Wow this is fast,
I'm not sure if I can keep up that pace.
Matej Knopp wrote:
I'm sorry, I don't quite get the idea. Why do you need a separate
component? And why does it need a separate session unique id?
You can take AjaxBehavior subclass (in the experimental branch) and
add it to any component. I'm afraid I don't really see the difference
between "special kind of component that requires no markup" and
behavior.
I didn't go into the experimental branch yet.
It's not at separate component, it might be a supertype, aggregating its
composite characteristic, as being addable to itself.
Separate session unique id as opposed to how behaviors currently get
their id, as an index in a sort of ArrayList in the component.
Basically when you creatively remove ajaxbehaviors from a component you
have to rerender the component too, as the id of the behaviors might get
mixed up.
You add component to parent <-> You add behavior to parent (component)
Behavior has URL, javascript can easily call the behavior.
You can't add behavior to another behavior, but of course you could
crate behavior that would contain/delegate to other behaviors to that
it would have a hierarchy.
That's what we did for the events that markers on a gmap could emit.
Without the hierarchy though.
But I'm lazy, I think the framework should provide that.
What I want to know is what exactly is wrong with behaviors and what
custom "component type" could do that behaviors can't.
It might boil down to the hierarchy aspect of the idea. Stacking up
'JavaScriptComponents' on the server without any bounds to any markup
and let the framework do the housekeeping of stacking em up in the
browser and the communication to the server.
So much from me for now & and be patient with my response pace,
Martin
-Matej
On Wed, Aug 27, 2008 at 10:31 PM, Martin Funk <[EMAIL PROTECTED]> wrote:
Hi Matej, hi list,
I just saw the page that Matej added to the wiki, so I thought it might be
wishing time for improving Wicket Ajax now.
My wishes are somewhat vague, but I just don't wanna miss the wishing window
:-)
Sven and I have been happily coding on wicket-contrib-gmap2, which also
shows just about our level of understanding the wicket and ajax space. At
least mine, Sven is probably fare ahead of me.
So coding on that, I came to think, if we have a chance to get something
like a JavaScriptComponent with the following capabilities:
It should be addable to a component, just like a component.
It should be addable to other JavaScriptComponents.
It should not need any markup.
It should carry its own session unique id.
It should have its own callbackurl
Adding it should result in an instantiation of a JavaScript object on the
browser side.
This JavaScript object should have the capabilities of sending a basic
XMLHttpRequest to its corresponding java-object using the callbackurl.
Adding or removing either one of them should result with the same effect to
the other.
I'm not quite sure if this draws the picture I'm thinking of, or if asking
this is getting to carried away from wicket and introduces complexity that
can't be handled. Though I have the feeling wicket is not to far away from
it anyway.
To me it looks like mixing capabilities of component with capabilities of
AbstractAjaxBehavior.
Sorta make em AjaxBehaviors full members of the component hierarchy and
loosen on Components need for markup.
OK the infrastructural JavaScript object providing the basic protocol
between the two halves of the object does not exist yet.
But if that could be accomplished quite a door could be opened (or the box
of Pandora)
Subclassing JavaScriptComponent wouldn't be trivial as you'd have to come up
with JavaScript code too.
Though this would lay a good basis for handling the js-object on the browser
communication to the server side. So you would not only be able to add the
nice goodies to the browser but also get a basis for letting the server know
of any events on the browser.
Any other thoughts on this?
Martin
BTW. there is still an issue on behaviors open
https://issues.apache.org/jira/browse/WICKET-713
