Kamal wrote:
Hi,
As has probably been discussed numerous times on this list, XSPs are
deprecated (or at least perceived to be, I won't get into the
philosophical discussion ) and flowscript + JXTemplates are the new
deal. As I (as well as others) have said in the past, I don't think
that this is an adequate solution. In a previous email, I stated three
issues that I think stop the flowscript + JXTemplate from adequately
replacing XSPs. I will repeat them here:
1. It leads to an explosion in pipelines. Instead of one pipeline, you
now have 2 (at least) instead of the one you get with XSPs.
2. There is so much that isn't easily ported to a JXTemplates +
flowscript environment. For example, there is no analogy to xsp:element.
3. No analogous functionality to the esql logicsheet. You basically
have to create your own and for simple queries, this can quickly
become a hassle.
I will add one more issue:
4. No replacement for xsp-action.
I have fixed the issue of there being no jx:element (though, I suspect
there are other things that XSPs give that Flowscript + JXtemplates do
not give us), and I am not going to even try to tackle issue (3).
However, I would like to take a stab at issue (4) and propose a
solution for issue (1).
Firstly, the replacement for xsp-action. I was thinking about a
Javascript Action. The basic idea is that you pass in as the src a
javascript file. This javascript file will contain a code that returns
an object, this object contains a set of variables that the action
then makes available to the sitemap (similar to flow attributes). I
think the basic idea is sound. I am thinking some of the code that is
available in the forms block [1] could be employed here. I am not too
sure how you stop people from doing silly things (such as allowing
people to define objects and functions rather than primitives) but I
suspect that flowscript deals with this issue.
Now that I bought up Flowscript, I guess I should answer why I feel
Flowscript does not replace XSP-action. In my case, I have an XSP
action that checks the database for a particular record. If this
record exists, it gets a column, which contains a directory for a set
of XSLT, this location is then used to select a particular XSLT for a
transformation. This action is used everywhere, the idea of
replicating this functionality in Flowscript sounds very messy. Also,
I don't believe Cocoon makes for a great Java framework and I believe
that your average user shouldn't have to know the gory details of
Cocoon to do simple things.
Please tell me if all of this sounds naive.
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.
I will leave up to a vote as to whether this change should go through.
If we have a majority, I am happy to work on this action if someone is
willing to give me some guidance.
As for (1), I will reiterate what I said in a previous email[2]:
I was wondering if anyone has thought of creating an extension to
JXTemplates to support a new style of template. One where you can
specify a javascript/Java/Ruby/whatever at the top and the
presentation after that. For example, something like this:
<Template>
<Flow>
<Javascript>
return({content : "123"});
</Javascript>
</Flow>
<Presentation>
<some_content>
<jx:out value="${content}"/>
</some_content>
</Presentation>
</Template>
This would return:
<some_content>123</some_content>
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.
Sylvain
--
Sylvain Wallez - http://bluxte.net
