[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