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