there will be browser based javascript generators.
So a default one and one per browser instance that can override specific
things.
johan
Gili wrote:
On comment: how are we going to begin handling browser-specific
bugs, compatibility, etc in Wicket core components? I'm sure when you
begin playing around with AJAX you will begin running into more and
more of these problems if you haven't already. Is browser-specific
rendering something we handle indirectly in components or something we
can in a more formal manner?
Gili
Johan Compagner wrote:
Hi,
this is what we should have as soon as possible if i am tasting the
area here around JavaOne.
What i call ajax rendering is this, a component knows his state (much
more then it did now!!) and if
he sees a change in his request he will print this out as a
javascript statement that will be send to the browser
and executed with eval()
I will get this javascript of the ajax enabled components on a ajax
request after dispatching to the listener first.
(just like a normal doRender after a component listener call)
So what we don't think we want is subclasses every component that we
have now to get ajax rendering on it.
Because then if you want to use a component that you want to tweak or
implement like a link you have to subclass
2 components the normal one or the ajax enabled one.. So you have to
choose at that time what you want..
What we could do is add 3 methods to Component:
1> final public setAjaxRendering(boolean)
2> non final protected createAjaxRenderer() returns a instanceof a
yet to make interface IAjaxRenderer
3> final public getAjaxRenderer() returns the instance that was made
by 2 or null..
that interface can or will have the following methods:
render() The render method that is called when it should render
itself through an ajax call
setCssId(String) // this is really needed because if the component
doesn't have a css id then ajax rendering will be disabled
setVisible(boolean) // component.setVisible() will redirect its
boolean to this object if it has ajax rendering because the component
must render itself, but be made non visible at the client side..
setModelValue(Object value) // ajax rendering will cost more. Because
we have to track changes so that we can generate the right javascript
statements on the server to send to the client.
setStyleClass(String) the style it should use (for example an
TextField could have a normal style and a error style (field turns red))
And i think there will be a lot more set methods for all kind of
properties. We just have to figure out how for we want to go..
Component should bne altered a bit:
by it rendering (real rendering) it should look for its Tag's
attribute map and set the cssid to the above implementation of the
IAjaxRender because
the css tag is specified in the html (maybe we should be able to
generate or alter them if css tags are in a listview/repeating
components)
als the setVisible method should test for the ajaxrenderer and if it
is there it shouldn't set its own visibililty flag but redirect that
to the ajaxrenderer
So that the component will render itself (and then set though some
css class or javascript to non visible) so that we can alter its
state afterwards
(set it visible, set its value)
So when this is in place this happens if a ajax call is coming in:
the event is dispatched.
then all the components are visited and if they have a ajaxrenderer
call render on it.
the components checks if he has changes that he should set to the
browser (like the model value: document.getElementById(cssid).value =
xxxx)
what all the components did return is send to the client and with a
simple javascript eval evaluted and everything is updated.
2 things to look for:
1> we must have a javascript generating class that generate above
pieces of code (i already had some prototype checked in)
2> for example that value =xxxx a few lines above... that xxxx what
is that? Normally the value could go through converters/formatters etc.
And how do we get the model object there. how to really test for a
change.....
any comments?
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
