<skip/>
>>I wonder if this is something we should move forward on (not sure
>>myself). On one hand, it feels like an intermediate (perhaps
>>unnecessary) step to the full 'CWC' model, but on the other hand, it
>>would be relatively easy to implement (version 2.0.3 - 2.1.0) and could
>>make Cocoon more approachable. It would also provide (force) a clear
>>definition of the core fileset and purpose of each 'component' (set of
>>files) in the distribution. What do you think?
>>
>
> I'm not sure I understand your points: can you please elaborate more on
> this?
Hmmm, probably best to explain with an example. The 'distribution
descriptor' might look something like:
<distribution version="2.1" clientversion="1.0"
basedir="http://xml.apache.org/cocoon/dist";>
<!-- Globals that can be later referenced. -->
<property name="src.dir" value="src"/>
<property name="lib.dir" value="lib"/>
<!-- List of all files in the distribution. -->
<files>
<f name="README.txt"/>
<f name="${src.dir}/org/apache/cocoon/SomeClass.java"/>
<f name="${lib.dir}/somelib.jar"/>
...
</files>
<!-- The core fileset. -->
<core>
<f name="*.txt"/>
<f name="${lib.dir}/core/*"/>
...
</core>
<!-- Optional modules. -->
<modules>
<module descriptor="modules/mod-a.xml"/>
<module descriptor="modules/mod-b.xml"/>
</modules>
</distribution>
and a module descriptor might look like:
<module name="Module-A" version="1.0">
<files>
<f name="${src.dir}/org/apache/cocoon/moda/**"/>
<f name="${lib.dir}/optional/dep-a.jar"/>
</files>
</module>
I hope this shows the idea. The component based architecture would allow
these type of file level dependencies. This would provide a clear
(automatically documentable) definition of the relationships between
each component in the distribution. However, even though most of the
process could probably be automated, I'd be careful not to introduce
anything that could potentially slow down the actual development.
>>The Cocoon core could essentially consist of the 'XML processing
>>controller' (in lack of a better term) and the 'CWC container'. I have
>>to say I really like where this is going :) It could open a new array of
>>possibilities for extensibility, component reuse, remote management, etc.
>>
>
> Easy, let's keep the feet on the ground :) what you are perceiving is
> the freedom that a better architecture gives you, but it's very easy to
> get carried over and loose focus, I don't want this.
I know, I know :) but we should of course pursue the ideal architecture.
>>>I like 'Cocoon Web Component', yeah, that's a good name.
>>>
>>Thanks, I like it too. Another even more general term would be simply
>>'Cocoon Module', but it might not have the same marketing value (and the
>>acronym would be confusing :)
>>
>
> Hmmm, what do others think of this?
Well, this was already taken elsewhere, but I also like 'Cocoon Block'.
>>>Exactly and I think that in order to make sure they interoperate in a
>>>nice and easy way, CWC polymorphism would be way cool!
>>>
>>Absolutely. Perhaps it's time to get back to the root of this thread and
>>start defining things in detail :)
>>
>
> Yes, totally. Why don't you get back to my first email and comment on
> the technical details that I expressed there? I'm sure this will start a
> discussion and others might jump in.
Seems that they already did :) Perhaps you could gather the ideas under
a new RT 'Cocoon Blocks' (I'm sure you can do better ;)
(: A ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
