cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo <>
Subject Re: XSP block
Date Tue, 10 Jun 2008 21:18:53 GMT
This is a thread that for time to time is being discussed. See:

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]

View raw message