cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject [roadmap] Cocoon 2.2
Date Sun, 01 Aug 2004 13:23:02 GMT
Steven Noels wrote:

> On 30 Jul 2004, at 12:07, Vilya Harvey wrote:
>> A scripting language feels like overkill for simple pipelines, but 
>> the XML syntax is very awkward for more complicated ones. The 
>> appropriate choice comes down to how soon you feel that cutoff 
>> occurs, for the kind of sites you develop.
> If the complexity of a sitemap becomes too troublesome to express 
> using XML, I'm pretty sure adding yet another concern to the same 
> artefact won't help - quite the contrary. I'm pretty sure some 
> sitemaps "out there" are simply too complex because people use all 
> sorts of twisted pipeline constructs and components, just to avoid 
> writing some lines of flowscript or an Apple, or use Java proper. What 
> some people feel like a disadvantage (splitting flow and pipelines 
> into separate artefacts), I feel like a distinct advantage of Cocoon. 
> With my peanut brains, I'm able to understand more advanced Cocoon 
> apps when I see a <map:call function|continue> and some internal-only 
> pipelines which are called by flow functions with a well described Map 
> of input parameters. This is all highly personal, of course.
> </Steven>

I support this. Maybe there are some users out there who feel 
uncomfortable that we discuss a lot about our fundamentals and the 
things they have based their work on. I think this is the base for 
inventing something new or finding better solutions because this gives 
you the chance of looking at things from a different angle.

I want to say that I like the way how Cocoon works _today_. I really 
like the separation of the declarativ sitemap and the procedural 
controller. I don't think this is clumsy or somethink else and it really 
helps to _understand_ web applications. I admit that it may be 
simpler/shorter to write all your stuff into one ???map but this can't 
be declarativ any more and this would destroy a lot of the 
understanabilty of Cocoon, of course, this is very personal.

IMHO we should focus on _polishing_ the things we have now. We would 
need a bunch of Flowscript components for database access, mailing, 
webservice integration and maybe more, we have to split up Cocoon into 
smaller pieces (I'll set up a proposal for this soon) so that it doesn't 
feel like a monolith any more and that we become more flexible and we 
finally have to work on a reference documentation that gives the user a 
sense of having a complete doc in her hands.

Something that I'm currently missing too, is a well defined roadmap for 
Cocoon 2.2.

The major points IMO are:

  - splitting up Cocoon into smaller pieces (a
    prerequiste for Cocoon Blocks)
  - Virtual Sitemap Components, inheritable views
  - move from ECM to Fortress
  - stable Cocoon Forms
  - complete reference documentation

After agreeing on the things that we want to become part of Cocoon 2.2, 
we should define milestones so that our users have an idea where we want 
to go and when we think we will arive.



View raw message