Matthew Langham wrote: > > > "Mozilla can now be used as a content editor" but could be "we > > have a content editor, and the code is based on Mozilla, by the way". > >. . . > > This I like. An XML Content Editor as a separate application based on > Mozilla code. > > I was pointing out that Cocoon is being widely used in environments where MS > IE is the browser running on the client - so a solution that would only run > _inside_ a Mozilla browser would lock out a lot of potential. > > Sounds like a new project to me.
This is my thinking: 1) I want an userfriendly semantic-based editing solution that *must* run on any platform. 2) I believe that browser-based inline editors provide the best solution. 3) I believe that element-granular editing behavior provides the best solution (unlike fully WYSIWYG editors like Frontpage, Mozilla's Composer or IE hotmail-like <iframe>s) 4) Currently only IE 5.5+ implements this using the contentEditable='true' attribute on every element. Mozilla has scheduled such a feature for version 1.1 to be released in July. See http://bugzilla.mozilla.org/show_bug.cgi?id=97284 [please, go there and vote for that bug so that it ends up in the tree faster!] 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. 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!) 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> 2) we have editing views in Cocoon that wrap pages using javascript/XUL/XBL things generated out of XMLSchemas that control that page. Depending on user-agent, we can *tune* the javascript on specific functionalities, just like we do for HTML style. [in case we have older browsers and no contentEditable feature is present, we have to resort back to form fields, with this architecture it's just as easy] 3) the generated controlling code is also responsible for driving the user experience and also to XML-format the results back on the form post action. 4) the server receives back a XML payload which can be fed into cocoon pipelines for further elaboration/storage/whatever. As you can see, all we need to make this possible is: MOZILLA IMPLEMENTING BUG 97284!!!!! and I'm currently working to make this possible in first person and any help will be very appreciated. -- 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]
