-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cycle dependency between Seaside-Core and Seaside-Canvas #1251
Comments
That's indeed a dependency that was recently (and inadvertently) introduced. The In Pharo and GemStone, this does not cause an issue. The code is loaded and the reference to the undeclared class is automatically resolved when the Seaside-Canvas package is loaded. Does this kind of undeclared classes cause issues loading in VAST? |
Hi Johan, However...when we found this problem we realized that maybe it was better to set explicit dependencies based on Seaside's BaselineOf (requires: and friends). So now we switched to this explicit approach and now the problem is solved for us. So.... up to you Johan what you want to do. From VAST perspective we are OK, we took another approached and we moved forward. Regardless of the result, thanks for taking a look! |
Hi @jbrichau I keep thinking about this one and while I solved my original problem, I still agree with you with the "Perhaps that should be an extension to the filter in the Seaside-Canvas package". So I will try to make that change soon. |
The only way I see to solve this properly is to introduce a third package that will depend on both. My initial approach to this was to create a But as I was doing this, I noticed that having a separate package only for this two classes might be overkill or at least short-sighted, then I thought about having a separate So @jbrichau the next PR will include this change. If you disagree with that, please let me know and I'll modify it to have only the |
@eMaringolo my idea was to remove rendering in the base implementation of the filter (just return http code) and move the response that renders html to a subclass. |
Well... that's a much simpler solution. |
I guess to Seaside-Canvas, right? |
@eMaringolo I was going to take care of it but you can beat me to it as I will only be able to get back to Seaside by the end of the week. 😉 |
BTW, I didn't move the canvas-dependent filter to |
If you see in BaselineOf, Seaside-Core depends on no one (https://github.com/SeasideSt/Seaside/blob/master/repository/BaselineOfSeaside3.package/BaselineOfSeaside3.class/instance/baselinecommon..st#L34) and Seaside-Canvas depends on Seaside-Core (https://github.com/SeasideSt/Seaside/blob/master/repository/BaselineOfSeaside3.package/BaselineOfSeaside3.class/instance/baselinecommon..st#L30)
However... Seaside-Core DOES NEED Seaside-Canvas... as it references the class WAHtmlCanvas which is contained in Seaside-Canvas: https://github.com/instantiations/Seaside/blob/tonel-dev/repository/Seaside-Core/WASessionCookieProtectionFilter.class.st#L87
Thoughts? @jbrichau
The text was updated successfully, but these errors were encountered: