cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Plugging that big XSP shaped hole
Date Wed, 25 Jun 2008 14:55:02 GMT
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.

>>> 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 Wallez -

View raw message