Re: using HTML editors with XSL

I have generally written my own HTML forms for XML editing.  What I do is
create a string that can be read out as XML using JavaScript, and use
something (Perl, usually, but lately saxon:output in Saxon) just to create a
file with the string in it, which is then an XML file and can be parsed.
The last version of an "editor" I did in this way creates an array of
objects in JavaScript and displays the array in a select box; users can move
elements up and down within the array and add elements using buttons.  To
write out the XML files, I loop over the array and turn the named properties
of each object into attributes, create a string and submit it via a
concealed form.  To edit XML files, I just reverse the process.  In the XSL
itself I call a JavaScript constructor each time the template hits an
element; then the attributes of the XML element become properties of objects
in a JavaScript array.  This works well in its very limited area of
application, and so far I've been building forms for specific purposes.  I'm
working on a more generalized version.  In a perfect world, I suppose the
thing would read a DTD . . . but I needed some kind of Web-based XML editor
I could configure to let users do only a limited number of things, and I
didn't know of any out there.

I can imagine creating a similar tool for your own purposes, though I
haven't thought through full-out XSL editing.  The point is that "ordinary
users" can move things around using tools like this; you could create a
relatively small set of XSL sheets that would display underlying XML, and
then users can change the contents of your  page (a lot) by using something
like the home-grown tool I've created.  At least, that's what I'm hoping
will happen in the app I'm building :)

Good luck,
Dave Halsted

----- Original Message -----
From: Aleksandrs Jakovlevs <Aleksandrs_Jakovlevs@xxxxxxxx>
To: <xsl-list@xxxxxxxxxxxxxxxx>
Sent: Wednesday, March 01, 2000 3:13 AM
Subject: using HTML editors with XSL


>
>
> I am a novice in XSL, so my questions is rather about the methodology.
>
> We want to design a system that prepares data in XML and expose it to the
> end-user by means of internet browser. It seems that optimal solution is
to
> use  XSL for this purpose. We expect to have a lot of views. BUT... there
> are a lot of professional HTML editors that allow HTML design and there is
> a lot of experienced HTML designers. These designers are not programmers.
> They are capable to design a perfect forms, colors, gifs etc. The business
> content should be provided by mapping XML on this stuff (using XSL). It
can
> be done by separate person (a programmer). He needs to embed XSL to
> existing HTML. Later HTML designer should be able to change page design
> using his tools and programmer - to update XSL (in a convenient way). They
> both are working on the same HTML page. In other words we would like to
> have XSL document consisting of two parts: HTML template and some XSL tags
> specifying where to put data from XML source. And we want to be able to
> change these two parts independently.
> I haven't seen a tool that allow to support such style of work. After
> reading some materials introducing XSL technology I have discovered that
> XSL is not exactly oriented on the proposed approach. The problem is that
> XSL stylesheet that transforms XML into HTML can not be editable by an
HTML
> editor since XSL (in general) doesn't keep structure of the HTML template
> unchanged.
> There could be several solutions:
> 1. Use some subset of XSL allowing to keep structure of the HTML template
> unchanged, e.g. use <xsl:for-each select="..."> instead of <xsl:template
> match="...">. This can make it possible to edit XSL stylesheet by some
HTML
> editor which is able just to skip unknown tags (in our case tags started
> with "xsl:"). (BTW, do you think it's possible?)
> 2. Wait for special HTML/XSL editors that will be able to restore HTML
> structure from the XSL and edit HTML template in WYSIWYG mode. (When such
> an editor could appear?)
> 3. Find out some other technology (not XSL) that is more applicable for
the
> described scenario. (Does anyone know such a technology?)
>
> Thanks,
> Alex
>
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list