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
