-1 for YUI. If no other WYSIWYG can be found, than I think none should be
deployed (or put the tinymce on google code too).
I don't see the issue here. RichTextArea is simply an example, its not part
of Click.
I think it should be a "complete" control (even if not part of Apache
click - due to license problems).
I think TinyMCE is the most advanced WYSIWYG right now.
I think a very important issue with these "external" packages/jars is their
version: I think their version number should be the *same* as the click
distribution that fits to.
It is just a pain in the a.. to match all the time the various component
versions with the correct framework (I'm speaking about other frameworks :),
but it looks like click is adopting the same bad strategy :( ).
Please fix this.
How do you propose we do this? Each time a new version of Click is released
we have to re-release all external packages even if they didn't change?
Yes. This can be simply automated, so it shouldn't be a problem.
On the other hand, the impact on the ease of use for your users will be
huge.
So the users would just take this as another good, simple and intuitive
"convention" (like many other click already has).
What is a bug is found in an external project? Its version will get out of
sync with Click.
No it won't be out of sync. Click changes more than anything else, so if
a bug is found
than it will be fixed in that trunk and upon next click release that
external jar will be released too.(tags should be also in sync)
Also I'm not sure if it was a very efficient idea to have so many google
projects. E.g. Wicket has one huge base: wicket-stuff that has all the
non-apache compatible things. Tapestry on does not, and it's a pain to
collect all require components.
Of course, if it's completely automated (and the automation file is
published), than it's not a big problem on how many google projects the
components are spread.
Thank you,
Demetrios.
