could be nice yes.
Another thing i think of is having "SingletonPage" in the session. So that a bookmarkable link always goes to the same
page if there is already one there in the page mape (stored with the mount url instead of path=x)
Then every other kind of link or form can generate the mount url als there url where the do there get/post request to.
Then the url stays the same even if you click on a link or submit a form.
Of course users have to give is a hint that that page can be used that way (because this is not possible/wanted in all cases)
with a marker interface or something.
johan
On 12/3/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Hi, answers below
>
> http://localhost:8081/quickstart/app?bookmarkablePage=com.theoryinpractice.testapp.pages.CommentsPage
>
> Is there a way to get the app to resolve the above using something like:
>
> http://localhost:8081/quickstart/app/page/Podcomments
>
> or even
>
> http://localhost:8081/quickstart/app?page=Podcomments
>
Yep there is, but I just killed it in HEAD to do some rethinking. You
could register aliases for classes which would then be used (so
support for the second case).
The rethinking is:
- is this for pages only, or is it more general (answer is yes,
because we want to use this for packaged resources too).
- do we want the class/ alias mapping, or do we want to support other
cases like the packages you suggest.
- how are we going to name it
But it'll be in there again shortly when we have answers to those
questions... probably this week. I think in 1.1 it is called pageAlias
in Application somewhere. One of the examples uses it.
You first approach is supported in the HEAD version now.
> Or maybe theres something already in wicket for more REST like URL schemes?
> I notice in the basic framework there's only a BookmarkablePage extension of
> Page, is there something in wicket-stuff maybe?
>
You mean REST like encode everything that has to do with state in your
url? Well, yes and no. In head we provide the option of 'mounting'
paths to bookmarkable pages (or actually in at a lower level, you
could mount any request target you want). The example we are working
on that shows this is wicket.examples.niceurl in the wicket-examples
project, and it lets you use Wicket with URLs like
http://localhost:8080/wicket-examples/niceurl/path/to/page2/param1/value1/param2/value2
where path/to/page2 is the mount, and param1 and param2 are the page parameters.
Currently, I am also working on abstracting the session even more and
trying to defer creating an actual httpsession object (the default
store for Wicket WebApplications) until it is absolutely needed.
The interesting thing here is that as long as you have a bookmarkable
page with nothing on it that points back to that page, there shouldn't
be a need to put it in the session. So, if I pull this off, it means
that you can create completely stateless applications. Of course that
won't help you with creating the kind of applications Wicket was
targetted for in the first place, but it is a nice optimization and
extra usuability I think.
I you /do/ have call backs like forms etc, we need to store that page
in the session - at least temporarily - in order to call the
approariate methods on the target components. In that case, you
application is not REST. And personally I don't agree with the REST
thing for web applications anyway (and I'm in the web CBD/
Continuations camp for that matter), as the original concept of REST
works fine for document centric view of the web (you know, the way it
all started) and can even work for web apps that have a very direct
1-1 relationship with requests (i.e. they are relatively simple), but
not for the kind of applications that people expect to work nowadays.
And the guys from the web mvc camp... they are not exactly following
the REST approach as it was intended either. Anway, big sidestep... I
am getting almost emotional about defending against REST and
stateless-ness as it seems to be a pavlov reaction for people to think
that that is the only way to do your web applications :)
Eelco
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
