Thanks for joining in. Btw, anyone who reads this is more than welcome
to participate.
I don't think rendering just the component that receives the ajax call
suffices. The first use case we would like implemented is ajax
validation. This should work with the least possible effort. Code could
look like:
RequiredTextField integerTextField = new
RequiredTextField("integerProperty", Integer.class);
integerTextField.add(new
ValidationEventRequestHandler("onchange"));
add(integerTextField);
where ValidationEventRequestHandler is the ajax part.
The thing is that triggering a validation could have an effect on the
rendering of a whole bunch of other components, the most obvious being
components that use feedback messages, like FeedbackPanel and
FormComponentFeedbackBorder. We strife to have the same net effect with
ajax on your page as you would have doing a full page render, thus those
components should be re-rendered when there is new feedback. And this is
just an example, because any ajax action could trigger a whole lot of
component changes, from visibility changes to maybe even replace calls.
We need to be able to regconize which components should be re-rendered,
and collect the render results, send that to the client, and interpret
that again to merge in our page.
Big question is: how do we implement this the least intrusive way, so
that users can keep on using Wicket as they have done before, but are
able to use ajax when they want without having too much knowledge about
it. Also, when we would be able to reuse our normal render process,
creating new ajax behaviour would be just as easy as creating normal
Wicket components. That's the target. Next Q is the 'how' :)
Eelco
Michael Jouravlev wrote:
On 7/13/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Done (at least the draf) is the ajax handler stuff. To be done:
- implement the model observer pattern;
- implement a mechanism that allows components to indicate that they are
'dirty'/ should be re-rendered;
- decouple the current rendering process so that components can be
rendered on their own;
- implement a render collection mechanism e.g. in the abstract ajax
handler class. implement making a message of it, sending that message
back to the client, and implement applying the changes to the page.
On 7/18/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
I think the concept of rendering a whole page as one continues process
has to go anyway. Each component should be able to render just itself,
and the rendering of the page is just rendering all the components.
I would like to chime in, maybe you find some useful ideas in the
approach that I use now. First of all, I use JSP. Second, I tried my
components with Ajax, and they work in "render HTML mode", see below.
So, here is the idea.
First, non-Ajax mode.
A page consists of [probably independent] components. A component can
receive input, in this case it is rendered on HTML page as an HTML
form (or several forms). A component considers every POST as input; as
well as GET with parameters (in case of Wicket probably a GET with any
parameters except system parameters like component or whatever). GET
without parameters is considered as "Render yourself" phase.
When an HTML form corresponding to a component is submitted, the POST
request is sent to the component itself, not to the page that contains
it. This way, a page does not even know what components it consists
of. This is easy for JSP, just use <jsp:include>. I am not sure what
mechanizm can be used in Wicket.
After component updated its status, it redirects (here is the trick)
to the page, which contains it. The page is then loaded by browser
with GET, which means "Render yourself". Page pulls other components
with GET as well, and they render themselves. Simple.
For non-Ajax mode, it does not matter if a page consists of one
component only, or of several components. The name of master page is
set in configuration file, so a component does not know where it
redirects to.
Now, Ajax mode.
There are two choices: return rendered HTML or return some fancy
XML/DOM data. If an Ajax component can simply render itself by
returning HTML, then designing non-Ajax and Ajax components is
downrigh easy. For Ajax, a component should redirect to itself, which
would force it to render itself immediately. Master page is not
changed.
If component should return more advanced DOM data for Ajax mode, then
components should be Ajax-aware and to return different response for
Ajax and non-Ajax mode.
Wrapping up, there are two tasks:
* where to redirect in case of non-Ajax and Ajax;
* what to return in response.
Umm, that is all ;) just some raw food for thought :)
Michael.
-------------------------------------------------------
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
