Well, for 1.5 nothing is carved in stone. But I'd need to have something more specific. Concrete usecase and probably a more concrete description about how it should work. So far I only have a very vague idea.
-Matej On Wed, Aug 27, 2008 at 11:21 PM, Martin Funk <[EMAIL PROTECTED]> wrote: > 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 >>> >>> >>> >>> > >
