click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Demetrios Kyriakis <>
Subject Re: Incompatibilities
Date Mon, 15 Dec 2008 13:15:04 GMT
>> 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 
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 

> A much simpler approach is to document the external project which Click
> version it depends on. You can see this very clearly
> here:
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,


View raw message