As the author of xsp-action, I have to say it was an ugly hack, meant
primarily for speeding up development cycles at a time when we did not
have flowscript nor hot code replace in Java debuggers.
Now your use case is right, and I agree that flowscript is overly
complex when all you need is a simple action that prepares some data
or defines routing in a pipeline as in your use case. And we talked
several times in the past about a JS-action that would sort of unify
flowscript and actions, but IIRC it was never implemented.
Was it not implemented because it was deemed too difficult or because no
one had the time to do it?
Is this possible? In some cases, I think this will be a neat solution
as you still have a clear separation between logic and presentation,
but you don't need to open three separate files to see what is going
on. Also, I don't see this as a replacement for flowscript, just
another tool in the toolbox that is Cocoon.
Considering the lack of a response to this functionality, I suspect
that it isn't doable or it is viewed as undesirable. If it is either
of these, can I please get an explanation? I suspect is a fairly big
task and it is probably something (at this point in time) I am not
capable of doing. That said, if no one has an objection to the
functionality and I can get some guidance, I am happy to look at
implementing it.
Hmm... This proposal is clearly mixing logic and presentation, which
is what Cocoon is all against! And this is one for the reasons that
led to deprecate XSP that opens the door to writing all application
logic in <xsp:logic> elements.
I am definitely in agreement with you about how Cocoon should be against
mixing of logic and presentation. In fact, I would go further and say
that is goal of XML. However, I disagree with your assertion that my
proposal is a mixing of logic and presentation. It has a clear
separation of logic and presentation, this just done in one file. The
idea would be that you would have one and only one Flow section and one
and only one presentation section. With Javascript defined in the Flow
section, you would have the ability to dynamically setup organic objects
to do what was required in the Presentation section.
The problem with XSPs (IMHO) was not that XSPs had logic and
presentation in the same file, it was the intermixing of logic and
presentation (not to mention the ugly mixing of java and XML). My
proposal does not have this problem as if enforces the separation. Also,
I am concerned that in deprecating XSPs we have replaced one set of
problems (the intermixing of logic and presentation) with problems that
are almost as big - a lack of transparency and sitemap bloat. The
sitemap bloat I have talked about. What I mean by lack of transparency
is best described with an example. If I find a bug with a particular
URL, in the past, all I had to do was find the appropriate pipeline and
all the information and files I needed to debug the problem would have
been there. Now, in the flowscript world, I would have to find the
appropriate pipeline. This would have a function call. I would then have
to search through all my flowscripts to find that function call, after
which I would have to look through the function to find out where the
send page is. When this is done, I go find that pipeline and then open
up the JX Template. Phew, that is a lot of work just to see what is
going on. It is no longer transparent as to what is going on. In cases
where there is complex logic associated with specifying what route to
take flowscripts are necessary (not to mention the easiest solution),
but I don't see the need for the overhead in the case when you want to,
for example, query a database, process the results and hand off the
resultant object to a JXTemplate to format the content.
Cheers.
- Re: Plugging that big XSP shaped hole Kamal
-
