Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <48621787.8070800@apache.org>
Date: Wed, 25 Jun 2008 12:01:43 +0200
From: Sylvain Wallez <sylvain@apache.org>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Plugging that big XSP shaped hole
References: <4860E19C.20705@tt.com.au>
In-Reply-To: <4860E19C.20705@tt.com.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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