cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <>
Subject Re: [RT] what cocoon forms lack
Date Fri, 10 Oct 2003 08:33:16 GMT
Le Vendredi, 10 oct 2003, à 10:21 Europe/Zurich, Stefano Mazzocchi a 
écrit :
>>> ...I dislike "textarea" as a style if an string input field. it 
>>> doesn't feel right: a textarea is the style of an editor....
>> OTOH being able to edit (wiki-like?) text from a plain textarea must 
>> be possible as a fallback for when people don't have the right 
>> browser, mobile stuff, etc. It is certainly easy to do but must be 
>> taken into account.
> Sure. but you missed my point. The critic was not about "HTML 
> textarea" but about where the "textarea" concept resides on woody. 
> Today, woody believes that textarea is a "style" of a string input 
> widget. I dislike this. I think "textarea" is a "mode" of a 
> yet-to-be-there editor widget, exactly for the reasons you mention 
> above and because widget should be separate for their use, not for the 
> output they create.

ok, got it now ;-)

>>> ...In linotype you have Wysiwig and markup, introducing a wiki mode 
>>> is in my todo list.
>> Do you envision a server-side format converter for this?
> no, client-side. I plan to write javascript to do this, so that I'm 
> able to move back and forward from a wiki view, a markup view and a 
> WYSIWIG view from the client side.

Why not server-side java?
Is it a design or implementation concern?
Client-side avoids a round-trip but introduces client dependencies 
which could be avoided.
And being able to write pluggable format converters in java for 
Linotype editing would be cool. Not sure about javascript.

>> ...I'm asking because a good birdirectional wiki-to-xhtml conversion 
>> component in java would be very useful. The current chaperon stuff 
>> doesn't provide this.
> a javascript wiki2xhtml parser would be just as functional and can be 
> used on both sides (even if would require some tricky things, since in 
> the client side the dom is already there, exposed)

hmm..back to DOM server-side?
(but if you're writing the code and I'm not, who am I to argue ;-)

>> ...I like this - if this is used for our docs later on, being able to 
>> cut/paste wiki stuff in and out would be very useful for offline >> work.
> yep, the gt-notes-editing experience showed me this as well!

I'm glad to hear this!


(trying hard to get back to this bread-and-butter stuff ;-)

View raw message