> I am throwing out some random ideas to eliminate the need for
> code in XSP.
Ciao,
I was expecting to write this e-mail in a couple of weeks,
but I can't avoid to jump in now since this topic is very
interesting and important to us here in Bibop. This is
also a good time to futher discuss the latest Stefano's
RT about code generation, so please bear with me. :)
We came to understand that while XSP is a really great
tool for "instant gratification" and rapid development
of small applications there are a number of areas where
it shows some shortcomings.
The first of course is separation of concern. And I'm
being practical here: logicsheets can help, but in most cases
you have to ask your web designers to do some programming,
and this is something they're very uncomfortable at. This
turns out in bugs and problems during the development
cycle, something we wanted to avoid by using technologies
such as Cocoon.
The second issue is architectural: here I must confess
that I have a personal bias against the whole code generation
approach. The point is that using this kind of technology
we are inserting possible pitfalls in our environment:
we need to have a java compiler floating around
and we need to overcome the total dumbness of it, we
need a "repository" and it needs to work well (I'm thinking
about permissions, disk space and so on), we have little
or no control over what kind of code will actually be
generated (which might lead to unexpected problems such
as a dreaeded OutOfMemory which is driving us crazy) and
even worse you cannot rest assured that it will actually
compile under all circumstances. And I will forget about
debugging nightmares. Last but not least all the issues
that Stefano has been talking about such as hotspots,
compiler optimizations and so on also remain and add
to the balance.
Finally a third issue: performance. No one is or will be
using Cocoon for a small personal site with a few hits per
day, the real playground for Cocoon is in complex environments
with tons of users, page views and so on. While we still don't
have any reliable benchmarks for Cocoon 2 our experience with
Cocoon 1 showed us that using a component-based approach to
dynamic XML generation turns out into *huge* performance
improvements not only in terms of speed of execution but
also in scalability and overall resource usage: we are talking
about an order of magnitude for the applications we needed
who went down to 50-60ms vs. 200ms for the plain XSP solution.
All in all the balance, IMHO, is negative: the ability to
quickly develop and deploy a solution is really nice, but
you're going sooner or later to pay a lot for it. This is
why we started to work on alternative solutions: we have been
announcing some time ago x:forge, which is a component based
approach for dynamic XML generation. X:forge is being ported
to the new Avalon APIs thus allowing us to use it in C2 as
a Transformer: we are using it today inside our CMS which
is based on Cocoon 1 as a processor and we are really satisfied
with performance and overall impact over the rest of the
structure (editors, graphics...). Actually the framework
is not only Cocoon agnostic but even Servlet or Web agnostic
so that we are using it even outside of web applications.
We are doing even more: Ricardo is working in what will be
the evolution of x:forge which will be namespace based and
even more component oriented, with fine grained scope
and more. Besides I assume that as for the current version
of x:forge this framework too will not be used at the Generator
level but as a Transformer (well, AFAIK... :)). I hope Ricardo
can jump in and help us in discussing this issues which are
really important to us, but I'm also very interested in knowing
what all of you think about this kind of concerns.
Berin, this is your poll:
[4] I like to easily theme my site
[5] I want to let business analysts write content, but
not screw up business logic or style
[5] I still want to be in control of the project, but
I want to localize certain information in a few places.
I also like *very much* the idea of the XMLizable interface:
we'll talk about it. What happened though to the XObject
interface?
Thanks to everyone who read so far :)
Ciao,
--
Gianugo Rabellino Via Comune Antico, 43
C.T.O. 20125 Milano (MI) - Italy
Bibop Research, Int. S.p.A. [EMAIL PROTECTED] - http://www.bibop.it
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
