Kamal wrote:
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?
I don't think it's a very complex task, and a lot can be borrowed from
the existing flowscript code. This is even needed, so that from a
js-action we can access the global variables and the view data (also
called "biz data") used in flowscript. The js-action must be able to
work independently, but also integrate nicely with flowscript for
scenarios where it is needed.
So it's a matter of time, or itch to scratch. Seems you have this itch :-)
Note that there is a BSFAction that can be used for actions using any of
the scripting languages supported by BSF (including JS), but it isn't
closely integrated with the flowscript data.
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.
I see your point, and the pipeline stacktraces only help when things go
really wrong. Now the js-action would make things easier, don't you think?
Sylvain
--
Sylvain Wallez - http://bluxte.net