On 1/23/06, Jim McLaughlin <[EMAIL PROTECTED]> wrote: > I've just started working with this and have a lot of interest in how > this will develop, but I don't know enough as of yet to contribute at a > high level to this discussion. But here are my thoughts so far: > > I stayed away from the AjaxHandler all together. This is largely because > the examples are mostly about effects and I need component level > rendering right now.
Just call Component.doRender() whenever needed. Though the ComponentRequestTarget is the better choice if a single component must be rendered. But, if for example you need a MultipleComponentTarget it would simply call doRender() on each component. > Its also because I have a requirement to use rico > and the examples are mostly dojo. Should matter much. Just create you RicoAjaxHandler to cover the Rico related stuff. > The ajax prototype example fit exactly > what I needed -- rendering a component directly by calling a Link. I can > see this working well with Form.onSubmit also. I like this because you > stay within wickets standard event handling framework. > see the ajax prototype example. It does exactly that > > I also don't like hardcoding the javascript strings into the handler. > only needed for component derived from WebComponent. Not needed for WebMarkupContainers. WebMarkupContainer will read the associated markup if it exists and just take the <wicket:head> part for the header contribution. Components inside <wicket:head> can be added with add(whatever). > This might be more of a personal preference issue. I decided to do this > with xslt because it seemed like a natural fit -- wicket is markup based > and xslt is commonly used for code generation from markup. I also have > some complex javascript requirements. However, I think for most people > xslt will make a hard problem harder. Velocity or freemarker might be a > better fit, but they will need to take nested components to make this > work. Either way, an external javascript parsing/rendering process will > be a big improvement. > I'm not an javascript/ajax expert but I agree that the javascript I've seen in the dojo example seem to the very "dynamic". What I means is the javascript is just a few lines but in each line 2 placeholders must be taken off. This is not what Wicket has been designed for. But using velocity or any other template engine doesn't seem to be the best choice either. > I'm thinking the AjaxHandler pattern should be more Adapter, and less > Decorator. This way it seems you get the best of both worlds. Kind of > like a Border, an AjaxAdapter would contain a component or components. > This way you keep the composition idea embodied by the current > AjaxHandler (but inverted), you can implement interfaces the > RequestTarget might require in a way that doesn't create a new hierarchy > for "standard" components, and allows multiple component rendering in > one request, which is currently difficult. no, very easy. Component.doRender() > This works great for me > because I am using panels with xslt behaviors to generate the > javascript, so in a sense I am already employing this pattern. > thx for you feedback. It is always welcome. Juergen > thx, > jim > > > Eelco Hillenius 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?cmd=k&kid3432&bid#0486&dat1642 > > > > ------------------------------------------------------- > 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&kid=103432&bid=230486&dat=121642 > _______________________________________________ > 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
