I don't know. I just know Dojo a little bit, and like their API. But it looks like people are more into scriptaculous. I don't know their relative merits. I'm fine with going what other people like best in this case. Or keep on supporting both, as long as I know people actually want to use it.
It looks like both libs are fine licence-wize. If someone wants to confirm that... Eelco On 9/5/05, Phil Kulak <[EMAIL PROTECTED]> wrote: > I like Dojo, actually. It's nice when you don't want a totally > out-of-the box solution. I guess I just really like dojo.bind. Does > Scriptaculous have something like that? > > On 9/4/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > I've gone ahead and implement the changes. I must take the couple of > > hours sleep I can get now, but the major changes are: > > * Got rid of interface again in favor of abstract class AjaxHandler > > (you should normally extend one of it's subclasses like > > ScriptaculousAjaxHandler or DojoAjaxHandler anyway) > > * Moved that class to the wicket package in order to hide a couple of > > methods. Wish Java had friends. > > * The binding of a component is now an implementation detail, and a > > handler instance can be bound to only one component. > > * Did a bunch of renaming to sync with some of the other changes in > > Wicket and to make the namings better in general. > > * Added a method to get the url to the handler - getCallbackUrl(); > > > > I also committed the changes for the wicket-stuff projects. Hope I > > didn't break anything. > > > > Could you guys please review the changes? Specifically I'd like to know > > whether: > > * the namings are allright; > > * you miss API stuff that would make writing your handlers easier. > > > > Furthermore, it seems that people are using scriptaculous in favor of > > Dojo. What shall we do, leave Dojo in there alongside Scriptaculous, > > or go for supporting just one flavor and leave it up to the users in > > case they want to have other support? > > > > FYI, tommorrow, we'll have two students starting with Topicus for > > their practical period of five months. Their assignment will be to > > pick up a piece of Wicket that can stand on its own. We are thinking > > about WML support, an Ajax component set or databinding. The latter is > > worked on quite a bit, so that would be a waste. Ajax is now worked on > > hard as well, but it might be a good idea to have our students > > integrate the ideas and take the time (and get much feedback from this > > list) to make the ajax handlers/ components really awesome. Or... WML > > is something we don't have yet. Is there any interest in that at all? > > > > Eelco > > > > > > > > On 9/4/05, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > > +1 for this change. > > > > > > I think it makes sense to only bind these handlers to one component. > > > > > > On 9/4/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > Btw, I plan this to be the last API change for 1.1. When this is > > > > decided and fixed, it's time to freeze the AJAX stuff. > > > > > > > > Also, the proposed change does not affect the ability to bind multiple > > > > handler instances to one component. > > > > > > > > Eelco > > > > > > > > > > > > On 9/4/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > All, > > > > > > > > > > Currently ajax handlers are 'stateless' in the sense that it is not > > > > > part of the contract on how many components they are binded. In > > > > > theory, it is possible to bind one handler instance to multiple > > > > > components. This is not done good enough currently, as onRequest() > > > > > should be changed to onRequest(Component) (where component is the > > > > > component that recieved the ajax dispatching call) to fully support > > > > > statelessness. > > > > > > > > > > I'm doubting whether this is a good idea now. I think the API would be > > > > > much more elegant if it didn't have the component arguments > > > > > everywhere, and it could have helper methods in AbstractAjaxHandler > > > > > like getCallbackUrl instead of getCallbackUrl(Component) (where it is > > > > > a question where you as the framework user would get the component > > > > > argument from anyway. Furthermore, I couldn't come up with a use case > > > > > where it actually would be really usefull to reuse ajax handler > > > > > instances between components. > > > > > > > > > > I'm about to implement: > > > > > * making ajax handlers statefull/ allways bind to one component > > > > > * removing the IAjaxHandler interface again in favor of AjaxHandler > > > > > (which is now AbstractHandler) so that we can force the rule that a > > > > > handler binds to one component only. > > > > > > > > > > Can I have your votes/ thoughts? Can anyone come up with a real-life > > > > > case where it would be good to be able to share ajax handler > > > > > instances? > > > > > > > > > > Eelco > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > > > > Practices > > > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & > > > > QA > > > > Security * Process Improvement & Measurement * > > > > http://www.sqe.com/bsce5sf > > > > _______________________________________________ > > > > Wicket-develop mailing list > > > > [email protected] > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > ------------------------------------------------------- > > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > > > Practices > > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > > > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > > > _______________________________________________ > > > Wicket-develop mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > > _______________________________________________ > > Wicket-develop mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Wicket-develop mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-develop > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
