cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Wechner <>
Subject Re: Wyona / Xopus (IE vs.Mozilla)
Date Sun, 10 Mar 2002 17:39:29 GMT

Stefano Mazzocchi wrote:

>"Robert S. Koberg" wrote:
>>I thought Xopus uses an ActiveX to control the editing. 
>No, it's everything javascript based (with calls to MSXML)
>>I could not even see their pages
>>because I don't not browse the internet with them on anymore (especially
>>sites made by guys like you :)
>Exactly, ActiveX is potentially too dangerous but no, they don't use
>this technology and nobody is planning to use it.

Well, no, Xopus is actually using a little bit ActiveX, but just for the 
Autosave mechanismn.
The rest is Javascript and MSXML.

But for professional authoring and editing you definitely need an 
autosave function.
("Newspaper editors" just dont't use the save (in between) button. I think
they actually ignore it on purpose:-)

There is a config parameter where you can tell Xopus how often it shall 
do autosaving
(e.g. every 60 seconds), and Xopus is saving the XML on the server and 
the client.
To save it on the client Q42 implemented it with ActiveX.
No matter how you implement this functionality, you are going to need 
it, because
the network could go down or the server is down or whatever. And you 
can't tell the
"newspaper editor" to stop editing just because the network is down at 
the moment
and there is too much risk that he/she is loosing the content.

I don't know any other technical solution at the moment, but anyway, it 
be a good idea to have a light and a fat version of Xopus.

One last general remark:
I think all of you are too much concentrated on how to implement this 
stuff technically.
It is actually already implemented! Maybe not too good and not on Mozilla.
What I want to say is, that we should more focuse on functional 
specifications, which
certainly doesn't forbid to vote on fixing bugs (which I did), but which 
will be the
foundation for the implementation.

All the best


>>>I fully believe that once mozilla implements contentEditable that can be
>>>controlled via javascript, the rest is just a matter of writing the
>>>DHTML (or, even better, XUL/XBL-based pages) that drives the process.
>>>I've done it for IE and it's not that hard.
>>>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!)
>>Yes, totally agree
>>>So, the best solution I see is:
>>> 1) both IE 5.5+ and mozilla 1.1 implement something like
>>>  <div contentEditable="true">
>>>   edit text here...
>>>  </div>
>>This won't work unless you have extremely simple DIVs. 
>This was only an example. And, BTW, I think you could do *very* powerful
>semi-structured editing with just <div> and <span>
>>What happens when
>>you want to edit bold text or a link in the DIV? 
>Via javascript. You can either have:
> 1) keyboard shortcuts (CTRL-B for bold, contentEditable does this
>automatically and also places 'semantic' tags in there! <strong> instead
>of <b>, <em> instead of <i>)
> 2) floating toolbar with buttons (you could do it with an
>absolute-positioned <div> with draggable controls, or with a frameset
>(LIME does this), or with reactions on other parts of the same page)
> 3) context menu (right-click and follow the menu, Xopus does this right
>>By setting
>>contentEditable to true at the DIV level everything that is not
>>explicitly set to contentEditable=false will be editable. 
>Yes, this is a feature, not a bug. It's up to the server to generate a
>page with contentEditable set to true *only* in those parts which should
>be editable by the current page-requesting user. Ranging from *none*
>(reading user) to any level, due to workflow constraints.
>>And wouldn't you want this? E.g.
>>    <SPAN CLASS="title">
>>       My Title
>>    </SPAN>
>>    <P>
>>       The para text with <STRONG>bold</STRONG> and <A HREF="#">links</A>.
>>    <P>
>I would use
> <div>
>  <span class="title" contentEditable="true">My Title</span>
>  <p contentEditable="true"> the para text with <strong>bold</strong>
>and <a href="#">links</a></p>
> </div>
>>Or are you saying you make editable 'islands' on the page set of by each
>>styling of a XML content piece into an editable DIV?
>That could be possible as well even if currently CSS isn't supported
>enough to style an XML document to every required layout, so I'm
>thinking more of something like this:
> 1) there is an XML document on the server (stored in an XML database
> 2) depending on the user identity, a different stylesheet is applied to
>indicate the areas that are 'editable' by that user (sets namespaced
> 3) the editing-enabled stylesheet turns those attributes into the
>contentEditable flags to true in the locations indicated
> 4) the page contains javascript that is capable of creating a semantic
>XML tree back from the editing process when onSubmit() is called on the
> 5) the server receives the XML document, validates it and, if valid,
>stores it into the database
>[the validating javascript might be generated by XSLT-transforming  the
>XML schema of the document!]
>I'm working for a demo to insert into the Cocoon samples, maybe working
>on top of Jeremy's <slash-edit/>
>>A serendipitous feature I have noticed is the ability to cut and paste
>>from a text, html, Word (etc) doc. The IE browser parses it (sometimes
>>for a long time...) and throughs it on the page as best it can. You just
>>need to know what it throughs down and parse/freshTrip it back to your
>>XML strucutre and send it to the server.
>It's entirely possible to have javascript that 'repairs' this pasted
>dirty HTML by crawling the DOM and removing/adapting things (like
><b>-><strong>, the remouval of Office PIs, remouval of <font> tags
>the like) LIME does this.
>>One other thing:
>>MACR is about to release the next version of Flash with much better XML
>>parsing speed (better than v.5). You *could* create a one pixel flash
>>movie and use that to control logic, flow, aggregation on the
>>client-side. [just joking :)].
>Well, since this flash-based logic would need to be automatically
>generated from the server, I'd much prefer a javascript solutions where,
>at least, the transmitted content is not binary!
>Moreover, this doesn't fix the rectangular content-editable problem

View raw message