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.
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. What I want to know is what exactly is wrong with behaviors and what custom "component type" could do that behaviors can't. -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 > > >
