click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Demetrios Kyriakis <demetrios.kyria...@gmail.com>
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 
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.


Mime
View raw message