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.
Thoughts?
-- Reinhard
