>> 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.
> Sure but first somebody needs to step up and create the control and project.
> In case somebody is interested
> I've added our old TinyMCE example to ClickClick.
Good to know.
> 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).
> Sorry to me that is more confusing. Having versions bumped without making
> actual changes seems weird.
No, for the user it is not confusing. It's the same thing like with the
controls
distributed with Click too: even if they don't change, they still get an
updated "version" by being in that jar (or extras jar). I think the same
should be true for the "external" jars too. The automation would ensure
that it's not more work: there are even ANT tasks for SVN and SSH
operations.
> A much simpler approach is to document the external project which Click
> version it depends on. You can see this very clearly
> here: http://code.google.com/p/click-calendar/
No, it's not. Somebody needs to write that, keep it up to date (and this
often doesn't happen), and the users also need to read it(they usually
don't - they just ask all the time), than do it: it's just too much work
for everybody where automation could simply do everything: the users
would not even notify that those are external.
> Users can also use Click's get-deps task to pull down the latest version of
> of click-calendar.
Advanced users yes, but not many of them. I like get-deps allot, but I think
an automation would be even better (it would be anyway for the
"building", not for the "getting" part)
> 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.
> Wicket-stuff is in constant flux so I don't know why you bring this up as a
> good example.
That "constant flux" is because it's also a "sandbox" with no
separation. Click on the other
hand already has a clearly separated sandbox directory, so it wouldn't
be that messy.
> Initially I wanted to integrate calendar with ClickClick but it is not
> maintained currently so was too much effort. Hence
> the calendar specific project was created.
>
> Keep in mind there are only two projects: calendar and charts.
With ClickClick there are 3, and there's allot of duplicated information :).
> And I'm not
> sure how popular the chart controls are.
I used them in several projects, and they're very simple and easy. Of
course, I think there are many missing features, but they're very
practical for nice "dashboard" pages (the first users get after login)
of many web 2.0 apps.
Thank you,
Demetrios.
|