XSP block (was: Type 'serverpages' does not exist for 'map:generate')

[Joerg Heinicke <jo...@gmx.de>]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

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

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