cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Cocoon Web Applications
Date Thu, 28 Feb 2002 15:25:31 GMT
Antti Koivunen wrote:
> 
> Stefano,
> 
> It seems that we pretty much agree on everything :)

cool

> (My first mail was mostly prompted by the use of the term "Web
> Application" and the "replacement for .war" impression that I first got
> from the message, but I realize that of course wasn't the idea.)

yes, I want to 'modularize' cocoon from the user perspective, not only
from the developer's perspective (as it is today).
 
> See below for more...
> 
> Stefano Mazzocchi wrote:
> > Antti Koivunen wrote:
> >
> >>Stefano Mazzocchi wrote:
> >>
> >>>Antti Koivunen wrote:
> >>>
> <skip/>
> >>>>
> >>>>Based on this, and other discussion on this list, I think it could be
> >>>>useful to have some kind of installation/configuration tool for Cocoon.
> >>>>It shouldn't be too difficult to implement with a clear definition of
> >>>>core libraries, optional modules and dependencies (within the same
> >>>>Cocoon distribution). At first, it could be a simple client app that
> >>>>just does the following:
> >>>>
> >>>>  1. Download a set of files describing the Cocoon distribution.
> >>>>  2. Select the desired modules (in addition to the core fileset).
> >>>>  3. Check the dependencies (file-level, within the same distribution).
> >>>>  4. Create the directory structure and download the required files.
> >>>>  5. Create a sample sitemap and xconf for the selected modules.
> >>>>
> <skip/>
> >>>
> >>Well, more of a way of increasing the modularity and internal
> >>consistency of the Cocoon distribution (as opposed to a complete package
> >>management solution).
> >>
> >
> > ok
> 
> 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?

> <skip/>
> >>>
> >>I'm all for increasing the modularity and extensibility of Cocoon, and I
> >>like e.g. the concept of "skins", but I'm not sure that "Web
> >>Application" is the right "unit" to use. I mean, it's just as likely
> >>that Cocoon is used as a part of a single webapp, and I'd also like to
> >>see the same modularity apply to other components, e.g. the likes of hsqldb.
> >>
> >
> > Of course. Modularity should be both 'vertical' (as with the 'skin'
> > approach) and 'horizontal' (as with hsqldb examples or a portal
> > application).... but I think my proposal solves both at the same time.
> 
> I think so too. We just have to define all the things that the modules
> may require and expose, e.g. one might just provide a simple role, while
> another one could include a sitemap and a mount-point, etc.
> 
> 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.

> >>If CWA is defined to be "something that provides additional
> >>functionality" for the Cocoon instance, then I think it's a good idea
> >>(but perhaps better named to "Cocoon Web Component" or CWC, respectively).
> >>
> >
> > 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?

> <skip/>
> >>
> >>>But a package manager alone would not something that would please my
> >>>search for a viable way to make cocoon web applications easily reused
> >>>between different projects.
> >>>
> >>I agree (and would love to see that repository of Cocoon modules :)
> >>
> >
> > 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.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------




-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message