Ugo Cei wrote:
>
> Just to refresh the thread about blogging, that seems to be languishing,
> I would like to point you to my recent blog entries:
>
> http://www.beblogging.com/cocoon/mount/beeb/20020302-112015
>
> and
>
> http://www.beblogging.com/cocoon/mount/beeb/20020304-142853
>
> Would anyone care to comment?
I've discovered xmlwebgui last week and played with it. I really like
the 'in-place possible choices' that it gives you (presenting the
internal xerces DTD representation translated into javascript, very cool
indeed for that little amount of code!), but the user interface is
really horrible. I mean: it's *way* faster to write xml in a big
textfield.
But the direction is the right one, I would say.
I still believe that mozilla is the way to go for web-based editing...
if only it was possible to write XPCOM components in Java :( Sure, it's
planned but don't know where it will land.
The thing is: Mozilla lacks 'contenteditable="true"'... this it the
problem: sure, you can do two things:
1) transform the DOM element into a textarea and back (but you loose
editing structure, unless you *explicitly* indicate the markup inside
the text area ---> BAD, UGLY, only techny will use it!
2) write a javascript-based "contenteditable" clone (which was posted
on this list a while back) using a *fake* caret built with CSS-ize
single characters --> HACK, SLOW, looks terrible!
Currently, mozilla has 'gecko' which does the rendering and 'editor'
which does all the text-editing stuff. I'm not sure *how* they got them
working together (I *hope* they didn't write two different rendering
systems!!!), but they should allow us to define (via an attribute, like
IE5.5+ does) to turn on the rendering system *right there*, just on the
places we want this operation to be turned on.
Why so?
well, mostly because the mozilla composer turns javascript off during
composition... thus, you need to use XUL <editor> but this is nothing
different from IE's <iframe> that Radio uses (and HotMail and so on),
but all the editing is there and all the rest is outside.
Editing granularity is simply too coarse.
It's all or nothing solution and it might work for weblogs, but for sure
it's not a solution that could scale to higher editing needs.
I would like to have the granularity to say 'this is editable' (say the
latest log in your weblog columns) but the rest is not... right there!,
no need for text fields, no need for weird things. Just *write* on your
page, like you would do on paper!
But with the extra plus of having your web page *tell you* where you
should be writing stuff and where you can't because either you are not
allowed to (because of your role: this is a must in workflow-based
editing environments, this empowers SoC!) or either because it doesn't
make sense (and the web designer doesn't want you to change things
around).
Moreover, having element-granular in-place editing, allows javascript to
remain on while the page is edited, because the javascript becomes part
of the 'structure' that guides your editing, unlike in the <editor> or
editing <iframe> where *everything* is editable, even the attributes...
but you normally don't need to edit attributes in those cases, only
change the text fields or add new elements.
Anyway, I'm about ready to dive into the mozilla code to add something
like this because I need it *very* badly, if you want to join, email me
privately.
--
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]
