Sylvain Wallez wrote:
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.
What do you mean by " closely integrated" with Flowscript? Where is the
BSFAction?
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
