yes.
Chris Turner wrote:
I think you need to consider the whole picture together. Ajax puts some pretty intensive requirements on javascript and css. I think if we just do css/javascript without considering the requirements of ajax then there is agood chance we have to come back and do some major refactorings when we want to support ajax. I'm not saying that we must do ajax at the same time as css/javascript just that we understand what support Wicket will be offering for ajax, what requirements this will have and make sure that we don't preclude ajax support when (if) we are ready to do it.
regards, Chris
Jonathan Locke wrote:
css and js are not markup languages. but, yeah, those seem like prerequisites to me too...
Gili wrote:
Won't AJAX discussion become a lot clearer once we add support for CSS/JS markups in Wicket? My point is, shouldn't we focus our discussion on those dependencies before AJAX?
Gili
Chris Turner wrote:
As Sam says, I think so much of it depends on how far we want to go on ajax enabling Wicket. I think if we were to just say okay, wicket has hooks for ajax, bolt on your own implementation then that might win us some points - and we could provide our own implementation if we wish. If however we want to make Wicket a 'kick-ass' ajax platform then the changes need to be much more integrated and thus wicket needs to be ajax enabled, not ajax neutral. Remember, ajax is not a standard or a protocol or anything, it's just the XmlHttpRequest object, a bit of css, lots of javascript and some server-side framework. All of these things exist already and can be used by anyone who is skilled in these technologies. I could probably even build an ajax application using the existing wicket framework, a bit of javascript and my own ajax enabled server classes if I wanted. In my opinion what ajax support is all about is making it as easy to use ajax as wicket makes it currently to build page based web applications.
Thinking of a typical ajax type application: tax calculator
First question is a drop down: Employment type: Employee / Director / Self Employed / Partner
Selecting something from the list changes all of the rest of the components on the page.
Filling in income and expenditure figures automatically rountrip on each value so that a running tax liability total is constantly updated
To build an app like this I should just be able to create a few wicket components on a page, indicate which should fire ajax events and what listener should handle each event and write the event handler - that's it. I then just write some simple HTML markup and my wicket app is up and running. This is what echo2 is trying to give (but with a number of weaknesses IMHO). I would want wicket to be that easy. I don't want to write any javascript, deal with messaging protocols, integrate third-party libraries, need to worry about page state and so on. However, to achieve this wicket needs to be as closely bound to ajax messaging as it currently is to the servlet specification and protocols. Then at the same time I also need the hooks so that I can add my own ajax aware components as well.
regards, Chris
Jonathan Locke wrote:
it's a tight binding between client and server, yes. but there doesn't have to be a tight binding between wicket internals and ajax does there?
i guess what i'm thinking is that if we provide the hooks to do the stuff below and start another project "wicket-ajax" that provides ajax support as an add on, then someone else can come along and decide we did it all wrong and start over with all this protocol and update plumbing. by doing a little extra work to keep wicket more ajax-neutral, we could allow people to have ajax engines that work with wicket which are quite different from our own.
which of the things below cannot be done via API hooks?
Christopher Turner wrote:
Jon,
I'm not sure there is such a thing as an 'ajax engine' in the way you are thinking. By definition ajax is most likely to be a very tight binding between client and server. The concept of 'ajax' beings together css, DHTML, javascript and web application framework into one amorpheous blob. You could of course make ajax talk standard protocols on top of HTTP (such as SOAP, REST or even some binary protocol if you wish). However, the further you move towards a generic engine the more and more complex Javascript you end up needing - and the worse the debugging nightmare becomes! Looking at echo2 they have implemented their own proprietary XML protocol optimised for communicating between the echo synchronization manager and the echo server components. I think we will probably need to do something very similar for Wicket. I would certainly expect any framework claiming to support ajax to abstract me as far as possible from neeing to implement any procotols or requiring complex javascript development where I only wish to use pre-existing components.
My thoughts on the subject so far have been along the lines of:
1) Wicket components generate events. These events currently invoke a URL (either directly or via submitting a form). With AJAX you would also need to make these components capable of making an AJAX request (and possibly increase the amount of events they can generate - but most of this is done by implementing the appropriate javascript onXYZ handlers)
2) When a Wicket component makes an AJAX request is talks to our client-side AJAX engine and submits details of the event. If we adopted XML messaging like echo2 then the message from client to server is something like:
<wicket-event> <component id="0" name="actionLink"/> <version>0</version> <interface>ILinkListener</interface> </wicket-event>
3) At the server end the request cycle detects the difference between a URL event and an AJAX event, works out what to do, finds the page and invokes the appropriate component listenet.
4) Components process themselves in some way or other
5) The server side AJAX handler works out what has changed and builds the appropriate response message to send back to the client.
6) An AJAX response is returned to the client. There are two main possibilities of what could be supported (we would probably need to support both):
a) replace the inner HTML of a particular DOM element with the new HTML content sent in the AJAX response. (One response could even send multiple new HTML content blocks). I would suspect the standard Wicket components would possibly work this way - it's what the echo2 components do
b) invoke some javascript code in a library to process the payload of the response (e.g. do transformation, run custom or complex logic). This would allow people to develop their own client-side heavy ajax components where needed.
I think where the above approach wins over something like echo2 is that Wicket would be able to seamlessly combine both the Page concept with the AJAX concept. That way people could use one page and ajax entrely right through to having many pages and just use ajax for the very complex or interactive ones. This overcomes many of the issues that have been highlighted with echo2, in particular the ability to bookmark a page and the ability of search engines to index an echo2 application.
From my inversigations so far don't feel that a web framework such as wicket can support ajax as a sort of 'optional extra'. Implementing ajax support in a way that makes it easy to use for the majority of developers requires a really tightly bound and invasive approach to pulling all or the requisite parts together.
Regards, Chris
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Jonathan Locke
> Sent: 04 April 2005 17:57
> To: [email protected]
> Subject: AJAX Support in 1.1 (was Re: [Wicket-develop] CSS
> resource files?)
>
>
>
> i don't know ajax super-well yet, but i think our approach in
> integrating ajax into wicket is going to be taking the same
> approach as
> we've taken with every other technology used in wicket: find
> the minimum
> building blocks to put into the core and then let everyone build
> whatever they want on top of that. you've identified a couple of
> important building blocks from the programmer's perspective:
>
> - requests to re-render components causing client-side dom updates
> - requests to components for arbitrary, dom-updating javascript
>
> however, i don't necessarily think even most of this is
> really wicket's
> business. there's this "ajax engine" that lives on the
> client and talks
> to the server. that's more of a technique than a specific technology
> right now and i imagine there will be a /lot/ of ajax engines
> out there
> and very little standardization. this is the web, after all! so i
> think to support "ajax" and implement something like client-side dom
> updates, wicket needs to delegate all of the ajax / JS work to people
> that are working on ajax engines by providing them the right
> integration
> hooks. wicket needs to provide a hook, for example, that
> will re-render
> a component. that would be core to wicket's support of ajax in
> general. it also needs to provide componentized JS support
> because JS
> is core to ajax (although JS is also core to other things, so our JS
> integration needs to be pretty generic). on the other hand,
> how an ajax
> engine interacts with the DOM on the client side and how
> requests from
> an ajax engine are processed on the server side is really pretty far
> outside the scope of wicket.
>
> so long as a given ajax engine can implement a server-side stub that
> adds ajax special sauce to wicket components easily, i think we're in
> the right ballpark. although ajax is exciting, we want to be very
> careful not to overreach in terms of wicket's scope. as i say in the
> wicket vision statement, wicket is about "enabling
> component-oriented,
> programmatic manipulation of markup". wicket is not an
> all-encompassing
> presentation layer technology. and i think it's probably not an ajax
> engine. i want wicket to stay focused and not drift off course to
> slowly become something else. losing focus is a great way to fail.
>
> so i think wicket ought to let you work with any 3rd party
> ajax engine
> and not tie you to one in particular. i think it's okay if there's a
> little glue that has to be written for each ajax engine that
> works with
> wicket, so long as wicket itself doesn't need to be modified
> to do it. > from the sound of it, this synchronization manager you're
> talking about
> is really part of an ajax engine and therefore should not be part of
> wicket. we provide nice component objects in wicket that work with
> markup. decorating those with JS synchronized ajax is the
> business of
> an ajax project, not wicket.
>
> all this said, i think we can provide all the necessary hooks
> to create
> advanced ajax engines, including engines that have features like the
> echo2 synchronization manager. and probably a lot of things
> we haven't
> thought of yet. as someone at sun used to say "innovation happens
> elsewhere". we need to take that to heart in wicket and let ajax
> innovation occur elsewhere and leverage it via integration.
>
> if you think i'm wrong about this, please argue with me/us. > at wicket,
> we're always open to discussion!
>
> jon
>
> Cameron Braid wrote:
>
> >I'd be keen to find out more about the AJAX expreiments. I've been
> >looking at the echo2 source code - they can dynamically update any
> >component using JavaScript + XmlHTTP. One way is by fetching the
> >latest HTML for the component from the server and replacing
> it into the
> >current DOM. However they have implemented a Syncronization
> manager > >that allows the components to sync them selves however they
> see fit -
> >i.e. you could render the component's state to a javascript literal
> >then build the new html on the client etc..
> >
> >I would like to know the direction that wicket is likely to take to
> >support this style of integration.
> >
> >Cameron.
> >
> >
> > > >
> >>-----Original Message-----
> >>From: [EMAIL PROTECTED]
> >>[mailto:wicket-develop- [EMAIL PROTECTED] On Behalf Of
> >>Eelco Hillenius
> >>Sent: Monday, 4 April 2005 6:21 PM
> >>Cc: [email protected]
> >>Subject: Re: [Wicket-develop] CSS resource files?
> >>
> >>See the wiki:
> >>http://wicket.sourceforge.net/wiki/doku.php?id=user:include_
> css_refere
> >>nces
> >>_for_components
> >>for one way to do this.
> >>
> >>And if you *really* need to include dynamic CSS, take a look at how
> >>the guys from DWR (http://eireneh.thorubio.org/dwr/) do it.
> Basically,
> >>the include *.js files in their generated pages, but then at the
> >>server side, they interpred the js request, and generated
> the contents
> >>on the fly. You could do the same with Wicket, by using
> resources. In
> >>fact, I think Johan is playing with this right now for his
> - private -
> >>AJAX experiments.
> >>
> >>Eelco
> >>
> >>Gili wrote:
> >>
> >> > >>
> >>> I tried using class Label to construct the CSS statement
> >>>dynamically, but Label escapes HTML reserved characters so that
> >>>method does not work...
> >>>
> >>> Eelco, how are you handling this problem...?
> >>>
> >>> > >>>
> >>-------------------------------------------------------
> >>SF email is sponsored by - The IT Product Guide
> >>Read honest & candid reviews on hundreds of IT Products from real
> >>users. Discover which products truly live up to the hype. Start
> >>reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click <http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click>
> >>_______________________________________________
> >>Wicket-develop mailing list [email protected]
> >>https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >> > >>
> >
> >
> >
> >-------------------------------------------------------
> >SF email is sponsored by - The IT Product Guide
> >Read honest & candid reviews on hundreds of IT Products from real
> >users. Discover which products truly live up to the hype.
> Start reading
> >now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click <http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click>
> >_______________________________________________
> >Wicket-develop mailing list [email protected]
> >https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >
> > > >
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from
> real users. Discover which products truly live up to the
> hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396 <http://ads.osdn.com/?ad_id=6595&alloc_id=14396>> &op=click
>
> _______________________________________________
>
> Wicket-develop mailing list [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
