cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kamal <bh...@tt.com.au>
Subject Plugging that big XSP shaped hole
Date Tue, 24 Jun 2008 11:59:24 GMT
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

Mime
View raw message