Re: XSP block

[Kamal Bhatt <kb...@tt.com.au>]

I am not really a committer to Cocoon, but I was wondering about this 
whole JXtemplates + Flowscript replaces XSPs advice. I feel that 
JXTemplates + Flowscript is a poor substitute. Here are my reasons why:

1. It leads to an explosion in pipelines. Instead of one pipeline, you 
now have 2 (at least)
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 have put my hand up for (2), and when I find some time I will look 
into it. I cannot see any way of rectifying (3), which is unfortnate 
because I suspect that is the biggest reason why people will not move 
away from XSPs. As for (1), 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>

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.

Anyway, my 2c.

> Moving this discussion from users list (for reference [1]) to dev list.
>
> On 06.06.2008 19:02, Alfred Nathaniel wrote:
>
>>> Warning: I'm stating my own opinion here, nothing official or 
>>> something like that.
>>>
>>> There are at least three problems with XSP:
>>> 1. No active committer is interested in XSP anymore, and even more, 
>>> hardly anyone wants to invest her time in technology that seems to 
>>> be deprecated in every dev's head but still block is not officially 
>>> marked as deprecated.
>>
>> I may be not as active as you but I am a committer who is still very
>> interested in XSP.  In may daytime job we have 1000+ XSPs in production
>> and no intention to drop that technology in the forseeable future.  XSP
>> has its shortcomings and pitfalls but after 7 years experience we know
>> how to handle that.
>>
>>> 2. The only reason why people keep trying to use XSP is that it has 
>>> decent documentation on our site and this documentation has no 
>>> information about XSP status. We should really explain people that 
>>> Templates + Flowscript is much better approach.
>>
>> I think the reason why XSP appeals to newcomer is that the concept is
>> familiar from JSP, and it is a combination of the three core
>> technologies which Cocoon handles extremely well:
>> XSP = XML + XSLT + Java.
>>
>> Personally, I still do not consider Flowscript an alternative for
>> enterprise websites for three reasons:
>>
>> a.) Serverside JavaScript is an additional level in the technology stack
>> you and your team have to master.
>> b.) I would not bet my head on Rhino being threadsafe, and it is such a
>> big beast to debug it yourself.
>> c.) Continuations are a great idea, but how do you know when it is safe
>> to free the memory?
>>
>>> 3. XSP is really old technique and is not maintained by anyone 
>>> (again officially, at dev/commits list). I'm not the one willing to 
>>> take costs of XSP maintenance in C2.2 therefore I'll probably vote 
>>> -1 for any actions leading to release of XSP block for C2.2. This is 
>>> my first such a strong voice in this case but I firmly believe it's 
>>> a high time have a concrete opinion.
>>
>> XSP is a really mature technology which hardly needs any maintenance any
>> more.  The reason why the XSP block (as many other blocks) is not
>> released yet is actually more of a C2.2 issue than an XSP problem.
>>
>>> Still, I'm open for discussion of course.
>>
>> I'd prefer to have this sort of discussion on the dev-list.
>
> I completely agree with Alfred. I don't see any reason for not 
> releasing XSP block. Yes, somebody has to do the actual work. But why 
> blocking it when somebody puts in the effort? You can estimate the 
> maintenance costs by looking at the changes in the last years in the 
> 2.1 branch.
>
> Joerg
>
> [1] http://marc.info/?t=121249886400001&r=1&w=4


-- 
Kamal Bhatt

Re: XSP block

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

This is a thread that for time to time is being discussed. See:

http://markmail.org/message/uzilvg4ww35nmegk

Quoting from my mail in the thread:

"As an "old" XSP user I think XSP is good for some rapid prototyping and 
for some small sites (Matthew and Carsten book stated about it clearly). 
The problems using XSP in webapp I painfull learned while working with 
it. :-( "

Best Regards,

Antonio Gallardo.


Kamal Bhatt escribió:
> I am not really a committer to Cocoon, but I was wondering about this 
> whole JXtemplates + Flowscript replaces XSPs advice. I feel that 
> JXTemplates + Flowscript is a poor substitute. Here are my reasons why:
>
> 1. It leads to an explosion in pipelines. Instead of one pipeline, you 
> now have 2 (at least)
> 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 have put my hand up for (2), and when I find some time I will look 
> into it. I cannot see any way of rectifying (3), which is unfortnate 
> because I suspect that is the biggest reason why people will not move 
> away from XSPs. As for (1), 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>
>
> 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.
>
> Anyway, my 2c.
>
>> Moving this discussion from users list (for reference [1]) to dev list.
>>
>> On 06.06.2008 19:02, Alfred Nathaniel wrote:
>>
>>>> Warning: I'm stating my own opinion here, nothing official or 
>>>> something like that.
>>>>
>>>> There are at least three problems with XSP:
>>>> 1. No active committer is interested in XSP anymore, and even more, 
>>>> hardly anyone wants to invest her time in technology that seems to 
>>>> be deprecated in every dev's head but still block is not officially 
>>>> marked as deprecated.
>>>
>>> I may be not as active as you but I am a committer who is still very
>>> interested in XSP.  In may daytime job we have 1000+ XSPs in production
>>> and no intention to drop that technology in the forseeable future.  XSP
>>> has its shortcomings and pitfalls but after 7 years experience we know
>>> how to handle that.
>>>
>>>> 2. The only reason why people keep trying to use XSP is that it has 
>>>> decent documentation on our site and this documentation has no 
>>>> information about XSP status. We should really explain people that 
>>>> Templates + Flowscript is much better approach.
>>>
>>> I think the reason why XSP appeals to newcomer is that the concept is
>>> familiar from JSP, and it is a combination of the three core
>>> technologies which Cocoon handles extremely well:
>>> XSP = XML + XSLT + Java.
>>>
>>> Personally, I still do not consider Flowscript an alternative for
>>> enterprise websites for three reasons:
>>>
>>> a.) Serverside JavaScript is an additional level in the technology 
>>> stack
>>> you and your team have to master.
>>> b.) I would not bet my head on Rhino being threadsafe, and it is such a
>>> big beast to debug it yourself.
>>> c.) Continuations are a great idea, but how do you know when it is safe
>>> to free the memory?
>>>
>>>> 3. XSP is really old technique and is not maintained by anyone 
>>>> (again officially, at dev/commits list). I'm not the one willing to 
>>>> take costs of XSP maintenance in C2.2 therefore I'll probably vote 
>>>> -1 for any actions leading to release of XSP block for C2.2. This 
>>>> is my first such a strong voice in this case but I firmly believe 
>>>> it's a high time have a concrete opinion.
>>>
>>> XSP is a really mature technology which hardly needs any maintenance 
>>> any
>>> more.  The reason why the XSP block (as many other blocks) is not
>>> released yet is actually more of a C2.2 issue than an XSP problem.
>>>
>>>> Still, I'm open for discussion of course.
>>>
>>> I'd prefer to have this sort of discussion on the dev-list.
>>
>> I completely agree with Alfred. I don't see any reason for not 
>> releasing XSP block. Yes, somebody has to do the actual work. But why 
>> blocking it when somebody puts in the effort? You can estimate the 
>> maintenance costs by looking at the changes in the last years in the 
>> 2.1 branch.
>>
>> Joerg
>>
>> [1] http://marc.info/?t=121249886400001&r=1&w=4
>
>