click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <malcolm.ed...@gmail.com>
Subject Re: Update RichTextArea example
Date Sun, 12 Jul 2009 23:02:13 GMT
What is the issue with the YUIRichText editor? Size or dependencies?

Regarding the project size, a small team is not necessarily a problem
if the product is stable, e.g. OGNL, 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.

regards Malcolm Edgar

On Mon, Jul 13, 2009 at 6:53 AM, Adrian A.<a.adrian.tech@gmail.com> wrote:
>>> This is how most of the very good quality software is - with only one
>>> main developer
>>> that does most of the work and keeps the "vision".
>>
>>
>> Interesting viewpoint although not something I subscribe to myself. In
>> software projects, if the knowledge and load isn't shared, there is always
>> the risk of the main developer losing interest and the project becoming
>> abandoned.
>>
>>
>>> When the team is big, the software is bloated too, and just plain
>>> mediocre :).
>>
>>
>> I don't buy this either. The team is normally big if the scope of the
>> project is large. That is why its important to pick software that fits the
>> problem space. If all you need is a servlet engine use Tomcat or Jetty. If
>> you need all the features of a Websphere, well then that is what you should
>> use.
>
> I mean the above for open source projects (not commercial - there, it's a
> total different story).
> Because of the "democracy"-like approach of "leading" projects, in the open
> source scene, one can usually see two approaches for "big teams":
> 1. - least common denominator is adopted for features/architecture
> 2. - everybody has it's own "pet" functionality that don't really fits with
> that of others.
>
> #1 and #2 make in most cases the projects bloated, as opposed to small
> projects that are much more coherent and uniform (but with the danger of
> being later abandoned).
>
> I could give you many many examples for each category, but it would not
> be nice here :).
>
>>> It's here:
>>> http://svn.nicedit.com/trunk
>>
>>
>> Ah, it doesn't seem like they link to it from their site though?
>
> The site is not quite coherent, and the forum is also quite spammed, but
> the information is/was there in the WIKI I guess.
>
>> Scanning their repository it seems the last commit was 6 months ago?
>
> Yes.
>
>>> I'm not sure if Roller is the best example :).
>>> http://www.bileblog.org/2007/03/here-we-go/
>>
>>
>> Xinha is just a Javascript editor, independent of Roller.
>
> Yes, I know that :). I mean that they're not the best example for "feature
> decisions" :).
>
>> I'm mentioning Xinha because its also released under an Apache compatible
>> license.
>
> It's size nears the size of the actual YUI (so there's no reason than to
> change at all).
> The idea of Nicedit was it's size - that it's much smaller in first place.
>
>> Please note, I'm not arguing for or against Nicedit or Xinha. Only that we
>> understand the risk of including these libraries with Click because once we
>> ship them we have to support them.
>
>> And if the JavaScript library becomes abandoned we might end up having to
>> replace them, which is a pain as was the case with
>> JSCalendar/CalendarDateSelect.
>
> An approach for this general problem could be to adopt another naming for
> the components, e.g.
> to have the javascript framework name in the component naming too, e.g.:
> YUIRichText, NiceditRichText, TinyMCERichText, JSNameXxxx, etc.
> This way, there's no naming and compatibility problem, cause adding a new JS
> library to replace an old one, would allow to have both in parallel (with
> deprecation), and if users still need the old one, they can invest in
> updating the corresponding Javascript.
>
>
> Adrian.
>
>

Mime
View raw message