Humm...I can think of a few requirments and potential issues and these
would depend, in part, on how wicket would implement and support ajax. I
it will depend in part if wicket chooses to do a complete ajax solution
where all rendering and views are ajax driven or if it is some sort of
hybrid that keeps the current WebPage concept and mixes some ability to
selectively update some content on the page but where page to page viewing
would still remain as it is today.

I'll throw out few thoughts:

1) How wicket supports javascript and css maybe different for an ajax
implemention vs the way wicket currently works. With ajax you have the
ability to add/edit/remove selective parts of the DOM. Typically, css and
javascript "HEAD" resources are not updatable in the DOM (I dont think).
So css would need to be embedded directly into the components "style"
attribute, so that when a component is updated/removed/added the css and
javascript is self contained in the html element itself.

2) Basic ajax concepts - Javascipt DOM engine that can update
components/elements in the DOM based on server response. JavaSciprt
messaging engine that communicates with server.

3) Server-side logic that can figure out what component(s) have been
modifed (change events) and send back to the server only those
component/elements that have changed.

4) Each component (HTML element) will need a unique id so that it can be
referenced in the DOM, for example, remove or replace an
element/component. These ids will be referenced both on the client and the
serveran will be needed to allow the server to know what html elements
need to be updated on the client browser.

5) Typically, with ajax apps, you don't have back button type capability
(you typically don't want it for the most part). So some of the features
in wicket that deal with back button concepts and such may be impacted or
at least no longer of importance?

6) HTML debugging. With ajax apps it is harder to debug the generated
HTML. So it would be important to build debug capaiblity to allow the
developer to see the HTML going back and forth from browser to server
(like echo2 does).

7) With ajax http posts can be sync or async. Allow for an hourglass type
metaphore if server request/response exceeds 2 seconds for example.

Just as reference, echo1 has a very robust framework and rich set of
components and for the most part echo2 (new ajax version) is a complete
rewrite. The one thing about echo is that it lends itself to ajax more
than other frameworks because it is more component centric than most web
frameworks. echo looks and behaves like java/swing so going to ajax is
very natural for it.

One of the nice things about wicket is that it allows content designers to
work with plain html and I am not sure how that would be impacted when
moving to ajax. This could be a critical issue. I am thinking that content
designers would focus more on component HTML design instead of "page"
design. And navigation would be more fluidly defined and defined somehwere
between the java code and high level HTML page definitions if that makes
any sense.

Sam

>
> do you have any thoughts on a list of requirements for ajax support?
>
> [EMAIL PROTECTED] wrote:
>
>>It has been stated by others on this list and I see it on the proposed
>> 1.1
>>features, but I would like to stress that supporting "AJAX" should be the
>>highest priority for wicket.
>>
>>I believe that wicket has solid advantages over Tapestry/Struts/JSF,
>>however, what will really turn interest toward wicket, and make it stand
>>out from the crowd, would be solid support for AJAX.
>>
>>Take a look at what echo is doing:
>>http://www.theserverside.com/news/thread.tss?thread_id=32834
>>
>>The echo demo really shows the advantages of Ajax for "web applications"
>>in particular. Echo2 is very nice but it is highly application and
>>programmer centric, which is nice for web apps with complex state that
>> are
>>not easily modeled with "html pages".
>>
>>Sam
>>
>>
>>
>>-------------------------------------------------------
>>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-user mailing list
>>[email protected]
>>https://lists.sourceforge.net/lists/listinfo/wicket-user
>>
>>
>>
>
>
> -------------------------------------------------------
> 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-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>



-------------------------------------------------------
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-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to