Plugging that big XSP shaped hole

[Kamal <bh...@tt.com.au>]

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

Re: Plugging that big XSP shaped hole

[Antonio Gallardo <ag...@agssa.net>]

Kamal escribió:
> Sylvain Wallez wrote:
>> 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 BSFAction?
Hi Kamal,

I think Sylvain refers to:

http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/acting/ScriptAction.html

This is part of the BSF block in cocoon. There is also a generator, 
running samples are here:

http://cocoon.zones.apache.org/demos/21branch/samples/blocks/bsf/welcome

I hope this helps.

Best Regards,

Antonio Gallardo.

Re: Plugging that big XSP shaped hole

[Kamal <bh...@tt.com.au>]

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

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

Re: Plugging that big XSP shaped hole

[Sylvain Wallez <sy...@apache.org>]

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

-- 
Sylvain Wallez - http://bluxte.net

Re: Plugging that big XSP shaped hole

[Kamal <bh...@tt.com.au>]

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


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

Cheers.

Re: Plugging that big XSP shaped hole

[Sylvain Wallez <sy...@apache.org>]

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