Good point. I'm currently working on it. Juergen
On 1/23/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > I already thought about this.. (adding the only needed behaviours to the > page (or panel?) itself) > > Then there is only one (small) list that needs to be iterated at once. > > But we need to check for things that don't keep hanging around. For example > containerremove(child) > > if the child itself or the childs of the child did contribute something to > the page it has to be removed also. > > > johan > > > On 1/23/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > 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?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
