You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@click.apache.org by Bob Schellink <sa...@gmail.com> on 2009/07/15 00:56:17 UTC

Re: Update RichTextArea example

I still think Nicedit would make for a better example than YUI. It loads quite a 
bit faster because its packaged in two resources (one js, one css), while YUI is 
packaged in 13 resources.

regards

bob


Malcolm Edgar wrote:
> On Mon, Jul 13, 2009 at 6:00 PM, Adrian A.<a....@gmail.com> wrote:
>>> What is the issue with the YUIRichText editor? Size or dependencies?
> 
> I am not sure if size should be a constraining factor for a RichText
> editor, as the resources should be compressed when served, and then
> cached on the users PC. With RichText editors they are not controls
> you would put on your home page.
> 
>> Size, dependencies, complexity.
>> Even if it's a quite well documented library, users find it quite complex.
>> For the WYSIWYG, I see that people still prefer TinyMCE.
> 
> Unfortunately TinyMCE has an incompatible LGPL license
> 
>> For JS libraries in general, after the first WTF (because of the unusual
>> approach), most users I've worked with find jQuery the most productive (but
>> it has also the biggest number of books too :) ).
>>
>>
>>> but the potential issue we have
>>> with JS libraries is that the runtime environments (browsers) are not
>>> stable, and can necessitate constant maintenance of the libraries.
>> I'm aware of this problem, but since JS is the only "spice" for the web
>> right now,
>> IMHO there's not much we can do. Minimizing the use of JS in Click would not
>> be a very smart option since the direction of all frameworks (and user's
>> request too) is for more JS: and even the browser support goes in this
>> direction - see the JS threads, and JS engine performance increases of the
>> newer browsers.
>>
> I am not saying don't include JS, just we need to take care selecting
> libraries which are actively supported as web browsers are constantly
> changing: IE6, IE7, IE8, FF, Safari, Chrome, etc.
> 
>> Adrian.
>>
>>
> regards Malcolm Edgar
> 


Re: Update RichTextArea example

Posted by Bob Schellink <sa...@gmail.com>.
Sorry ignore, sent to wrong list :)


Bob Schellink wrote:
> I still think Nicedit would make for a better example than YUI. It loads 
> quite a bit faster because its packaged in two resources (one js, one 
> css), while YUI is packaged in 13 resources.
> 
> regards
> 
> bob
> 
> 
> Malcolm Edgar wrote:
>> On Mon, Jul 13, 2009 at 6:00 PM, Adrian A.<a....@gmail.com> 
>> wrote:
>>>> What is the issue with the YUIRichText editor? Size or dependencies?
>>
>> I am not sure if size should be a constraining factor for a RichText
>> editor, as the resources should be compressed when served, and then
>> cached on the users PC. With RichText editors they are not controls
>> you would put on your home page.
>>
>>> Size, dependencies, complexity.
>>> Even if it's a quite well documented library, users find it quite 
>>> complex.
>>> For the WYSIWYG, I see that people still prefer TinyMCE.
>>
>> Unfortunately TinyMCE has an incompatible LGPL license
>>
>>> For JS libraries in general, after the first WTF (because of the unusual
>>> approach), most users I've worked with find jQuery the most 
>>> productive (but
>>> it has also the biggest number of books too :) ).
>>>
>>>
>>>> but the potential issue we have
>>>> with JS libraries is that the runtime environments (browsers) are not
>>>> stable, and can necessitate constant maintenance of the libraries.
>>> I'm aware of this problem, but since JS is the only "spice" for the web
>>> right now,
>>> IMHO there's not much we can do. Minimizing the use of JS in Click 
>>> would not
>>> be a very smart option since the direction of all frameworks (and user's
>>> request too) is for more JS: and even the browser support goes in this
>>> direction - see the JS threads, and JS engine performance increases 
>>> of the
>>> newer browsers.
>>>
>> I am not saying don't include JS, just we need to take care selecting
>> libraries which are actively supported as web browsers are constantly
>> changing: IE6, IE7, IE8, FF, Safari, Chrome, etc.
>>
>>> Adrian.
>>>
>>>
>> regards Malcolm Edgar
>>
> 
>