Paul Hammant wrote:
> Nicola Ken Barozzi wrote:
>
>>
>> Paul Hammant wrote:
>>
>> [snipped many things that don't reall make much sense to me, but that
>> I won't question for the respect I have of you; go along, I will follow]
>>
>>> Nicola,
>>
>>
>> ...
>>
>>>> 3) define a common startup layer for the Avalon Containers, so that
>>>> it can be used with all containers. I imagine a single set of shell
>>>> scripts, a single servlet container, a single class container,
>>>> which can use inside any other container.
>>>> This would make it possible to run Phoenix or Merlin or whatever as
>>>> standalone, or in a servlet, or in another program... and also nested.
>>>
>>>
>>>
>>> I don't think you can count servlet. Why? It is not an Lifecycle
>>> using API.
>>
>>
>>
>> Concrete example: Cocoon is an Avalon Container. I want to be able to
>> run it standalone (CLI), in a Servlet (as now) or directly as a .SAR
>> in Phoenix.
>
>
> +1
>
>>>> This would eliminate the problems we are having now, by making
>>>> components usable in all containers by nesting containers, and
>>>> making any container easily embedded in other apps.
>>>
>>>
>>>
>>>
>>> With respect, I have written two containers that sit on top of the
>>> default container Phoenix. They are Jesktop and EOB. Both of them
>>> handle classloading of their separate componets well enough. It
>>> would be nice for me to use ContainerKit or Excalibur/Container to
>>> save lines of code, but I have not done so yet. Anyway, the point
>>> is that container-in-container is possible already.
>>
>>
>>
>> I can easily make plain components work in Phoenix, but as you have
>> seen with Merlin, viceversa is not painless.
>> Can Merlin use EOB?
>
>
> I dunno, I suggestd to Stephen that he tried it a couple of week ago :-)
EOB includes BlockContext which means that additional meta-info is
required for these components to run inside Merlin.
The solution to this involves the following:
* add .xtype descriptors to the EOB distribution (these contain the
information describing the depedencies that the EOB blocks have -
including the dependency on the Phoenix BlockContext interface and
Phoneix conterxt keys)
* use the patched version of cornerstone that I'm maintaining (the
patched version also includes the .xtype declarations in order to solve
the same issues and provide convinient deployment profiles for some of
the conterstone components)
Cheers, Steve.
>
>
>>> *Please* let me continue with my slow programme of issue-by-issue
>>> conflict resolution.
>>
>>
>>
>> [I still don't see how your mail about the blurb is an issue-by-issue
>> conflict resolution; please remain concrete on the proposals.]
>>
> I am, We started with four choices for BlockContext
> compatability/resolution and we are working towards an agreement.
What about adding the deprication of BlockContext to the list?
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
