Please don't get me wrong. I don't say we shouldn't support behaviors and the idea itself. But may be we can improve the implementation required to support it.
a) Remove IBehaviorListener from Component and implement a request target which does the same (should be simple refactoring). And move Component.urlFor(IBehaviourListener) to AbstractBeahviour. This way we put the code where it (IMO) belongs Currently every WebComponent and WebMarkupContainer implements IHeaderContributor and IBodyOnLoadContributor. The Component implementation of these interfaces iterators of all attached behaviors. That is necessary to support behaviors which implement IHeaderContributor. But is also the reason why the header support is currently a performance hot spot. What about an additional list of behaviors associated with Page which maintains only behaviors which implement IHeaderContributor. The constructor of AbstractBehavior could register itself with the page in case the bahavior implements the interface. That should have the same net effect and might not need any changes to existing code. Juergen On 1/23/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > Supporting both means more or less to keep it the way it is, no? > > What do other people - especially the people that worked with ajax and > Wicket - think about this issue? > > Eelco > > > On 1/23/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > i think we should support both.. > > > > Because i can think of complex things that you just have to do it as a > > component. > > But simple things (ajax validation?) can be behaviours... > > > > johan > > > > > > > > On 1/23/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > > I first played a bit with AjaxHandler but found that I basically build > > > an AjaxHandler hierarchy next to the Component hierarchy because each > > > type of Component required specific extensions to the AjaxHandler *if > > > I wanted to use wickets core components* (extensions for autocomplete, > > > drag&drop, counter etc). And I found a general DojoAjaxHandler which > > > does hardly more than initialization in combination with extended > > > components which add the <divs> and modify the attributes less useful. > > > I guess you have to decide between an explosion in AjaxHandlers or > > > Components. Though I guess what you say is true for validators. > > > > > > Juergen > > > > > > On 1/23/06, Eelco Hillenius < [EMAIL PROTECTED]> wrote: > > > > I appreciate the search for simplifying our Ajax support. What I like > > > > about the sandbox code is that it uses a request target to do the job, > > > > and that the request and response are seperated. What I don't like > > > > about the sandbox code is that it puts the whole ajax thing back into > > > > the normal component hierarchy again (which is exactly what Johan's > > > > idea was at first). Sure that's easier/ more elegant to implement, but > > > > it also means that you are bound by inheritance. So you can't 'enrich' > > > > a component with ajax behavior, but instead have to pick a specific > > > > component that supports that ajax behaviour. An example of where this > > > > would be good to have is validation. Typically, you should be able to > > > > pick any form component and attach an ajax validator to it. No matter > > > > whether it is a checkbox, a normal textfield, or a custom text field. > > > > With your sandbox code however, I would need a seperate ajax component > > > > variant for each form component, and if I use custom textfields, I > > > > would have to make sure they extend the right ajax component. > > > > > > > > So I think behaviors are still the way to go for ajax. The problem is > > > > that almost everyone that build ajax components so far circumvented my > > > > intend and made them full fledged components instead of behaviors. > > > > That's a clear indication people find it easier to work with > > > > components for implementing ajax. > > > > > > > > I think it comes down to a couple of pros and cons. For the idea of > > > > implementing ajax as full fledged components instead of behaviors: > > > > > > > > Pros: > > > > * easier to implement new ajax components > > > > * those components are probably more elegant, and certainly the fact > > > > that components don't have to play dispatcher for behaviors is more > > > > elegant > > > > > > > > Cons: > > > > * less flexible to use as you have to use inheritance instead of > > composition > > > > * potential explosion of the number of components > > > > > > > > For me the cons outweight the pros. Which doesn't mean I think there > > > > is nothing to be improved, but I just still believe in ajax behaviour > > > > instead of components. > > > > > > > > Eelco > > > > > > > > > > > > On 1/23/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote: > > > > > wicket-stuff contains wicket-contrib-dojo and > > > > > wicket-contrib-dojo-examples which implement various Dojo (ajax) based > > > > > textfield autocompleter and (ajax based) drag&drop examples. I > > > > > reviewed these examples because I felt that ajax support could be > > > > > better, easier to understand, more obvious. In case you are > > > > > interested, my ideas are in wicket-sandbox. > > > > > > > > > > Cornerstones of the implementation > > > > > a) does not use AjaxHandler and IMO is easier to understand (less > > > > > magic). IMO we should remove IBevaiorListener completely and remove > > > > > IHeaderContribution from AjaxHandler and all the required code which > > > > > is necessary to support it. > > > > > b) introduces InterfaceRequestTarget to define a request target based > > > > > on an Interface which must implement only one method. Your component > > > > > must implement the interface > > > > > c) It defines an IAjaxListener (event listener) and IAjaxResponder > > > > > (request target) which defines the necessary listener/render pair for > > > > > ajax requests > > > > > d) Either by means of extending InterfaceRequestTarget or directly in > > > > > the IAjaxResponder method it is now very easy to put an envelope > > > > > around the response as required by e.g. Rico. > > > > > > > > > > May be you'll find some time to review it. I'd appreciate any > > feedback. > > > > > > > > > > Juergen > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > > files > > > > > for problems? Stop! Download the new AJAX search engine that makes > > > > > searching your log files as easy as surfing the web. DOWNLOAD > > SPLUNK! > > > > > > > http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642 > > > > > _______________________________________________ > > > > > Wicket-develop mailing list > > > > > Wicket-develop@lists.sourceforge.net > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > > files > > > > for problems? Stop! Download the new AJAX search engine that makes > > > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > > > > > http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642 > > > > _______________________________________________ > > > > Wicket-develop mailing list > > > > Wicket-develop@lists.sourceforge.net > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > > files > > > for problems? Stop! Download the new AJAX search engine that makes > > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > > > > http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642 > > > _______________________________________________ > > > Wicket-develop mailing list > > > Wicket-develop@lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642 > _______________________________________________ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
