cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Wyona / Xopus (IE vs.Mozilla)
Date Tue, 12 Mar 2002 22:30:40 GMT
> 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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message