There's definitively some nice idea's in that. One of the things for
1.1. is to more clearly define our request processing cycle. We need
that for JSR 168 support too. I guess Wicket's cycle looks much like
what you described, though it is largely non-formalized (which is a bad
thing btw). Here is my big but: how are you going to support the back
button at all?
Eelco
Michael Jouravlev wrote:
I don't quite get the reason for having *any* information in the
"render request" or how do you call it. You refresh a whole Page, so
unless you use Ajax, you have to render all components on a page. Page
is identified by URL, like /forminput. Is not this enough?
I tried to read wiki on request/responce cycle, but probably I was not
reading thoroughly enough. Let me tell you my approach in my small
Struts addon, so maybe you could explain me Wicket approach in the
same terms.
First off, I use the same two-phase request processing (aka
POST-redirect-GET) in my project. I have three modes:
=== cut here ===
* component initialization event prepares component for use with new
set of data;
* user input phase accepts input data, updates domain model, generates
error messages;
* view rendering phase generates a result page.
Request/response cycle looks like this (POST request is discussed, but
I am going to make a change and treat any "non-clean" GET, that is GET
with parameters, as POST).
Submit event is dispatched to a corresponding handler method. The
hander validates input data and perform model update if needed. In
case of error, the handler saves errors in the session and redirects
to the same page. This is called "component reloading". (Actually, I
do not use term "page", I prefer "location" which can serve different
pages, or "action" in Struts terms).
Reloading does not cause infinite loop, because request for data
submission has POST type, while redirected request for action
reloading is automatically converted to GET type. GET request does not
cause component reloading. Instead, on receiving GET request, a view
is rendered.
If no errors were detected and location can render a view for new
component state, then component can be reloaded. Otherwise, control is
handed over to another location.
When a user refreshes a page, location/action/whateveryoucallit
displays a view appropriate to component state.
A special init key parameter must be used to initialize and reset a
component. This is necessary because otherwise there would be no way
to distinguish the following events:
* use the component with fresh set of data;
* navigate to component using a link;
* refresh a component explicitly;
* automatically reload a component as the second phase of input processing.
Initialization event allows to reset the component for new set of
data. Three other events: linking, refreshing and component reloading
are treated the same, and render a view, corresponding to current
component state. That means that navigating to a component via link
displays current state of component, but does not initialize it.
=== cut here ===
This is how I do it. So, a simple empty GET means "render yourself". I
don't get, why rendering request has reference to IRedirectListener
*after* redirection already occurred?
Also, what else can you do besides processing input and rendering a
page? It would be much simpler, if all POST requests and all GET
requests with parameters would be considered as "input" requests, and
"clean" GET would be considered "render" request, would not it?
On 7/12/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
you could encrypt every url then all urls look like this:
http://www.wicket-library.com/wicket-examples/forminput?s=xdfadfljkasdfhasldfh
that null point should be catched some how but what would you like to do?
return to the calling page?
that interface=xxx is needed because that is the action we call on the server
side..
johan
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
