hmm.
I also can't see another way that a page is statefull by default and
becomes stateless...
But then every page would be statefull in the inspector (if a page
isn't rendered first)
We just only know it after rendering..
But why is that test there? If a page is stateless then we don't want
to keep a reference to it in the link?
Its a pitty that PageMap.get(int) is package scope and InspectorBug
class can't access it.
Because if that was the case then we could do this:
public InspectorBug(final String id, final WebPage page)
{
super(id);
Link link = new BookmarkablePageLink("link",
InspectorPage.class, new PageParameters(page.getId());
}
and the InspectorPage just tries to get the page from the pagemap and
if it is not there then it page was stateless
else it can use it.
Juergen: I did change and commit all things that i could find that
override isStateless()
did i forget something?
What kind of text was suddenly extra in the page's header?
I still think that isStateless() should be final, because to me it
doesn't make any sense to me that a developer can say
yes it is stateless. If we (the framework know it can't be stateless
(because of a listener) then a developer can't say it is because
that is just not possible.
The other way around is fine. If the framework says it is stateless
but somehow the developers (don't know how) says no i want
this page in the pagemap because i find it statefull then it may
override something and return that if he wants.
So he can say it is statefull but he can't say it is stateless..
johan
On 1/8/06, *Jonathan Locke* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
is there a fix for this other than having the inspector bug make every
page its placed on stateful?
kindof makes it interfere with the experiment, but with this new auto
detect code, i don't see another choice offhand.
Jonathan Locke wrote:
>
> oh right... the page is stateless because it has not rendered yet!
> the inspector bug was calling isStateless() in its constructor so
> every page is always stateless to it now!
>
> Jonathan Locke wrote:
>>
>> why is wicket inspector broken now? it just says every page is
>> [Stateless Page]... even when it is not...
>>
>> Johan Compagner wrote:
>>> ok implemented the fist cut for this
>>> It seems to work fine. Alle example applications seems to work and
>>> the test are running.
>>>
>>> Page.isStateless () is made final and it shouldn't be overriden
>>> because it can't really be up to the developer if a page is
>>> stateless or not.
>>>
>>> stateless is calculated on every render.
>>>
>>> If i look at the examples and the inspector then we see now that a
>>> lot of pages are not in the session!
>>> Just look at the component reference example. It session is being
>>> kept very very clean!
>>>
>>> johan
>>>
>>>
>>> On 1/8/06, *Johan Compagner* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
>>> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>
wrote:
>>>
>>> as i already said. We know if a page is stateless or not
as far as
>>> i can think off.
>>> If Page.urlFor(Component,Interface) is not called for a
page. The
>>> page is stateless..
>>> If it is called then a callback to the page can happen so
it is
>>> statefull.
>>> Or do i miss something here?
>>>
>>> Walking the component tree to check this can maybe be
dangerous
>>> (now or in the further)
>>> because what happens when the component itself is not the
listener
>>> but for example a behaviour/ajax handler?
>>>
>>> So i think just tracking the call to Page.urlFor is the
best thing
>>> to do. And we have to make sure
>>> that when we introduce listeners not only to components
that that
>>> all go to one method of Page.
>>>
>>> That check in Page.urlFor can be a boolean setter that is a
>>> transient or request only boolean because
>>> if for example a Page had a Form or a Link but it is in a
specific
>>> case not visible then the page is also stateless.
>>>
>>> But that is just a matter what we want if we have a Page
that was
>>> statefull then with the second request
>>> the link/form was made invisible so then the page is
stateless the
>>> Page.touch() doesn't add it again to the page map
>>> So the Page is not again in front of the pagemap, but
maybe this
>>> is the behaviour that we want because to that page
>>> no call backs can be made. So that page doesn't have to be at
>>> front it can disappear earlier.
>>>
>>> johan
>>>
>>>
>>>
>>> On 1/8/06, *Eelco Hillenius* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
>>> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
>>>
>>> A trick that I thought of - but never tried to
implement yet -
>>> is to
>>> walk the component tree in a (bookmarkable) page and look
>>> for any
>>> nested IRequestListener with the exception of
>>> IRedirectListener and
>>> bookmarkable page links. If none are found, you know
that you
>>> can keep
>>> that page out of the session. Imo, having such a boolean
>>> method is a
>>> bit too easy and only to be used in very specific
cases by
>>> people that
>>> really know what they are doing, in which case they
already
>>> have the
>>> option of providing their own page map implementation (or
>>> whatever it
>>> is called now). So, we might rethink whether we really
need
>>> this
>>> method, or that we should make Wicket smarter about this.
>>>
>>> Eelco
>>>
>>>
>>> On 1/8/06, Jonathan Locke < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
>>> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
>>> >
>>> > 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]>
>>> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
>>> > > <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> <mailto: [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]>>
>>> > > <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
>>> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>
>>> > > > <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
>>> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > <mailto:[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]>>>
>>> > > > <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
>>> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
>>> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>>>
>>> > > > > <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
>>> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
>>> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>
>>> > > <mailto: [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>>
>>> > > <
>>>
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>>>
>>> > > > <
>>>
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>>
>>> > > <
>>>
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]>>
>>> > > <mailto: [email protected]
<mailto:[email protected]>
>>> <mailto:[email protected]
<mailto:[email protected]>>>
>>> > > > <mailto:
[email protected]
<mailto:[email protected]>
>>> <mailto:[email protected]
<mailto:[email protected]> >
>>> > > <mailto: [email protected]
<mailto:[email protected]>
>>> <mailto: [email protected]
<mailto:[email protected]>>>>
>>> > > >
>>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
<https://lists.sourceforge.net/lists/listinfo/wicket-develop>
>>>
<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>
>>>
<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>
>>> <
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]>>
>>> > > <mailto: [email protected]
<mailto:[email protected]>
>>> <mailto: [email protected]
<mailto:[email protected]>>>
>>> > >
>>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>>>
<https://lists.sourceforge.net/lists/listinfo/wicket-develop
<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>
>>>
<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_idv37&alloc_id865&opclick
<http://ads.osdn.com/?ad_idv37&alloc_id%16865&opclick>
>>> < http://ads.osdn.com/?ad_idv37&alloc_id%16865&opclick
<http://ads.osdn.com/?ad_idv37&alloc_id%16865&opclick>>
>>> _______________________________________________
>>> 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
<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
<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
