On 8/12/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
> 
> > In SignIn example link look like this: <a href="signin">signin</a> As
> > you can see, there is no additional parameters, it simply navigates to
> > signIn. WebRequestCycle considers this link as a homepage, and calls
> > setResponsePage(homePage). At least in this case Wicket does not
> > create a new instance. But in case of bookmarkable page Wicket calls
> > Page newPage =
> >   session.getPageFactory().newPage(pageClass,
> >   new PageParameters(getRequest().getParameterMap()));
> > which is not exactly what I want. But I have not gotten there yet, so
> > I cannot tell for sure ;-)
> >
> Going to a home page That is what that href does that only goes to a
> home page
> Then a new page is created yes. But that is the thing that get's hit
> from outside youre webapplication
> I only talk about things when youre are inside youre web application.
> Those links in Page X or Page Y are controlled by you.
>
> Bookmarkable pages or HomePages are just entry points to start a wicket
> session, start a page
> and go forward from that point on. (and then you are in control of the
> complete flow)

I talk about both. I started from a simple example. Now after you
mentioned that a page is created for outside call only, I may have
less desire to change this behavior. I would say, that maybe it is ok
that home page gets clean and empty each time you navigate from
outside, but nevertheless I want to have option to keep whatever
information it had if the session is already established. Also,
creating new page instance eats up memory and I dont get the point why
old instances are not deleted.

> You could create youre own PageFactory, but i guess you want to have a
> Session Pagefactory.
> Not an application page factory. Don't think that is possible right now.

I have not digged that deep yet, I just call newPage :) I will look up
further in the code.

> > Link class in just an abstraction. It all boils down to a good old
> > HTTP/HTML. Wicket parses a regular HTTP requests, which does not know
> > about Link objects. I already gave you example of start page in SignIn
> > example, the page is pure HTML.
> >
> > Before creating my own Link objects, I need to understand how Wicket
> > parses request parameters.
> >
> > But you are right that in the end of the day I will have to create a
> > Link, which will generate proper <a href> for me.
> >
> >
> 
> Ok but if you want to give parameters from outside youre webapplication
> directly to a page inside
> youre webapplication then you can use bookmarkable urls:
> 
> <a href="signin/bookmarkablePage=xxxxx?param=value">signin</a>
> 
> then a page will be created (like it should you jump inside an
> application maybe for the first time)
> and the page will get that PageParameters in its constructor (if it has
> such a constructor)

I don't like bookmarkable urls as they are now. First, they look ugly.
Second, the page is shown directly without redirection. On the
contrary, I want to send a command to a page, so it would process it,
and then render itself after redirect.

If my page is not versioned ("version") nor has several instances
("path") then I do not want to see anything in the url besides base
page address, I do not want to see "version" or "path".

Also, I do not want to see any parameters in the url. Parameters are
commands, they should be processed in the input phase, then Wicket
should redirect to page and render it in its current state, parameters
are not needed for that.

Michael.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to