Jason Foster wrote:
>
> > I would *strongly* suggest you to write a new reader.
> >
> > I totally understand that tweaking the sitemap sounds 'easier' because
> > the try/fail cycle is *much* faster now, but I tend to believe that
> > until we have the flowmap in place, we should avoid to add anymore
> > dynamism to the sitemap, or people will start to use it and come up with
> > even more things to deprecate or keep to maintain forever.
> >
> > Hope you get my point.
>
> I'll accept the point, but think that soon we're going to have a huge,
> messy, undocumented, proliferation of customized generators, actions, etc.
> For example:
>
> - FileExistsAction
> - FileNotExistsAction
> - PerlStyleFileTestAction
> - GrepAction
> - UnzipAction
> - GetUploadedFilenameAction
> - UploadedFileGenerator
> - UnzipUploadedFileGenerator
> - FallbackFileGenerator
> - FallbackTraxTransformer
>
> Maybe with Cocoon Blocks, and something like CPAN, this would be manageable.
> As is stands though, everyone will have to be a Java developer (OK,
> technically you could be an ECMAScript or Python developer) if they want to
> do things like this. Does this unduly restrict our userbase? I agree with
> the flexibility syndrome concerns, but there needs to be a happy medium
> between "everyone write a custom generator" and "everyone type volumes into
> the sitemap manually".
Jason, believe me I entirely share your concerns. In fact, it's a while
I'm worried about this and one of the reasons why I proposed the flowmap
was that people *love* the sitemap, but it's too declarative by nature.
Just consider one thing: which sitemap component is intrinsically the
least reusable AS-IS?
Actions, no question about it.
I'm pretty sure that if everybody submits their Cocoon-based webapps,
we'll have a tons of actions, some generators, a few transformers and
readers and no serializers.
This rings a bell: people need a better way to describe their precedural
flow and the Cocoon component approach is too heavy for this.
> Sorry to trip your alarm so strongly.
Absolutely no need to apologize, I'm very sensible because this *is* the
biggest design problem that Cocoon faces. You've touched a nerve and a
nerve that is going to be touched more and more in the future as soon as
users get sick and tired of having to write 10 lines of java code into
their actions and fragment thier contracts all over the place.
Recently, I came up with a sitemap what had three custom actions and
reached 12 levels of nesting, 6 matches and 48Kbs in size.
While at the same time I was writing thousands of lines of client-side
javascript with one/third of the effort.
I could smell something burning in the back of my neck.
Degree of reusability of those 'actions': null, zarro, forget it.
There is no problem in lack of intrinsic reusability of parts of
programs, but this is where 'scripting languages' come in and rock the
party.
In fact, both XSLT and the Cocoon Sitemap are markup-based declarative
scripting language. What we need to balance things out from a user
perspective is the abiliy to describe the application flow with the same
ease of use and the same fast try/fail cycle.
We might later decide to compile everything for performance and size
purposes, but for development or for normally-loaded sites, this won't
be necessary with a good internal caching system and a transparent proxy
up front.
So, what's the best solution?
Writing web applications is hard for a simple reason: they are half-way
declarative and half-way procedural. And it's very hard to find a
framework that has a nice balance between these two mindsets.
I would love Cocoon to become one and this is the reason why I proposed
the concept of a "flowmap".
Then Ovidiu came up with the wonderful idea of using continuations to
store the application state transparently, but the key usability issue
is not state control (even if admittedly a great plus) but the ability
to 'script' the flow of your application, making it act as a
programmatic and procedural 'glue' between cocoon components (those with
a high degree of reusability).
NOTE: I'm not stating that flowmaps deprecate actions, no way, but with
a scripted flowmap we have a new design pattern for components:
if you can make your logic reusable write a component
if not, write your logic in the flowmap
I'm going to investigate more on this subject which I consider very
important now and report back.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
