Thomas Comiotto wrote:
i don't know xopus, but i think all editors could be rewritten not to
duplicate aggregations and transformations from the publication - by
delegating it. every editor is free to apply another post-processing
step and tweak the content as it wants (see tiny again: the rendered
page from the publication sitemap is augmented with the necessary
javascript snippets).
No. Every web-based visual xml editor I am aware of is driven by some
sort of xml-to-xhtml mapping (the rest does raw document styling by css
and direct xml processing - see BXE 1). BTW I guess you would want xhtml
editors to operate on the raw source.
but they do. tiny does, fck does as well. with xhtml, the "raw source"
is almost what people want to see, plus some css.
tiny just delegates the rest of the page rendering to the publication so
that the surroundings (navigation, tabs, etc.) look right without code
duplication. bxe does unspeakably ugly things to achive the same goal
(or maybe it's just our integration...).
if an xml editor wants to work on the source, it can. but if it forces
me to re-write my existing transformations in weird ways to cater to
editor oddities (once for every resource type), then i'm not going to
use it.
For the xml-to-xhtml variants the content server has to provide what's
needed to build the corresponding map. This is usually xslt data (XOpus,
BXE 2, Yulup) for doing a xml-to-xhtml transformation whereas xslt's are
not only used for rendering the corresponding page (what you would like
to delegate to the server) but also for back-propagating modifications
from xhtml to xml.
well, i still don't really buy that "visual xml editor" thing... it may
work for presentation-centric markup with a dash of semantics here and
there, but never for generic xml with lots of data and heavy semantics.
if you can say it in xhtml, it's probably boring in xml >:->
What's needed is a simple and possibly standardized way of generating
xslt's required by those editors out of what's already in use in the
xhtml rendering pipelines.
could work for xslt simple xslt.
but not for other transformations, such as i18n, uuid or proxy. at that
point it's easy to introduce just one more kludgy hack, and then the
number of hacks rises exponentially and you introduce N custom
re-rendering mechanisms of what the presentation already does, where N
is number of doctypes times number of editors you need to support...
<rant>
and that's where i'd rather give up the shiny visual-ness and confront
the users with the true nature of what they are dealing with: semantic
markup that is only marginally presentation-orientated.
after the initial shock, they will produce better markup that with a
what-you-see-is-what-i-thought-you-meant-or-what-you-thought-looks-good
interface.
i still think the best approach to arbitrary grammars is automatic form
generation (but then i've tried that and accepted defeat for now).
</rant>
are you experimenting with lenya 2.0 already? let me know what kind of
xslt data you need and how, and i'd be very happy to try figure out
elegant ways of providing it. i'm just saying that there is a point
where the tradeoff between visual-ness and kludge turns bad...
regards,
jörn
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
