Hi,
Implementing "simple" Ajax thingies in a web framework in general is no
big deal, we think we can make Ajax seemingly fit in wicket in a
generic way.
So far we are thinking of making all wicket components Ajax aware and
make them capable to write changes in a standarized way into an
AjaxResponse, with this we could have an Ajax render-phase in wich
multiple components could participate
Regards Jan Blok
Phil Kulak wrote:
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
|
