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. Its also because I have a requirement to use rico
and the examples are mostly dojo. 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.
I also don't like hardcoding the javascript strings into the handler.
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 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. 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,
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
