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 Fri, 08 Mar 2002 13:12:46 GMT
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.
<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