cocoon-dev mailing list archives

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

What do you mean by " closely integrated" with Flowscript? Where is the 

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

View raw message