Am 22.08.13 11:25, schrieb Bernard:
Hi,
On Thu, 22 Aug 2013 11:21:41 +0300, you wrote:
On Thu, Aug 22, 2013 at 11:08 AM, Emond Papegaaij <
[email protected]> wrote:
snip
The mismatch is in the fact that the PageParameters object is stored with
the page while it resembles the parameters the page was created with. If
a page changes (for example, by updating its model object), the
PageParameters no longer match with the state of the page. That's why I'd
rather not store them in the page at all but recreate them when needed.
I don't see why Page's parameters should be related 1:1 to page's model.
The parameters are just the data that has been provided for the page
construction. Nothing more.
Later they could be used for url generation or not.
The page may use some of the parameters to create its model or not.
snip
I can see Martijn's point, and if one defines this as a convention, as
it already is, then no more confusion.
But I think it is a good concept to generate PageParameters from the
state of the page.
... which can be complicated if you want to preserve any state of your
page in an external representation through page parameters. I had build
something like that and it was a pain (did this for SEO)...
It would be good practice.
.. i am not sure about that.
I already use public
static methods MyPage#createParameters(MyEntity something) which
encapsulates this so my page instance would just call the static
method with the parameters from the state of the page.
So how could this be enforced? The framework could insist on
overriding such a method if it detects a PageParameters constructor.
.. sometimes you do not want to present internal state.
Unfortunately that constructor is abused at the moment. See
WICKET-5069.
It would not be performant so caching would be needed.
Perhaps update the instance var pageparameters with the result of a
getPageParameters() call on modelChanged()?
I think we mixing different kind of things here.. If you can externalize
the state of a page into a page parameter string representation, then
your page does not have any state. Every link on such a page should be
therefor a BookmarkablePageLink with an different set of page parameters
which describe the transition to a different client side state. You must
then redirect every form submit or non-bookmarkable links to a page with
page parameters describing the new state. This way there will be no
PageExpired exception.
This way you use wicket as a component based page renderer.. which is
ok, but not a strength of wicket.
We can make it easier to provide classes and functions if this is what
you want. But i fear that there is not the one solution, because there
are often very surprising requirements.
Michael:)
