Hmm.. I could briefly describe it.
The interaction is done in two phases.
1. Input phase
The url looks like this
.../library?component=5.border.navigator.navigation.1.pageLink&version=0&interface=ILinkListener
The parameters here:
- component
path to the component, that is a target of link action
"5" means page with id "5", border.navigator...pageLink
specifies the component on that page
- version - page version
- interface - specifies the function that will be called
on target object
each of this interfaces (ILinkListener, IFormSubmitListener)
contains only one method. That's the one that will be called.
Depending on rendering policy, the actual rendering can be done here as
well (but it's usually stored in buffer). This is because of hibernate
lazy binding, if I understand correctly.
2. Render phase (after redirect)
...library?component=7&version=0&interface=IRedirectListener
- component - ID of page that will be rendered
- version - desired version (version=0 could be hidden, IMHO)
- interface - usually IRedirectListener (also could be hidden, I think).
So basically the render url could be reduced to something like this
...libery?component=7
Please correct me, if I've written anything wrong. I think something
like this should be in wiki. But I don't dare to add it due to my lame
english :)
If you wonder why in library example when you click on page 2 or page 3
the url is so long, it's because that switching pages is done in one
request only. But it should be possible to do it in two request (with
redirect)
-Matej
Michael Jouravlev wrote:
On 7/13/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
We could get rid of the interface=IRedirectListener and if a request is
made for:
http://www.wicket-library.com/wicket-examples/forminput?component=0&version=0
then that IRedirectListener is implied.
But getting rid of component=0&version=0 is a bit more difficult
Because we need to know what component is called for forminput and what version
there is.
only this:
http://www.wicket-library.com/wicket-examples/forminput
returns just the homepage of the forminput application.
So after forminput you could have all kinds of pages. Of course we could see if
we can make
this cleaner like:
http://www.wicket-library.com/wicket-examples/forminput/component0-version0
or
http://www.wicket-library.com/wicket-examples/forminput/page1_version0
So that we can construct it again.
Would that kind of url be better??
Johan, I started to work with Wicket only yesterday, so I am still
learning the concepts and reading the code. I am sure I will
understand why all this stuff is present in render request. But maybe
you could explain it in layman terms?
I understand that version=... helps to create page versions, besides
some other task that it may have. I do not have clear understanding
what other parameters are for. In the above example, what does
"/forminput" define? A page? I mean, a Wicket Page? If yes, then why
do you need any other information besides page name (or class name) to
render a page? Putting Ajax aside, you render a web page as a whole,
so you need to render Page object as a whole. Why would you pass any
parameters to components or a component on a Page when you render it?
I still cannot grasp it.
Wicket has input phase, where parameters are passed, and model is
updated and components are updated. Why you cannot stick all
parameters there? You said that you "need to know what component is
called for forminput". But why do you need this on render phase,
instead of input phase? Wicket reloads page even if I click on a link,
not only for submit buttons, so I do not see a problem to have a clean
URL. What do I miss here?
I read some docs yesterday, but did not find an answer. I need to look
at the code more closely, I guess.
Michael.
-------------------------------------------------------
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
