cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Alternative Solution to XSP
Date Fri, 22 Jun 2001 17:04:07 GMT
[Very busy on several projects, hence my silence these days, but this
thread is important]

Berin Loritsch a écrit :
> 
> Michael Hartle wrote:
> >
> > Get the CMS to copy the needed content to Cocoon2-controlled paths
> > and files, finally process the resulting valid XML documents of business
> > analysts
> > via Cocoon2, transform the documents and by this seperately add business
> > code
> > and style.
> >
> > What am I missing that might screw such a setup ?
> 
> Data driven sites.  There has to be a way for business anylists to alter
> things like "What is a prompt called?", "What are the instructions for this
> form", and "What is the text of the help for this entry?" without screwing
> up standard layout conventions as well as how the information is pulled
> from the persistence layer.
> 
> The real danger is when the Business Analyst *thinks* they know something
> about the system.  In smaller companies like mine, we all know what is going
> on with a project.  If he (thinking he is helping) adjusts a SQL statement
> that is embedded, the app is broken.  The extent of the fix may be easy to
> locate or difficult depending on what has changed (I've seen a wrong sort order
> screw up expected results--esp. in complex joins).
> 
> What I am saying is typically what happens with XSP in general is that logic
> creeps into the page even if it is for something simple.  As soon as that
> happens, it is not suitable for a Business Analyst.  Besides Softquad XMetaL
> is not that good with namespaces--esp. when you are creating new documents.
> We need to come up with something scalable, that works for every company
> from open source project to fortune 500.

I understand your point. However, I don't think XSP should be blamed as
it is in this thread. XSP is great when used where it has to be. Writing
SAX events in Java is a PITA, and XSP makes it a pleasure.

IMO, the real point is how can we enforce (where it's required) that no
code is written in the source document and forbid in that document the
use of low-level primitives used for final code generation like
<xsp:logic> ?

This goes through some changes in the XSP engine :

- logicsheet preprocessors, as proposed by Giacomo. Writing a logicsheet
is hard and tedious. With SLL or other XSL generators, people can be
encouraged to write more logicsheets and thus move reusable <xsp:logic>
constructs from their XSPs into logicsheets.

- logicsheets syntax checking. Logicsheets must not only generate code,
but also control that they're used as they're intented to be, and most
of them don't check it. This was illustrated recently on cocoon-users by
a thread about <xsp:attribute> that cannot be put inside <xsp:logic> in
C2 as is possible in C1, while xsp.xsl doesn't care about it.

- XSP validators. In order to forbid the use of low-level logicsheets in
XSP documents, there could be some preprocessors that checks which
logicsheets are used. You could then have a "strict-serverpages"
generator that forbids use of <xsp:logic> while a developper-oriented
subsitemap could provide a "serverpages" generator that would allow it.

A key point also is IMO the "good design" of logicsheets : they should
generate as less code as possible (i.e. mainly control structures) and
delegate all logic to helper classes. SLL and other preprocessors can
help a lot in this area.

Considering that last point, I'm not sure hotspot performance issues
raised recently are really relevant. What's the fastest : hotspotted
transformers that perform tons of hashmap lookups to dispatch elements
to handlers, or glue code (the compiled XSP) that calls methods on Java
classes that are likely to be hotspotted if used throughout all the
webapp ?

About debugging, I admit debugging an XSP is not a easy as standard Java
code. But is it more difficult than debugging a complex event-driven
transformer ? Just connect a debugger (like the excellent JSwat) to a
running server and you can step sequentially inside your XSP and helper
classes, while you have to monitor state change in every startElement()
call of a transformer to find a bug.

Nevertheless, the various transformers that have been presented in this
thread are really interesting, but they should be an alternative to XSP
(as stated in this thread's title) rather that a replacement. Cocoon is
used in very different environments and both are useful.

Ok, now the answers to the poll :

What Problem does Cocoon Solve?
-------------------------------
Rate your response with a number between 1 and 5 where
1 is strong disagreement, 5 is strong agreement, and
3 is ambivolence.

[5] I like to easily theme my site

[3] I want to let business analysts write content, but
    not screw up business logic or style
(not really relevant for me since we sell turnkey applications based on
a layered presentation/logic/persistence architecture)

[4] I still want to be in control of the project, but
    I want to localize certain information in a few places.
(sure I want to be in control, but I don't really understant the point
here)

Cheers,
-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

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


Mime
View raw message