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.
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.
Cheers,
Kamal.
[1]http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/util/JavaScriptHelper.java
[2]http://www.mail-archive.com/dev@cocoon.apache.org/msg56455.html
