This is a double reply, it was so convenient, I couldn't resist. :-)
On Friday, 15. March 2002 17:11, Chris Bilson wrote:
> Tod Harter writes:
> > 1st of all, the entire "document" model of serving content, go ask for a
> > URL, get back the result breaks down badly. Consider a form that when
> > you submit it could generate either of 2 completely different results.
> > Obviously you don't want to have to COMBINE the contents of those
> > results into one template with a big IF statement, that defeats the
> > entire purpose of the template idea, to have something that is close in
So if you dislike that (something I can understand quite well), use internal
or external redirects on successful completion of one page. With external
redirects, even the browser sees a different URL, which plays nicely with
caching proxies, the 'Back' button and the like. You still get a (small) if
statement, but you need one anyways. Having it in the XSP has the advantage
of making the page self-contained.
> Of course this doesn't work. XSLT is way too complex for most of the
> HTML designers I know. I think it's great, and they think I'm nuts.
There are designers out there who already deliver XSLT, so this is just a
matter of time.
> > The 2nd problem is the nature and structure of XSP itself. Its just
> > plain butt ugly. Its fine as I said for putting a few snippets into a
> > page, but as an actual language to implement logic in, its GHASTLY. 1st
Au contraire, it is great. Given the right taglibs, you can have a declarative
description of logic in your XSP page, which any non-programmer would
understand. Do the programming in your taglibs, and use XSP as logic
description.
> > of all the syntax rules are insane. Sure its XML, but you can spend
> > hours or days trying to understand why you cannot nest certain tags
> > together, and every taglib has idiosyncracies about where and how you
> > can use it. Perl and XML syntaxes don't mesh at all well either. Then
That's what you would call a 'bug'. Please report them. Ideally, XSP just
DWIMs, which is what any perl coder should be comfortable with, isn't it?
Plug ahead: AFAICT, SimpleTaglib derived taglibs have much less problems
with nesting than others, as they do not have to care about the context, it's
all done for them by SimpleTaglib.pm
> > there is the problem that you can't modularize anything at all. Just
> > like the original poster here was saying. What are you going to do,
> > replicate your logic all over the place? Start creating an include for
I'd write a taglib. And I did that kind of stuff, hiding all the logic away,
giving me an easy to use "when finished go to this location" tag and
everything. My form XSPs contain a little logic (just the glue to link to the
next step), generates a little content (just data, not a document - the XSLT
makes a document from the data), and a reference to a declarative description
of what data is processed. Here, the XSP is the 'control' part of the CMV
(MVC) paradigm. The 'model' is stored in reusable, mostly object oriented
external descriptions, and the 'view' is managed by XSLT.
XML is perfect for this approach, as with XML you need much less knowledge
about the data you are managing.
> > each "subroutine" that you want? Now you run into all the reasons modern
> > programming languages were born. Except with XSP its worse because your
> > variables are hidden away etc. Who knows what the REAL code is!!!!
When you start looking for the real code, you are not using XSP correctly.
> > Honestly it seems to me that content is content and logic is logic, and
> > trying to munge the two together is a big bastardized ugliness. I'd like
> > to hear some alternative viewpoints though because I'd be happy to use
> > XSP if someone can point out an actual concrete benefit to it in any
> > non-trivial application.
Just do not mix up content and logic. Mix up _data_ and logic, this is what
you do in your classic programming language as well. Let XSLT make content
from the data.
When you find yourself putting static data in your XSP, then why use XSP at
all? After all, XSP is about dynamic data.
> I don't know that there is much of an alternative. To write web
> applications you _must_ connect logic and content. It's just a
Just want to emphasize this. The connection is done via stylesheet
configuration and XSP (if dynamic data is involved), and, of course, via
old-fashioned hyperlinks.
> interfaces between the content and the logic. Right now, I am kind of
> obsessed with the idea of logic generating XML for XSLT to transform
> into content, and never having the content have to talk back to the
> logic. This is radically different from the way I am used to doing
Yes, this is great. This is the extensibility of XML at work. When you find
yourself needing another bit of data for another nice XSLT feature, just add
it and everything else will work on as before.
> parts. I have been wanting to use XSP for this (as opposed to
> something like Mason+AxKit), so everything can come in one box
> (AxKit).
This is preferred, because when using just XSP/XML + XSLT, all processing is
done on the DOM tree. No string processing, repeated parsing/serializing is
done except for the initial data source and the final output.
--
CU
Joerg
PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc
PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
