the idea was that some pages that encode stateful urls might actually be stateless (in the pagemap) because they put their state into the url or the client. that was my reasoning.

Johan Compagner wrote:
i find that isStateless() a bit the javadoc should really be much clearer of this method. Because now developers can just think. "He it keeps the page out of the session great i will return true" But that is dangerous if you use any state (urlFor call basicly) because those will not work,
you always get a Expired page of course..
So the developer can't really decide if a page is stateless yes or know. We as a framework can.

For exampe a developer can make a page stateless and in the beginning it is stateless yes so everything works Then suddenly a small change happens and suddenly errors are popping up (hopefully they test this right as soon as possible and they know immedianlty why they suddenly get an Expired Page when they do X)

johan

On 1/7/06, *Jonathan Locke* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:


    maybe the IRequestCodingStrategy is the place to keep track of
    this.  if
    the coding strategy is used, then the page is stateful.  the urlFor
    impls all call it and there might be more cases in the future.

    Johan Compagner wrote:
    > I think for now we should just say if you want completely stateless
    > make everything you do through bookmarkable links.
    > Then for example amazon could do it for viewing all the
    categories and
    > items.
    > Then we only need something for for forms.
    > If we also can map a form to a bookmarkable link and that link first
    > makes the form page (instead of looking it up in the pagemap)
    > and then does the submit on it.
    > Then a user must use cookies or something to store the relevant
    > information on the clients computer (i think this is how amazon
    works
    > now)
    > So then we need a BookmarkableForm component that doesn't do
    > Page.urlFor(form,interface) but generates a bookmarkable link
    > for the page it is on (how exactly maybe that the developer should
    > help with)
    >
    > For pages that has just bookmarkable stuff (so
    > Page.urlFor(Component,interface) is never called) we should
    never make
    > a PageEntry
    > so the page should never go into the pagemap.
    >
    > johan
    >
    >
    > On 1/7/06, * Jonathan Locke* < [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
    >
    >
    >     the new feature would not be any more limiting than the same
    >     feature in
    >     jsf.  might not be too fun to implement though...
    >
    >     Igor Vaynberg wrote:
    >     > imho,
    >     >
    >     > On 1/6/06, *Jonathan Locke* < [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    >     <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
    >     > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
    <mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>> wrote:
    >     >
    >     >
    >     >     it definitely can get harder.  but it depends on the
    >     page.  you can
    >     >     imagine a pretty complex page too where the whole page
    can be
    >     >     reconstructed in the correct state from just the page
    >     constructor
    >     >     arguments...  you just save the arguments and you can
    >     rebuild from
    >     >     that.
    >     >
    >     >
    >     > no, actually i cant. rebuilding a page from constructor
    >     arguments just
    >     > means that you lose all the interaction that happened on
    the page.
    >     > this is where wicket shines - the user interacts with
    components
    >     that
    >     > are isolated from the page and keep their own state. i went
    >     through a
    >     > few pages i recently wrote to see how feasible this would
    be, and it
    >     > was possible in a few situations, but in most it would not
    be. even
    >     > something as simple as a dataview: the dataprovider pulls out
    >     page 4
    >     > which consists of 10 detachable models. in order to
    reconstruct that
    >     > you would have to  keep the ids of the 10 objects the models
    >     represent
    >     > and store them somewhere, then you would need a way to
    >     initialize the
    >     > data provider to load those particular 10 objects when the
    dataview
    >     > requests page 4 after being reconstructed ( you need to
    fake it
    >     > because page 4 at a later time does not insure the same 10
    >     objects).
    >     > it seems too much trouble to go through personally.
    >     >
    >     >     i personally would probably not use this feature even on a
    >     high volume
    >     >     site, perhaps unless it truly had to be clustered.  but it
    >     seems
    >     >     not too
    >     >     hard to provide and it gives users options and critics
    (who
    >     may or may
    >     >     not be well informed) less to find lacking.
    >     >
    >     >
    >     > but then you have the situation where those same critics
    are now
    >     > saying that this newly added feature solves nothing
    because its too
    >     > limiting. and look at all the trouble we have to go
    through to
    >     get it
    >     > working, i dont think converting all links to posts is
    trivial.
    >     >
    >     >  -Igor
    >     >
    >     >
    >     >
    >
    >
    >     -------------------------------------------------------
    >     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_id=7637&alloc_id=16865&op=click
    <http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click>
    >     < http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
    <http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click>>
    >     _______________________________________________
    >     Wicket-develop mailing list
    >     [email protected]
    <mailto:[email protected]>
    >     <mailto:[email protected]
    <mailto:[email protected]>>
    >     https://lists.sourceforge.net/lists/listinfo/wicket-develop
    >
    >


    -------------------------------------------------------
    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_id=7637&alloc_id=16865&op=click
    <http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click>
    _______________________________________________
    Wicket-develop mailing list
    [email protected]
    <mailto:[email protected]>
    https://lists.sourceforge.net/lists/listinfo/wicket-develop




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

Reply via email to