Stefano Mazzocchi wrote:
[EMAIL PROTECTED]">"Robert S. Koberg" wrote:
[EMAIL PROTECTED]">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 might
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
Michael
wyona.org
[EMAIL PROTECTED]">
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 agreeSo, 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
now)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.
<DIV CONTENTEDITABLE="true">
<SPAN CLASS="title">
My Title
</SPAN>
<P>
The para text with <STRONG>bold</STRONG> and <A HREF="#">links</A>.
<P>
</DIV>
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
probably)
2) depending on the user identity, a different stylesheet is applied to
indicate the areas that are 'editable' by that user (sets namespaced
attributes)
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
page
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 and
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
either.
