That's not just submitting the form onChange(), is it? I'm talking about calling a specific component in the tree with an xmlhttprequest which can then write arbitrary character data to the response. Sorry if I'm not getting what you were trying to point out.
-Phil On 7/19/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > The basic functionality, being able to easily add an ajax call back, is > allready there. Take a look at FormInput in HEAD, and uncomment the one > commented line, and see where it takes ya. Our goal with Wicket is to > really have it integrate well. But that's a tough one. > > Eelco > > Phil Kulak wrote: > > >Okay, here are my thoughts: > > > >We don't have to make it this complicated. To get this all working we > >only need two things. The component needs to contribute JavaScript to > >the header (done), and it needs to respond to a request from said > >JavaScript. That can be done by merely adding an IAjaxListener. Let > >the component designer worry about how he/she actually wants to > >implement it. I think we can build a system where components re-render > >themselves and automatically fill themselves in on the page, but we > >need the basic functionality too, right? I mean, what if I don't want > >to ship the entire HTML for a component over the wire and instead send > >one char to indicate that JavaScript should do something elaborate? I > >should be able to do that, and that's what's most easily supported by > >Wicket. I say, get that working, get some cool AJAX components > >written, and then worry about getting really fancy. > > > >-Phil > > > >On 7/19/05, Jan Blok <[EMAIL PROTECTED]> wrote: > > > > > >>Hi, > >> > >>I think we dont have to have observers on models, in many cases the it > >>very expensive to retrieve model values > >>If we mark a component as being dirty with a rerender() method (aka > >>repaint() in swing env., I called this "invalidate" in previous post) or > >>let the component call rerender() himself when significant change has > >>happened on him (like visible), in an Ajax render phase we just collect > >>the changes from the dirty components (or all if the page is marked dirty) > >> > >>Jan Blok > >> > >> > >>Eelco Hillenius wrote: > >> > >> > >> > >>>As for the models, as long as we have an observer pattern implemented, > >>>it is up to the model implementation how and when observers should be > >>>notified. > >>> > >>>Eelco > >>> > >>> > >>>Johan Compagner wrote: > >>> > >>> > >>> > >>>>most db driven models don't know if they are dirty or not > >>>>For this kind of thing the developer itself can say invalidate > >>>>youreself (the component or maybe say it to the model) and render again. > >>>>Because i know or think you are changed. > >>>> > >>>>You also have non db models (the non detachable once) and that one > >>>>can set the dirty flag by firing a property change where the > >>>>components who has > >>>>that model are setting the dirty flag) > >>>> > >>>>then the question is should there be some automatic part where wicket > >>>>as a framework guesses now it is time to do the complete page render > >>>>or this component (that is backup by a database/detachable model) > >>>>render. > >>>> > >>>>johan > >>>> > >>>> > >>> > >>> > >>> > >>>------------------------------------------------------- > >>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > >>>from IBM. Find simple to follow Roadmaps, straightforward articles, > >>>informative Webcasts and more! Get everything you need to get up to > >>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > >>>_______________________________________________ > >>>Wicket-develop mailing list > >>>[email protected] > >>>https://lists.sourceforge.net/lists/listinfo/wicket-develop > >>> > >>> > >>> > >>------------------------------------------------------- > >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > >>from IBM. Find simple to follow Roadmaps, straightforward articles, > >>informative Webcasts and more! Get everything you need to get up to > >>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > >>_______________________________________________ > >>Wicket-develop mailing list > >>[email protected] > >>https://lists.sourceforge.net/lists/listinfo/wicket-develop > >> > >> > >> > > > > > >------------------------------------------------------- > >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > >from IBM. Find simple to follow Roadmaps, straightforward articles, > >informative Webcasts and more! Get everything you need to get up to > >speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click > >_______________________________________________ > >Wicket-develop mailing list > >[email protected] > >https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Wicket-develop mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-develop > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
