[Seaside] Pharo 2.0 scriptaculous does not work

Dale K. Henrichs dale.henrichs at gemtalksystems.com
Sat Jun 15 20:43:06 UTC 2013 

Johan,

A third  project for Zinc Seaside support isn't a bad alternative ... then the #stable is only incremented when support for Zinc has been successfully vetted against both projects ... 

Another alternative is to add a #stableSeaside symbolic version to the Zinc project that is "owned" by the Seaside project and changed whenever a new release has been vetted by the Seaside guys ... 

Presumably the Seaside API is changing a lot less frequently than Zinc, so this approach will decouple Seaside from Zinc a bit without having to manage a completely separate package...

Dale

----- Original Message -----
| From: "Johan Brichau" <johan at inceptive.be>
| To: "Seaside - general discussion" <seaside at lists.squeakfoundation.org>
| Sent: Saturday, June 15, 2013 12:38:16 PM
| Subject: Re: [Seaside] Pharo 2.0 scriptaculous does not work
| 
| Dale,
| 
| I guess the case was #1.
| Zinc produced a new #stable version but the Seaside project
| referenced an older (incompatible) Zinc-Seaside package. In
| contrast, the Zinc project was offering a correct version of
| Zinc-Seaside in its #stable version, but Seaside references
| Zinc-Seaside using an explicit package version.
| 
| So, my reasoning was that if Zinc was actually offering a matching
| Zinc-Seaside package version, it should be possible for Seaside to
| pick it up....
| 
| I fully agree that, given the dependencies, the Zinc-Seaside version
| to use should be specified by the Seaside version. But, since
| Seaside references Zinc using #stable, then it should also reference
| Zinc-Seaside using #stable. Or Seaside should reference Zinc using
| an explicit version.
| 
| In my mind, Zinc-Seaside is more of a shared package between Seaside
| and Zinc. Changes to both Seaside and Zinc might require it to be
| changed.
| In essence, if Zinc-Seaside would really have been owned by the
| Seaside project, then we would have needed to adapt it to work with
| the new Zinc.
| 
| Perhaps the most reasonable solution is to move Zinc-Seaside in its
| own configuration. Especially since Zinc is moving way faster than
| Seaside, we might want to deal with changing versions in a separate
| configuration and reference that one from Seaside using #stable.
| 
| Johan
| 
| On 15 Jun 2013, at 20:49, "Dale K. Henrichs"
| <dale.henrichs at gemtalksystems.com> wrote:
| 
| > Johan,
| > 
| > Sorry I've been completely absorbed by STIC this week, so the
| > doctor has not been in, but he is now:)
| > 
| > 
| > If I understand the flow of the conversation you are trying to
| > include the Zinc-Seaside package in the Zinc project without
| > specifying a proper dependency (because doing so would instroduce
| > a circularity between Seaside and Zinc).
| > 
| > You are taking this approach because you ran into problems when
| > Zven made a certain set of changes to Zinc that broke the
| > adaptor...
| > 
| > First I'd like to back up and say the Zinc-Seaside package _should_
| > be included in Seaside30 project with a dependency upon the Zinc
| > project. The Zinc-Seaside _is_ in support of the Seaside project -
| > the code is wrapping Zinc functionality with a Seaside-specific
| > (common) API for web servers.
| > 
| > It's not correct to expect Sven to be responsible for ensuring that
| > Zinc-Seaside passes all of it's tests whenever he releases a new
| > version of Zinc, so he should not be responsible for the
| > Zinc-Seaside package.
| > 
| > AFAICT, the issues came up when Sven released a new #stable version
| > of Zinc that,to quote Sven:
| > 
| >  "Some recent changes to Zinc apparently resulted in some
| >   compatibility problems with Seaside. We fixed already at
| >   least one of them..."
| > 
| > Either the "recent changes" were changes to the basic API (case #1)
| > or the Zinc-Seaside code itself was reaching into Zinc and using a
| > private API (case #2) or the Zinc-Seaside code was written to work
| > around/rely on a bug in Zinc (case #3).
| > 
| > Let's skip case #1 for now.
| > 
| > If the root cause is case #2, then the Seaside folks should work
| > with Zinc to define a public API that can be safely cause across
| > all future bugfixes ...
| > 
| > If the root cause is case #3 then the Seaside folks can take out
| > there workaround and move forward.
| > 
| > In both of the above cases the root cause is an anomaly that is not
| > expected to occur _every time Zinc is updated_.
| > 
| > If the root cause is case #1, then we have a more difficult
| > situation because in reality an API change results in the creation
| > of two #stable versions ... One #stable version is Zinc with the
| > old API the other #stable vesion is Zinc with new API.
| > 
| > If one expects to use a project in production applications, it is
| > reasonable to expect that the API itself remains consistent across
| > bug fixes ... I do not want to have to change my application in
| > order to safely pick up a bugfix from a project ... On the other
| > hand if I want to take advantage of the new api, I am be willing
| > to rewrite my application to take advantage of the new
| > capabilities... If we are indeed entering this area then we need
| > to adpopt the Sematic Versioning Spec[1] for version naming so
| > that API transitions can be recognized at the version-level which
| > then makes it possible specify project dependencies in tools such
| > as Metacello.
| > 
| > There is a fourth case (case #4) that occurs to me and that is that
| > the Zinc API is not complete and Seaside is dependent upon a
| > project with an API that is still under development. If this is
| > the case, it behooves Sven to pre-announce his plan to change the
| > Zinc API in an upcoming release and give projects and production
| > apps that depend Zinc a chance to evaluate the implications and
| > adjust their applications/dependencies in anticipation of the
| > change...
| > 
| > I am not "picking on Zinc." Sven is providing a very good product
| > free of charge to the community.
| > 
| > I _do_ want to make sure that we have characterized the problem
| > completely before taking action in the form of adding features to
| > Metacello:)
| > 
| > Dale
| > 
| > [1] http://semver.org/
| > 
| > ----- Original Message -----
| > | From: "Johan Brichau" <johan at inceptive.be>
| > | To: "Seaside - general discussion"
| > | <seaside at lists.squeakfoundation.org>
| > | Sent: Saturday, June 8, 2013 1:11:52 AM
| > | Subject: Re: [Seaside] Pharo 2.0 scriptaculous does not work
| > | 
| > | I think I need the metacello doctor to work out what I had in
| > | mind.
| > | Dale? you there? :-)
| > | 
| > | In the meantime, I bumped a new version that references the
| > | correct
| > | Zinc-Seaside package version, such that it works correctly for
| > | now.
| > | 
| > | The problem I have is that Metacello does not support the
| > | #requires:
| > | condition for project references. Before loading Zinc (with
| > | Zinc-Seaside), the Seaside-Core package needs to be loaded.
| > | I was under the false impression that such a statement was
| > | possible
| > | in Metacello, but alas... I am wrong.
| > | 
| > | So now I need to figure out how we can:
| > | - let the Zinc-Seaside package version be controlled by the Zinc
| > | project (it makes more sense)
| > | - have the Seaside config reference the Zinc project but only
| > | load it
| > | after having loaded Seaside-Core.
| > | 
| > | I tried several things yesterday including referencing Seaside
| > | from
| > | Zinc as well, but that went into an infinite loop (metacello does
| > | not detect loops?).
| > | Guess I was a bit too bold yesterday, but maybe Dale can shed
| > | some
| > | light on how to accomplish the above two items?
| > | 
| > | Johan
| > | 
| > | On 07 Jun 2013, at 16:43, Johan Brichau <johan at inceptive.be>
| > | wrote:
| > | 
| > | > Thanks Sven.
| > | > 
| > | > I'm adapting the Seaside config to include that group instead
| > | > of
| > | > the Zinc-Seaside package.
| > | > 
| > | > On 07 Jun 2013, at 14:17, Sven Van Caekenberghe <sven at stfx.eu>
| > | > wrote:
| > | > 
| > | >> Johan,
| > | >> 
| > | >> On 07 Jun 2013, at 10:11, Johan Brichau <johan at inceptive.be>
| > | >> wrote:
| > | >> 
| > | >>> On 07 Jun 2013, at 10:03, Sven Van Caekenberghe
| > | >>> <sven at stfx.eu>
| > | >>> wrote:
| > | >>> 
| > | >>>> I am willing to do that (it sounds logical), but can that be
| > | >>>> done without depending on Seaside itself ? Because that does
| > | >>>> not sound practical, maybe reducing a circular dependency or
| > | >>>> at
| > | >>>> least an interference with the specific Seaside versions and
| > | >>>> groups that you initially want to load.
| > | >>> 
| > | >>> If I am correct, that should not be a problem.
| > | >>> 
| > | >>> The Seaside30 config can specify to load the 'Zinc-Seaside'
| > | >>> version as specified by the Zinc config.
| > | >>> All you have to do is list the Zinc-Seaside package in your
| > | >>> version methods and make sure that it does not get loaded
| > | >>> when
| > | >>> not explicitly asking for it.
| > | >>> I believe that can be done by not putting it in the #default
| > | >>> load
| > | >>> group.
| > | >> 
| > | >> I just created
| > | >> ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.49 which
| > | >> now has a 'Seaside' group that loads the 'Zinc-Seaside'
| > | >> adaptor
| > | >> package with a specific version. It is of course not loaded by
| > | >> default.
| > | >> 
| > | >>> If you want your config to be complete, you can list a
| > | >>> dependency
| > | >>> on the Seaside project for the Zinc-Seaside package. This
| > | >>> would
| > | >>> only be loaded if somebody explicitly load the Zinc-Seaside
| > | >>> package.
| > | >> 
| > | >> For now I skipped the dependency on Seaside, we'll see how it
| > | >> goes.
| > | >> 
| > | >> Sven
| > | >> 
| > | >>> If that does not work, we need to ask the Metacello doctor
| > | >>> ;-)
| > | >>> 
| > | >>> Johan_______________________________________________
| > | >>> seaside mailing list
| > | >>> seaside at lists.squeakfoundation.org
| > | >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| > | >> 
| > | >> --
| > | >> Sven Van Caekenberghe
| > | >> Proudly supporting Pharo
| > | >> http://pharo.org
| > | >> http://association.pharo.org
| > | >> http://consortium.pharo.org
| > | >> 
| > | >> 
| > | >> 
| > | >> 
| > | >> _______________________________________________
| > | >> seaside mailing list
| > | >> seaside at lists.squeakfoundation.org
| > | >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| > | > 
| > | > _______________________________________________
| > | > seaside mailing list
| > | > seaside at lists.squeakfoundation.org
| > | > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| > | 
| > | _______________________________________________
| > | seaside mailing list
| > | seaside at lists.squeakfoundation.org
| > | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| > | 
| > _______________________________________________
| > seaside mailing list
| > seaside at lists.squeakfoundation.org
| > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| 
| _______________________________________________
| seaside mailing list
| seaside at lists.squeakfoundation.org
| http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
|

More information about the seaside mailing list