On 9/5/05, Eelco Hillenius <
[EMAIL PROTECTED]> wrote:
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
