Andreas Hartmann wrote:
Jörn Nettingsmeier schrieb:
Andreas Hartmann wrote:
Joern Nettingsmeier schrieb:
i think you may be a little biased against xslts...
I used to like it a lot, and I still like it for certain purposes, but
it tends to get in your way when you try to increase the performance.
i don't really buy that argument. granted, the best way to make an xslt
fast is not to do it (again). but since menus don't change much, there's
a lot of room for optimization. i don't think menu transformations are a
performance bottleneck atm, and cocoon is all about pipeline caching.
The state of the menu items has to be computed for every request,
since it depends on the AC permissions and the current state of
the document. I don't think there's much to cache.
true. i was already dreaming of ajax :)
still, until i have run a few benchmarks, i'm not convinced that the
performance bottleneck is in the XSLT. i'd like to convert all input
module calls to NOOPs and look at the timing differences...
IMO XML is good for data, but not for the description of processes.
can't see why. can you give me an example of a domain-specific language
that can't be done in XML?
The question is not if it can be done, but if it is comfortable
to work with.
but that depends on the semantics of the language, and only marginally
on the syntax.
maybe your discomfort is caused by XSL?
much of the awkwardness of XSL comes from the fact that it's an
event-based functional language (which sure takes some getting used
to...), and that it includes a second syntax (XPath) for addressing.
it's not a consequence of the XML format it's represented in.
Our menu is a special case - it has a basic structure (which XML is
fine for), but there's some logic to control the details. We have to
find a way to separate these aspects, maybe by introducing a generic
mechanism to show/hide/enable/disable menu items.
hmm. especially for trivial things such as menu enabling/disabling,
It's not really trivial - you might have to access data about the
document, the current session etc. A simple example - you want to
enable/disable a menu item depending on the return value of a method
call. You can't do this in XSLT easily.
well, you could. saxon for instance has a very slick java extension
mechanism. but i'm not really advocating it - it would mix stuff that
should stay separate.
the way i would tackle the issue is to have a generator that exports all
needed information as XML, which should have a lot less overhead that
the 10 or so input modules we are calling now, each with the whole
avalon shebang attached to it.
with an XML snippet, it's just a matte of picking out the information,
and that's where XSL can shine.
i still believe that the fundamental interface between java core and
sitemaps should be xml, and not those many little text snippets we now
produce. that's where our complexity comes from, and i'm sure that's
also burning a lot more cycles than strictly necessary.
XML has its fields of application. But I wouldn't like to implement
an OS core in an XML-based language :)
gotcha: you wouldn't want to implement an OS core in java either. :-D
True, but that's not a pro-XML argument :)
no, it just shows that your initial point is not particulary waterproof.
you could easily express C in XML. it does not make much sense, because
the plain-text representation of C is a user-interface (the programmer
interacts with the compiler) and needs to be nice because people have to
type huge amounts of code.
if the code were machine-generated, it wouldn't make much difference.
and if you only needed short snippets of C code, it wouldn't make much
difference either.
sitemaps are small. and if they're awkward, that's because of
inconsistencies and lack of powerful control structures, not because of
its tree structure or the angle brackets...
--
Jörn Nettingsmeier
Kurt is up in heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
