> Lon Boonen wrote:
>
> This is my first post to a mailing list ever. So if I am breaking some
> rules please forgive me.
No problem. Just make sure you don't use HTML in your emails posted here
(see my previous message for why this is not considered polite)
> > Voted! 41 votes so far.
>
> So if I hurry I could be number 42!!! That would be great!
>
> >
> > > 5) Xopus uses contentEditable="true" as a in-place editing
> > widget and
> > > adds a layer of driving logic based on client side
> > XML/XSLT/XMLSchema to
> > > implement MVC. This is a possible solution but, for sure,
> > not the only
> > > one. The same processing (creating a editing controlling
> > javascript for
> > > the page) can be done on the server side. No, Ugo, we don't
> > need to do
> > > it on the client side.
> >
> > As long as the number of roundtrips from client to server is
> > kept to a minimum, I agree with you.
>
> I disagree. The experience will not be the same for the user.
> As a user you want to move on with your work. If you change structure
> and click in some title to edit its contents you do NOT want the page
> to reload, loose your focus and throw away the few characters you may
> have already typed in.
No, of course not. I was implying that you should be having a round-trip
to the server for each and every editing operation. No, that would be
totally horrible and would definately loose the benefit of a
browser-based inline editor.
> >
> > > Also, I believe that there is no need for XSLT on the
> > client side (CSS
> > > styling is enough for most inline editing needs, since the
> hard-core
> > > transformations normally don't happen at the content level
> > but at the
> > > page structure level, which is normally *never* edited this way!)
> >
> > Of course.
>
> Of course NOT.
Easy, Lon. No need to be that raw.
> XSLT is for now one of the best and most used ways of transforming XML
> to something else, most likely HTML.
>
> If you want a truely WYSIWYG editor, as I do, then you will need to
> support XSLT in it.
>
> Furthermore. Apart from editing I really want XSLT on the client for
> viewing/transforming pages!
> I want pages that are dynamic. DHTML lets me do this only partly and
> only after a lot of coding.
> If you have XSLT on the client it is easy to get new content from the
> server and transform it to fit into your page.
> DHTML isn't really dynamic until you have XML/XSLT on the client.
I dare to disagree with you here.
I was, for sure, impressed by the use of XML/XSLT/Javascript all
together on the client side but I'm not sure you need that much power in
order to provide a fully WYSIWYG solution.
My previous point was: the parts that you normally edit in the page are
*not* so complex that you require incredibly difficult transformations.
In fact, difficult transformations are *NOT*, in general, reversible.
But please, this is the old XSL vs. CSS debate over again and I think
it's pointless to discuss it here.
I honestly don't care *how* an XML-based inline editor is implemented as
long as:
1) is fully WYSIWYG (means no layout limitations)
2) is fully portable (means it runs on every platform/OS)
3) is fully customizable (means that can everything can be generated on
the server side depending on the request)
4) is light and fast (means also reduces round-trips and the editing
experience is nice)
Apart from this, I really don't care how it ends up working.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
