cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kamal Bhatt <kbh...@tt.com.au>
Subject Re: XSP block
Date Tue, 10 Jun 2008 04:07:02 GMT
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


Mime
View raw message