[Seaside] Pharo 2.0 scriptaculous does not work

Johan Brichau johan at inceptive.be
Mon Jun 10 09:03:04 UTC 2013


btw, disregard my use of "natural" in my previous response. I apply the adjective too to many different situations, hence confusing you ;-)

On 10 Jun 2013, at 10:50, Johan Brichau <johan at inceptive.be> wrote:

> Diego,
> 
> Indeed, the most "natural" way of things from a project-dependencies point-of-view is that the Seaside project includes the Zinc-Seaside package, which is the way things work right now. However, the internal implementation of the adaptor is dependent on the version of the Zinc project. If Seaside references a particular version of the Zinc package _and_ references the #stable version of the Zinc project, it happens that Seaside can load incompatible versions of Zinc and the Zinc-Seaside package. Therefore, it would be more natural for the Zinc project to specify the version of the Zinc-Seaside package, instead of the Seaside project doing that.
> 
> Obviously, this is also not correct because the Zinc-Seaside package depends on Seaside as well. I guess that using current Metacello, we can only achieve this by creating a separate project-spec for Zinc-Seaside. It probably is the most correct way to do it, because the package sits between two projects.
> 
> Nevertheless, if Metacello would allow to specify a "requires" clause on project references, we could enforce the loading of Seaside-Core to precede the loading of Zinc (including its Zinc-Seaside adaptor package). Another solution (a bit more low-level) would be that Seaside config determines that version to load for the 'Zinc-Seaside' package is the one referenced in the #stable version of Zinc.
> 
> In summary, the main point is that Seaside should not reference an explicit Zinc-Seaside package version _and_ reference the symbolic #stable version of Zinc, because that breaks, has broken and will break again. Now, what is the most lenient solution to solve this? 
> 
> Johan
> 
> On 10 Jun 2013, at 09:39, Sven Van Caekenberghe <sven at stfx.eu> wrote:
> 
>> 
>> On 10 Jun 2013, at 09:23, Diego Lont <diego.lont at delware.nl> wrote:
>> 
>>> Johan,
>>> 
>>> Let me try to understand what you want.
>>> 
>>> You want to move Zinc-Seaside to Zinc, and thus build Zinc depend on Seaside instead of the other way around.
>>> So you want to add a group to Zinc, called 'Seaside', that loads Zinc-Seaside that requires Seaside30, so it loads after Seaside30 config is loaded with Seaside-Core.
>>> Both projects have load type linear, so it should work …. but my guess is that you than have to remove Zinc from Seaside altogether.
>>> 
>>> So I think my question would be: why should Seaside still depend on Zinc, when you move Zinc-Seaside to Zinc?
>>> 
>>> Diego
>> 
>> It is more complicated than that, IMHO:
>> 
>> - there is more than one Seaside (3.0.8 & 3.1), Zinc does not want (or has to) choose
>> - loading the Zinc-Seaside adaptor does not necessarily mean you have to update Zinc itself
>> - conceptually, Seaside needs HTTP support, not the other way around
>> - but you cannot load an adaptor without the Seaside framework classes being loaded
>> 
>> My current proposed solution is very simple: a group 'Seaside' that loads only Zinc-Seaside without dependencies. The advantage is that I can control the version and update it if needed.
>> 
>>> On Jun 8, 2013, at 10:11 AM, Johan Brichau wrote:
>>> 
>>>> 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
> 
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside



More information about the seaside mailing list