You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jan Vermeulen <ja...@isencia.com> on 2007/02/06 19:53:25 UTC
Single-page applications: bad idea in Wicket ?
We are currently building an application in Wicket (2.0) that has only a
single page: that page contains a border where template markup is defined.
The body of that border is a panel that gets replaced while the user
navigates through the application (something similar to the wizard
implementation in Wicket, but without having created all wizard panels from
the start).
Advantages:
* we use Ajax requestTargets that only replace the changing part of the
page: less flicker, less network traffic.
* as a templating alternative (compared to the extension templating
mechanism), it allows for the body of the template NOT to be an extension of
the template page.
* if the action is limited to an smaller part of the page (f.i. a modal
dialog), same logic applies.
Problems with Wicket:
* the SecondLevelCachePageStore is 'page-oriented': while I remain in the
same page, nothing gets flushed to disk.
* the UndoVersionManager is maintained in the page, and so its changeLists
are using up memory as long as that page is not serialized to disk. I am
aware of the open discussion on refactoring of the pageStore &
versionManager: the 'single-page application' is an extreme case of the
'replace-component' syndrome (cfr.
http://www.nabble.com/refactor-storing-pages-and-versions-tf2943670.html#a8231263).
* since the last change in Wicket 2.0 with 'mergeversion' in the
UndoVersionManager, all Ajax requests are by default considered as candidate
for merging to the actual version i.s.o. creating a new version. This is a
good idea for changes applied to the same page. But in our case, page
navigation is also done through ajax requests, and here we clearly want a
new version for these requests. We solved this problem overwriting the
Request.mergeVersion() method. But we felt that there might be a more
generic need to differenciate between ajax requests that require merging and
ajax requests that require a new version.
Did we take the wrong approach ? Or should Wicket be better prepared to
handle a lot of ajax modifications to the same page ?
--
View this message in context: http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html#a8831903
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Single-page applications: bad idea in Wicket ?
Posted by Johan Compagner <jc...@gmail.com>.
On 2/8/07, Jan Vermeulen <ja...@isencia.com> wrote:
>
>
> >This would work fine now i guess in the latest code of 1.3
> >But that is because a page version is now always a different instance.
> >Because we don't rollback anymore
> >the same page instance (there is no changelist anymore)
>
> We're working with the Wicket 2.0 trunk. Will these changes of 1.3 be
> applied to 2.0 ?
yes i first wanted it to test a bit in the 1.3 (so that i not have too
constantly keep 2 branches up 2 date)
I hope to do it this weekend
>But this will not work when you use the accessstackpagemap (the normal
> >httpsessionstore impl)
> >Because then what happens is that the current page is changed underneath
> >your own call.
> >that could really result in all kind of strange things.
>
> We actually are having all kinds of strange behavior because of changes to
> the current page: we are programmatically doing back-button behaviour by
> retrieving the previous page/version pair from the pageStore. This is
> causing problems due to the fact that we have only one page: so the undo
> is
> applied to the same page instance that is being changed due to submit.
>
> So is it a bad practice to simulate this back-button behaviour in buttons
> within the page ? We have a lot of pages where 'exit' or 'cancel' buttons
> mean 'go back to the previous page'.
What you really should do is just generate the url to the current page.
And then parse the url...and set the version to one lower then it is
But i guess this is also not a happy situation :(
And now in 1.3 or 2.0 there is no previous version at all if you just do
ajax.
so i hope that that previous button is an normal request and that your
really want
to go back to another normal request.
johan
Re: Single-page applications: bad idea in Wicket ?
Posted by Johan Compagner <jc...@gmail.com>.
all urls in the browser are just exact.
Maybe we can give an option. When an normal request come in ignore the
version info. always return the latest.
johan
On 2/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> Can't we come up with something smart like recording the last non-ajax
> request so that when a request for exactly that url comes in after a
> couple version changing ajax request we now that we have to discard
> version info but just serve the latest?
>
> Eelco
>
> On 2/8/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > if the problem is knowing the version ( [20] part of the url ) on the
> server
> > side, can we not keep track of it in a js var, and then modify our
> > wicket.ajax.request javascript to append it to every url for every ajax
> > request?
> >
> > this should work for ajax->ajax but wont work for ajax->regular, but at
> > least its a start
> >
> > -igor
> >
> >
> > On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
> > >
> > > Igor Vaynberg wrote:
> > > > On 2/8/07, Jan Vermeulen <ja...@isencia.com> wrote:
> > > >>
> > > >>
> > > >> >but what is a previous page? you said you only have a single page?
> > > >>
> > > >> Yes, we have one 'physical' Wicket page. But of course, our
> application
> > > >> contains various 'conceptual' pages (physically panels), i.e.
> > > components
> > > >> that make up the body of that single page, and that we go replacing
> as
> > > >> the
> > > >> user navigates. With previous, I mean the same Wicket page, but a
> > > >> previous
> > > >> panel.
> > > >
> > > >
> > > > i see
> > > >
> > > >> wicket's ajax requests should never generate a new version, because
> > > ajax
> > > >> requests do
> > > >> >not change the page url and thus there is no back-button history -
> > > >> and so
> > > >> a
> > > >> >version is not needed.
> > > >>
> > > >> That's why I started this thread in the first place: we are using
> ajax
> > > >> requests to replace these 'conceptual pages' (panels), and would
> have
> > > >> liked
> > > >> a history of that. But for what I read around here, this would be a
> > > hell
> > > >> of
> > > >> a job. I suppose we should re-render the whole page each time.
> > > >
> > > >
> > > > hmm....yes it would be quiet difficult. the thing is that wicket is
> not
> > > a
> > > > 100% ajax driven framework so we have some limitations when compared
> to
> > > the
> > > > likes of backbase and gwt when it comes to things such as this. you
> see
> > > our
> > > > versioning is designed to keep state in sync with the backbutton of
> the
> > > > browser which is of course non-existant when it comes to ajax.
> > > >
> > > > im not really sure how gwt emulates the back button, maybe we can
> look
> > > at
> > > > that and use the same approach. keep in mind that most of us are not
> > > > javascript gurus :) this would defintely be the area where we could
> use
> > > the
> > > > help/input/ideas/patches from our users :) it should be doable, but
> > > > difficult :)
> > > I hate to disappoint you, but i really doubt it's doable in wicket.
> GWT
> > > and backbase work completely different than wicket. It's possible to
> > > support ajax and backbutton for a framework that is completely
> > > ajax-driven. But Wicket is not the case.
> > >
> > > Biggest problem is updating the url. Consider the situation when you
> do
> > > 5 ajax requests on a page (incrementing page version by 5). Then you
> > > reload the page (ctrl+r) and got those 5 versions reverted. That's
> > > because it's not possible to update the url in javascript withou
> > > reloading the page. Changing url hash doesn't help, as it's not
> > > submitted to server.
> > >
> > > I've been thinking about supporting ajax and backbutton in wicket, but
> > > this thing is a real showstopper.
> > >
> > > -Matej
> > > >
> > > >
> > > >> B.t.w.: thanks for the great support, the quick response from the
> core
> > > >> developers, the open mind to new ideas, etc. We made the right
> choice
> > > in
> > > >> going to Wicket !
> > > >
> > > >
> > > > glad to hear it!
> > > >
> > > > -igor
> > > >
> > >
> > >
> >
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Johan Compagner <jc...@gmail.com>.
What do you want to reconstruct on the client?
if the back button is pressed. And we have an special ajax request for that.
That calls the server and does:
Component[] alteredComponents = page.getVersionManager().rollbackAjax(-1)
and then in the ajax request target we set those altered components.
So that they are rerendered in the browser..
I think it is very easy to know what components are altered.
We just let the version manager catch that again :)
so if the version manager does this:
Add.undo() (that removes a component from a parent)
we just let the version manager record that change and we know which
component did change again.
i think that should work.
or the other way around that we just ask the Add change what component it
will alter when it undo's
johan
On 2/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
> > Although there is a drawbacks for this:
> > The history would be lost after first page refresh (so that my example
> > wouldn't even work, unless you don't refresh it :))
>
> But if we would keep ajax changes separately or with a special mark
> somehow, we could push the part of the ajax history we didn't rollback
> to the client (our ajax engine) so that we could reconstruct it again.
>
> Eelco
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Eelco Hillenius <ee...@gmail.com>.
On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
> Yeah, that should be doable.
I created an issue for this: http://issues.apache.org/jira/browse/WICKET-271
Eelco
Re: Single-page applications: bad idea in Wicket ?
Posted by Matej Knopp <ma...@knopp.sk>.
Yeah, that should be doable.
-Matej
Eelco Hillenius wrote:
> On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
>> Although there is a drawbacks for this:
>> The history would be lost after first page refresh (so that my example
>> wouldn't even work, unless you don't refresh it :))
>
> But if we would keep ajax changes separately or with a special mark
> somehow, we could push the part of the ajax history we didn't rollback
> to the client (our ajax engine) so that we could reconstruct it again.
>
> Eelco
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Eelco Hillenius <ee...@gmail.com>.
On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
> Although there is a drawbacks for this:
> The history would be lost after first page refresh (so that my example
> wouldn't even work, unless you don't refresh it :))
But if we would keep ajax changes separately or with a special mark
somehow, we could push the part of the ajax history we didn't rollback
to the client (our ajax engine) so that we could reconstruct it again.
Eelco
Re: Single-page applications: bad idea in Wicket ?
Posted by Johan Compagner <jc...@gmail.com>.
why is history lost?
But if you can catch the back button with an ajax request and do a special
call to the server
then i think if we separate the versioning in an ajax and normal.
We could do a real redirect or just update the object that are changed.
johan
On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
>
> Although there is a drawbacks for this:
> The history would be lost after first page refresh (so that my example
> wouldn't even work, unless you don't refresh it :))
>
>
> Matej Knopp wrote:
> > well...
> > in theory, if we had special versioning for ajax this magic could work.
> >
> > On server we would have to maintain page version number and ajax delta.
> >
> > Let me give you an example:
> > You load page with version 3 (url says version=3)
> >
> > then you click an ajax link (twice)
> > on server the page version is 3 and ajax delta = 2. (internally we could
> > store as 5 i guess).
> >
> > Then when a request comes, with version 3, we would know that we need to
> > server the version 5 (3 + 2 ajax delta).
> >
> > on first backbutton, we would have to call special ajax revert action,
> > that would revert the version to 3 + 1 ajax delta and possibly reload
> > the whole page (less work to do, we wouldn't have to track dom changes).
> >
> > on second backbutton we would have to do the same, reverting to 0 ajax
> > delta (version 3).
> >
> > all other backbutton pressed would be treated like regular back button
> > presses (no ajax magic).
> >
> > -Matej
> >
> >
> >
> > Johan Compagner wrote:
> >> So always remember the last versionnumber for a page that was a normal
> >> request
> >> And all normal and ajax request to that version number will always
> >> give the
> >> latest.
> >>
> >> What we also could do is have special ajax versioning that doesn't up
> the
> >> version number
> >> but can be used in an ajax request to rollback. some thing like:
> >>
> >> Component[] alteredComponents = page.getVersionManager
> >> ().rollbackToAjaxVersion(version)
> >> AjaxRequestTarget.add(alteredComponents)
> >>
> >> johan
> >>
> >>
> >>
> >> On 2/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >>>
> >>> On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
> >>> > Eelco Hillenius wrote:
> >>> > > Can't we come up with something smart like recording the last
> >>> non-ajax
> >>> > > request so that when a request for exactly that url comes in after
> a
> >>> > > couple version changing ajax request we now that we have to
> discard
> >>> > > version info but just serve the latest?
> >>> > And what if user really pressed the back button and really returned
> to
> >>> > the page with "old" verion number?
> >>>
> >>> Then you would recognize it is not the same url as before the ajax
> >>> request(s) and you would just roll back the whole thing to that
> >>> version.
> >>>
> >>> Eelco
> >>>
> >>
> >
> >
>
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Matej Knopp <ma...@knopp.sk>.
Although there is a drawbacks for this:
The history would be lost after first page refresh (so that my example
wouldn't even work, unless you don't refresh it :))
Matej Knopp wrote:
> well...
> in theory, if we had special versioning for ajax this magic could work.
>
> On server we would have to maintain page version number and ajax delta.
>
> Let me give you an example:
> You load page with version 3 (url says version=3)
>
> then you click an ajax link (twice)
> on server the page version is 3 and ajax delta = 2. (internally we could
> store as 5 i guess).
>
> Then when a request comes, with version 3, we would know that we need to
> server the version 5 (3 + 2 ajax delta).
>
> on first backbutton, we would have to call special ajax revert action,
> that would revert the version to 3 + 1 ajax delta and possibly reload
> the whole page (less work to do, we wouldn't have to track dom changes).
>
> on second backbutton we would have to do the same, reverting to 0 ajax
> delta (version 3).
>
> all other backbutton pressed would be treated like regular back button
> presses (no ajax magic).
>
> -Matej
>
>
>
> Johan Compagner wrote:
>> So always remember the last versionnumber for a page that was a normal
>> request
>> And all normal and ajax request to that version number will always
>> give the
>> latest.
>>
>> What we also could do is have special ajax versioning that doesn't up the
>> version number
>> but can be used in an ajax request to rollback. some thing like:
>>
>> Component[] alteredComponents = page.getVersionManager
>> ().rollbackToAjaxVersion(version)
>> AjaxRequestTarget.add(alteredComponents)
>>
>> johan
>>
>>
>>
>> On 2/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
>>>
>>> On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
>>> > Eelco Hillenius wrote:
>>> > > Can't we come up with something smart like recording the last
>>> non-ajax
>>> > > request so that when a request for exactly that url comes in after a
>>> > > couple version changing ajax request we now that we have to discard
>>> > > version info but just serve the latest?
>>> > And what if user really pressed the back button and really returned to
>>> > the page with "old" verion number?
>>>
>>> Then you would recognize it is not the same url as before the ajax
>>> request(s) and you would just roll back the whole thing to that
>>> version.
>>>
>>> Eelco
>>>
>>
>
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Matej Knopp <ma...@knopp.sk>.
well...
in theory, if we had special versioning for ajax this magic could work.
On server we would have to maintain page version number and ajax delta.
Let me give you an example:
You load page with version 3 (url says version=3)
then you click an ajax link (twice)
on server the page version is 3 and ajax delta = 2. (internally we could
store as 5 i guess).
Then when a request comes, with version 3, we would know that we need to
server the version 5 (3 + 2 ajax delta).
on first backbutton, we would have to call special ajax revert action,
that would revert the version to 3 + 1 ajax delta and possibly reload
the whole page (less work to do, we wouldn't have to track dom changes).
on second backbutton we would have to do the same, reverting to 0 ajax
delta (version 3).
all other backbutton pressed would be treated like regular back button
presses (no ajax magic).
-Matej
Johan Compagner wrote:
> So always remember the last versionnumber for a page that was a normal
> request
> And all normal and ajax request to that version number will always give the
> latest.
>
> What we also could do is have special ajax versioning that doesn't up the
> version number
> but can be used in an ajax request to rollback. some thing like:
>
> Component[] alteredComponents = page.getVersionManager
> ().rollbackToAjaxVersion(version)
> AjaxRequestTarget.add(alteredComponents)
>
> johan
>
>
>
> On 2/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
>>
>> On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
>> > Eelco Hillenius wrote:
>> > > Can't we come up with something smart like recording the last
>> non-ajax
>> > > request so that when a request for exactly that url comes in after a
>> > > couple version changing ajax request we now that we have to discard
>> > > version info but just serve the latest?
>> > And what if user really pressed the back button and really returned to
>> > the page with "old" verion number?
>>
>> Then you would recognize it is not the same url as before the ajax
>> request(s) and you would just roll back the whole thing to that
>> version.
>>
>> Eelco
>>
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Johan Compagner <jc...@gmail.com>.
So always remember the last versionnumber for a page that was a normal
request
And all normal and ajax request to that version number will always give the
latest.
What we also could do is have special ajax versioning that doesn't up the
version number
but can be used in an ajax request to rollback. some thing like:
Component[] alteredComponents = page.getVersionManager
().rollbackToAjaxVersion(version)
AjaxRequestTarget.add(alteredComponents)
johan
On 2/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
> > Eelco Hillenius wrote:
> > > Can't we come up with something smart like recording the last non-ajax
> > > request so that when a request for exactly that url comes in after a
> > > couple version changing ajax request we now that we have to discard
> > > version info but just serve the latest?
> > And what if user really pressed the back button and really returned to
> > the page with "old" verion number?
>
> Then you would recognize it is not the same url as before the ajax
> request(s) and you would just roll back the whole thing to that
> version.
>
> Eelco
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Eelco Hillenius <ee...@gmail.com>.
On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
> Eelco Hillenius wrote:
> > Can't we come up with something smart like recording the last non-ajax
> > request so that when a request for exactly that url comes in after a
> > couple version changing ajax request we now that we have to discard
> > version info but just serve the latest?
> And what if user really pressed the back button and really returned to
> the page with "old" verion number?
Then you would recognize it is not the same url as before the ajax
request(s) and you would just roll back the whole thing to that
version.
Eelco
Re: Single-page applications: bad idea in Wicket ?
Posted by Eelco Hillenius <ee...@gmail.com>.
The ajax part would have it's own rolling back. So if you had one
normal request and two ajax requests after that and you push the back
button, the 'rollback' would be handled by the javascript engine (so
without any call backs) much like normal ajax engines do, except that
we would probably need to inform the server that we rolled back a
version.
Eelco
On 2/8/07, Johan Compagner <jc...@gmail.com> wrote:
> Then that is never possible.
> Because if you want to make a single page and do everything else in ajax
> we could say, every request is just the latest. And let only the real back
> be done in code (so what jan does now)
>
> johan
>
>
> On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
> >
> > Eelco Hillenius wrote:
> > > Can't we come up with something smart like recording the last non-ajax
> > > request so that when a request for exactly that url comes in after a
> > > couple version changing ajax request we now that we have to discard
> > > version info but just serve the latest?
> > And what if user really pressed the back button and really returned to
> > the page with "old" verion number?
> > >
> > > Eelco
> > >
> > > On 2/8/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > >> if the problem is knowing the version ( [20] part of the url ) on the
> > >> server
> > >> side, can we not keep track of it in a js var, and then modify our
> > >> wicket.ajax.request javascript to append it to every url for every ajax
> > >> request?
> > >>
> > >> this should work for ajax->ajax but wont work for ajax->regular, but at
> > >> least its a start
> > >>
> > >> -igor
> > >>
> > >>
> > >> On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
> > >> >
> > >> > Igor Vaynberg wrote:
> > >> > > On 2/8/07, Jan Vermeulen <ja...@isencia.com> wrote:
> > >> > >>
> > >> > >>
> > >> > >> >but what is a previous page? you said you only have a single
> > page?
> > >> > >>
> > >> > >> Yes, we have one 'physical' Wicket page. But of course, our
> > >> application
> > >> > >> contains various 'conceptual' pages (physically panels), i.e.
> > >> > components
> > >> > >> that make up the body of that single page, and that we go
> > >> replacing as
> > >> > >> the
> > >> > >> user navigates. With previous, I mean the same Wicket page, but a
> > >> > >> previous
> > >> > >> panel.
> > >> > >
> > >> > >
> > >> > > i see
> > >> > >
> > >> > >> wicket's ajax requests should never generate a new version,
> > because
> > >> > ajax
> > >> > >> requests do
> > >> > >> >not change the page url and thus there is no back-button history
> > -
> > >> > >> and so
> > >> > >> a
> > >> > >> >version is not needed.
> > >> > >>
> > >> > >> That's why I started this thread in the first place: we are using
> > >> ajax
> > >> > >> requests to replace these 'conceptual pages' (panels), and would
> > >> have
> > >> > >> liked
> > >> > >> a history of that. But for what I read around here, this would be
> > a
> > >> > hell
> > >> > >> of
> > >> > >> a job. I suppose we should re-render the whole page each time.
> > >> > >
> > >> > >
> > >> > > hmm....yes it would be quiet difficult. the thing is that wicket
> > >> is not
> > >> > a
> > >> > > 100% ajax driven framework so we have some limitations when
> > >> compared to
> > >> > the
> > >> > > likes of backbase and gwt when it comes to things such as this.
> > >> you see
> > >> > our
> > >> > > versioning is designed to keep state in sync with the backbutton
> > >> of the
> > >> > > browser which is of course non-existant when it comes to ajax.
> > >> > >
> > >> > > im not really sure how gwt emulates the back button, maybe we can
> > >> look
> > >> > at
> > >> > > that and use the same approach. keep in mind that most of us are
> > not
> > >> > > javascript gurus :) this would defintely be the area where we
> > >> could use
> > >> > the
> > >> > > help/input/ideas/patches from our users :) it should be doable, but
> > >> > > difficult :)
> > >> > I hate to disappoint you, but i really doubt it's doable in wicket.
> > GWT
> > >> > and backbase work completely different than wicket. It's possible to
> > >> > support ajax and backbutton for a framework that is completely
> > >> > ajax-driven. But Wicket is not the case.
> > >> >
> > >> > Biggest problem is updating the url. Consider the situation when you
> > do
> > >> > 5 ajax requests on a page (incrementing page version by 5). Then you
> > >> > reload the page (ctrl+r) and got those 5 versions reverted. That's
> > >> > because it's not possible to update the url in javascript withou
> > >> > reloading the page. Changing url hash doesn't help, as it's not
> > >> > submitted to server.
> > >> >
> > >> > I've been thinking about supporting ajax and backbutton in wicket,
> > but
> > >> > this thing is a real showstopper.
> > >> >
> > >> > -Matej
> > >> > >
> > >> > >
> > >> > >> B.t.w.: thanks for the great support, the quick response from the
> > >> core
> > >> > >> developers, the open mind to new ideas, etc. We made the right
> > >> choice
> > >> > in
> > >> > >> going to Wicket !
> > >> > >
> > >> > >
> > >> > > glad to hear it!
> > >> > >
> > >> > > -igor
> > >> > >
> > >> >
> > >> >
> > >>
> > >
> >
> >
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Johan Compagner <jc...@gmail.com>.
Then that is never possible.
Because if you want to make a single page and do everything else in ajax
we could say, every request is just the latest. And let only the real back
be done in code (so what jan does now)
johan
On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
>
> Eelco Hillenius wrote:
> > Can't we come up with something smart like recording the last non-ajax
> > request so that when a request for exactly that url comes in after a
> > couple version changing ajax request we now that we have to discard
> > version info but just serve the latest?
> And what if user really pressed the back button and really returned to
> the page with "old" verion number?
> >
> > Eelco
> >
> > On 2/8/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >> if the problem is knowing the version ( [20] part of the url ) on the
> >> server
> >> side, can we not keep track of it in a js var, and then modify our
> >> wicket.ajax.request javascript to append it to every url for every ajax
> >> request?
> >>
> >> this should work for ajax->ajax but wont work for ajax->regular, but at
> >> least its a start
> >>
> >> -igor
> >>
> >>
> >> On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
> >> >
> >> > Igor Vaynberg wrote:
> >> > > On 2/8/07, Jan Vermeulen <ja...@isencia.com> wrote:
> >> > >>
> >> > >>
> >> > >> >but what is a previous page? you said you only have a single
> page?
> >> > >>
> >> > >> Yes, we have one 'physical' Wicket page. But of course, our
> >> application
> >> > >> contains various 'conceptual' pages (physically panels), i.e.
> >> > components
> >> > >> that make up the body of that single page, and that we go
> >> replacing as
> >> > >> the
> >> > >> user navigates. With previous, I mean the same Wicket page, but a
> >> > >> previous
> >> > >> panel.
> >> > >
> >> > >
> >> > > i see
> >> > >
> >> > >> wicket's ajax requests should never generate a new version,
> because
> >> > ajax
> >> > >> requests do
> >> > >> >not change the page url and thus there is no back-button history
> -
> >> > >> and so
> >> > >> a
> >> > >> >version is not needed.
> >> > >>
> >> > >> That's why I started this thread in the first place: we are using
> >> ajax
> >> > >> requests to replace these 'conceptual pages' (panels), and would
> >> have
> >> > >> liked
> >> > >> a history of that. But for what I read around here, this would be
> a
> >> > hell
> >> > >> of
> >> > >> a job. I suppose we should re-render the whole page each time.
> >> > >
> >> > >
> >> > > hmm....yes it would be quiet difficult. the thing is that wicket
> >> is not
> >> > a
> >> > > 100% ajax driven framework so we have some limitations when
> >> compared to
> >> > the
> >> > > likes of backbase and gwt when it comes to things such as this.
> >> you see
> >> > our
> >> > > versioning is designed to keep state in sync with the backbutton
> >> of the
> >> > > browser which is of course non-existant when it comes to ajax.
> >> > >
> >> > > im not really sure how gwt emulates the back button, maybe we can
> >> look
> >> > at
> >> > > that and use the same approach. keep in mind that most of us are
> not
> >> > > javascript gurus :) this would defintely be the area where we
> >> could use
> >> > the
> >> > > help/input/ideas/patches from our users :) it should be doable, but
> >> > > difficult :)
> >> > I hate to disappoint you, but i really doubt it's doable in wicket.
> GWT
> >> > and backbase work completely different than wicket. It's possible to
> >> > support ajax and backbutton for a framework that is completely
> >> > ajax-driven. But Wicket is not the case.
> >> >
> >> > Biggest problem is updating the url. Consider the situation when you
> do
> >> > 5 ajax requests on a page (incrementing page version by 5). Then you
> >> > reload the page (ctrl+r) and got those 5 versions reverted. That's
> >> > because it's not possible to update the url in javascript withou
> >> > reloading the page. Changing url hash doesn't help, as it's not
> >> > submitted to server.
> >> >
> >> > I've been thinking about supporting ajax and backbutton in wicket,
> but
> >> > this thing is a real showstopper.
> >> >
> >> > -Matej
> >> > >
> >> > >
> >> > >> B.t.w.: thanks for the great support, the quick response from the
> >> core
> >> > >> developers, the open mind to new ideas, etc. We made the right
> >> choice
> >> > in
> >> > >> going to Wicket !
> >> > >
> >> > >
> >> > > glad to hear it!
> >> > >
> >> > > -igor
> >> > >
> >> >
> >> >
> >>
> >
>
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Matej Knopp <ma...@knopp.sk>.
Eelco Hillenius wrote:
> Can't we come up with something smart like recording the last non-ajax
> request so that when a request for exactly that url comes in after a
> couple version changing ajax request we now that we have to discard
> version info but just serve the latest?
And what if user really pressed the back button and really returned to
the page with "old" verion number?
>
> Eelco
>
> On 2/8/07, Igor Vaynberg <ig...@gmail.com> wrote:
>> if the problem is knowing the version ( [20] part of the url ) on the
>> server
>> side, can we not keep track of it in a js var, and then modify our
>> wicket.ajax.request javascript to append it to every url for every ajax
>> request?
>>
>> this should work for ajax->ajax but wont work for ajax->regular, but at
>> least its a start
>>
>> -igor
>>
>>
>> On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
>> >
>> > Igor Vaynberg wrote:
>> > > On 2/8/07, Jan Vermeulen <ja...@isencia.com> wrote:
>> > >>
>> > >>
>> > >> >but what is a previous page? you said you only have a single page?
>> > >>
>> > >> Yes, we have one 'physical' Wicket page. But of course, our
>> application
>> > >> contains various 'conceptual' pages (physically panels), i.e.
>> > components
>> > >> that make up the body of that single page, and that we go
>> replacing as
>> > >> the
>> > >> user navigates. With previous, I mean the same Wicket page, but a
>> > >> previous
>> > >> panel.
>> > >
>> > >
>> > > i see
>> > >
>> > >> wicket's ajax requests should never generate a new version, because
>> > ajax
>> > >> requests do
>> > >> >not change the page url and thus there is no back-button history -
>> > >> and so
>> > >> a
>> > >> >version is not needed.
>> > >>
>> > >> That's why I started this thread in the first place: we are using
>> ajax
>> > >> requests to replace these 'conceptual pages' (panels), and would
>> have
>> > >> liked
>> > >> a history of that. But for what I read around here, this would be a
>> > hell
>> > >> of
>> > >> a job. I suppose we should re-render the whole page each time.
>> > >
>> > >
>> > > hmm....yes it would be quiet difficult. the thing is that wicket
>> is not
>> > a
>> > > 100% ajax driven framework so we have some limitations when
>> compared to
>> > the
>> > > likes of backbase and gwt when it comes to things such as this.
>> you see
>> > our
>> > > versioning is designed to keep state in sync with the backbutton
>> of the
>> > > browser which is of course non-existant when it comes to ajax.
>> > >
>> > > im not really sure how gwt emulates the back button, maybe we can
>> look
>> > at
>> > > that and use the same approach. keep in mind that most of us are not
>> > > javascript gurus :) this would defintely be the area where we
>> could use
>> > the
>> > > help/input/ideas/patches from our users :) it should be doable, but
>> > > difficult :)
>> > I hate to disappoint you, but i really doubt it's doable in wicket. GWT
>> > and backbase work completely different than wicket. It's possible to
>> > support ajax and backbutton for a framework that is completely
>> > ajax-driven. But Wicket is not the case.
>> >
>> > Biggest problem is updating the url. Consider the situation when you do
>> > 5 ajax requests on a page (incrementing page version by 5). Then you
>> > reload the page (ctrl+r) and got those 5 versions reverted. That's
>> > because it's not possible to update the url in javascript withou
>> > reloading the page. Changing url hash doesn't help, as it's not
>> > submitted to server.
>> >
>> > I've been thinking about supporting ajax and backbutton in wicket, but
>> > this thing is a real showstopper.
>> >
>> > -Matej
>> > >
>> > >
>> > >> B.t.w.: thanks for the great support, the quick response from the
>> core
>> > >> developers, the open mind to new ideas, etc. We made the right
>> choice
>> > in
>> > >> going to Wicket !
>> > >
>> > >
>> > > glad to hear it!
>> > >
>> > > -igor
>> > >
>> >
>> >
>>
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Eelco Hillenius <ee...@gmail.com>.
Can't we come up with something smart like recording the last non-ajax
request so that when a request for exactly that url comes in after a
couple version changing ajax request we now that we have to discard
version info but just serve the latest?
Eelco
On 2/8/07, Igor Vaynberg <ig...@gmail.com> wrote:
> if the problem is knowing the version ( [20] part of the url ) on the server
> side, can we not keep track of it in a js var, and then modify our
> wicket.ajax.request javascript to append it to every url for every ajax
> request?
>
> this should work for ajax->ajax but wont work for ajax->regular, but at
> least its a start
>
> -igor
>
>
> On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
> >
> > Igor Vaynberg wrote:
> > > On 2/8/07, Jan Vermeulen <ja...@isencia.com> wrote:
> > >>
> > >>
> > >> >but what is a previous page? you said you only have a single page?
> > >>
> > >> Yes, we have one 'physical' Wicket page. But of course, our application
> > >> contains various 'conceptual' pages (physically panels), i.e.
> > components
> > >> that make up the body of that single page, and that we go replacing as
> > >> the
> > >> user navigates. With previous, I mean the same Wicket page, but a
> > >> previous
> > >> panel.
> > >
> > >
> > > i see
> > >
> > >> wicket's ajax requests should never generate a new version, because
> > ajax
> > >> requests do
> > >> >not change the page url and thus there is no back-button history -
> > >> and so
> > >> a
> > >> >version is not needed.
> > >>
> > >> That's why I started this thread in the first place: we are using ajax
> > >> requests to replace these 'conceptual pages' (panels), and would have
> > >> liked
> > >> a history of that. But for what I read around here, this would be a
> > hell
> > >> of
> > >> a job. I suppose we should re-render the whole page each time.
> > >
> > >
> > > hmm....yes it would be quiet difficult. the thing is that wicket is not
> > a
> > > 100% ajax driven framework so we have some limitations when compared to
> > the
> > > likes of backbase and gwt when it comes to things such as this. you see
> > our
> > > versioning is designed to keep state in sync with the backbutton of the
> > > browser which is of course non-existant when it comes to ajax.
> > >
> > > im not really sure how gwt emulates the back button, maybe we can look
> > at
> > > that and use the same approach. keep in mind that most of us are not
> > > javascript gurus :) this would defintely be the area where we could use
> > the
> > > help/input/ideas/patches from our users :) it should be doable, but
> > > difficult :)
> > I hate to disappoint you, but i really doubt it's doable in wicket. GWT
> > and backbase work completely different than wicket. It's possible to
> > support ajax and backbutton for a framework that is completely
> > ajax-driven. But Wicket is not the case.
> >
> > Biggest problem is updating the url. Consider the situation when you do
> > 5 ajax requests on a page (incrementing page version by 5). Then you
> > reload the page (ctrl+r) and got those 5 versions reverted. That's
> > because it's not possible to update the url in javascript withou
> > reloading the page. Changing url hash doesn't help, as it's not
> > submitted to server.
> >
> > I've been thinking about supporting ajax and backbutton in wicket, but
> > this thing is a real showstopper.
> >
> > -Matej
> > >
> > >
> > >> B.t.w.: thanks for the great support, the quick response from the core
> > >> developers, the open mind to new ideas, etc. We made the right choice
> > in
> > >> going to Wicket !
> > >
> > >
> > > glad to hear it!
> > >
> > > -igor
> > >
> >
> >
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Matej Knopp <ma...@knopp.sk>.
Igor Vaynberg wrote:
> if the problem is knowing the version ( [20] part of the url ) on the
> server
> side, can we not keep track of it in a js var, and then modify our
> wicket.ajax.request javascript to append it to every url for every ajax
> request?
>
> this should work for ajax->ajax but wont work for ajax->regular, but at
> least its a start
sure, it's a start, but i can't see anything behind it.
as soon as you reload the page, you'll lose the version information.
Unless we figure this (and believe me, i've tried to), it's not worth
even trying to implement it. It would be a half-baked non-reliable
solution at best. I can't just tell the user not to reload the page.
To to mention patching the urls would require rather hacky javascript.
>
> -igor
>
>
> On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
>>
>> Igor Vaynberg wrote:
>> > On 2/8/07, Jan Vermeulen <ja...@isencia.com> wrote:
>> >>
>> >>
>> >> >but what is a previous page? you said you only have a single page?
>> >>
>> >> Yes, we have one 'physical' Wicket page. But of course, our
>> application
>> >> contains various 'conceptual' pages (physically panels), i.e.
>> components
>> >> that make up the body of that single page, and that we go replacing as
>> >> the
>> >> user navigates. With previous, I mean the same Wicket page, but a
>> >> previous
>> >> panel.
>> >
>> >
>> > i see
>> >
>> >> wicket's ajax requests should never generate a new version, because
>> ajax
>> >> requests do
>> >> >not change the page url and thus there is no back-button history -
>> >> and so
>> >> a
>> >> >version is not needed.
>> >>
>> >> That's why I started this thread in the first place: we are using ajax
>> >> requests to replace these 'conceptual pages' (panels), and would have
>> >> liked
>> >> a history of that. But for what I read around here, this would be a
>> hell
>> >> of
>> >> a job. I suppose we should re-render the whole page each time.
>> >
>> >
>> > hmm....yes it would be quiet difficult. the thing is that wicket is not
>> a
>> > 100% ajax driven framework so we have some limitations when compared to
>> the
>> > likes of backbase and gwt when it comes to things such as this. you see
>> our
>> > versioning is designed to keep state in sync with the backbutton of the
>> > browser which is of course non-existant when it comes to ajax.
>> >
>> > im not really sure how gwt emulates the back button, maybe we can look
>> at
>> > that and use the same approach. keep in mind that most of us are not
>> > javascript gurus :) this would defintely be the area where we could use
>> the
>> > help/input/ideas/patches from our users :) it should be doable, but
>> > difficult :)
>> I hate to disappoint you, but i really doubt it's doable in wicket. GWT
>> and backbase work completely different than wicket. It's possible to
>> support ajax and backbutton for a framework that is completely
>> ajax-driven. But Wicket is not the case.
>>
>> Biggest problem is updating the url. Consider the situation when you do
>> 5 ajax requests on a page (incrementing page version by 5). Then you
>> reload the page (ctrl+r) and got those 5 versions reverted. That's
>> because it's not possible to update the url in javascript withou
>> reloading the page. Changing url hash doesn't help, as it's not
>> submitted to server.
>>
>> I've been thinking about supporting ajax and backbutton in wicket, but
>> this thing is a real showstopper.
>>
>> -Matej
>> >
>> >
>> >> B.t.w.: thanks for the great support, the quick response from the core
>> >> developers, the open mind to new ideas, etc. We made the right choice
>> in
>> >> going to Wicket !
>> >
>> >
>> > glad to hear it!
>> >
>> > -igor
>> >
>>
>>
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Igor Vaynberg <ig...@gmail.com>.
if the problem is knowing the version ( [20] part of the url ) on the server
side, can we not keep track of it in a js var, and then modify our
wicket.ajax.request javascript to append it to every url for every ajax
request?
this should work for ajax->ajax but wont work for ajax->regular, but at
least its a start
-igor
On 2/8/07, Matej Knopp <ma...@knopp.sk> wrote:
>
> Igor Vaynberg wrote:
> > On 2/8/07, Jan Vermeulen <ja...@isencia.com> wrote:
> >>
> >>
> >> >but what is a previous page? you said you only have a single page?
> >>
> >> Yes, we have one 'physical' Wicket page. But of course, our application
> >> contains various 'conceptual' pages (physically panels), i.e.
> components
> >> that make up the body of that single page, and that we go replacing as
> >> the
> >> user navigates. With previous, I mean the same Wicket page, but a
> >> previous
> >> panel.
> >
> >
> > i see
> >
> >> wicket's ajax requests should never generate a new version, because
> ajax
> >> requests do
> >> >not change the page url and thus there is no back-button history -
> >> and so
> >> a
> >> >version is not needed.
> >>
> >> That's why I started this thread in the first place: we are using ajax
> >> requests to replace these 'conceptual pages' (panels), and would have
> >> liked
> >> a history of that. But for what I read around here, this would be a
> hell
> >> of
> >> a job. I suppose we should re-render the whole page each time.
> >
> >
> > hmm....yes it would be quiet difficult. the thing is that wicket is not
> a
> > 100% ajax driven framework so we have some limitations when compared to
> the
> > likes of backbase and gwt when it comes to things such as this. you see
> our
> > versioning is designed to keep state in sync with the backbutton of the
> > browser which is of course non-existant when it comes to ajax.
> >
> > im not really sure how gwt emulates the back button, maybe we can look
> at
> > that and use the same approach. keep in mind that most of us are not
> > javascript gurus :) this would defintely be the area where we could use
> the
> > help/input/ideas/patches from our users :) it should be doable, but
> > difficult :)
> I hate to disappoint you, but i really doubt it's doable in wicket. GWT
> and backbase work completely different than wicket. It's possible to
> support ajax and backbutton for a framework that is completely
> ajax-driven. But Wicket is not the case.
>
> Biggest problem is updating the url. Consider the situation when you do
> 5 ajax requests on a page (incrementing page version by 5). Then you
> reload the page (ctrl+r) and got those 5 versions reverted. That's
> because it's not possible to update the url in javascript withou
> reloading the page. Changing url hash doesn't help, as it's not
> submitted to server.
>
> I've been thinking about supporting ajax and backbutton in wicket, but
> this thing is a real showstopper.
>
> -Matej
> >
> >
> >> B.t.w.: thanks for the great support, the quick response from the core
> >> developers, the open mind to new ideas, etc. We made the right choice
> in
> >> going to Wicket !
> >
> >
> > glad to hear it!
> >
> > -igor
> >
>
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Matej Knopp <ma...@knopp.sk>.
Igor Vaynberg wrote:
> On 2/8/07, Jan Vermeulen <ja...@isencia.com> wrote:
>>
>>
>> >but what is a previous page? you said you only have a single page?
>>
>> Yes, we have one 'physical' Wicket page. But of course, our application
>> contains various 'conceptual' pages (physically panels), i.e. components
>> that make up the body of that single page, and that we go replacing as
>> the
>> user navigates. With previous, I mean the same Wicket page, but a
>> previous
>> panel.
>
>
> i see
>
>> wicket's ajax requests should never generate a new version, because ajax
>> requests do
>> >not change the page url and thus there is no back-button history -
>> and so
>> a
>> >version is not needed.
>>
>> That's why I started this thread in the first place: we are using ajax
>> requests to replace these 'conceptual pages' (panels), and would have
>> liked
>> a history of that. But for what I read around here, this would be a hell
>> of
>> a job. I suppose we should re-render the whole page each time.
>
>
> hmm....yes it would be quiet difficult. the thing is that wicket is not a
> 100% ajax driven framework so we have some limitations when compared to the
> likes of backbase and gwt when it comes to things such as this. you see our
> versioning is designed to keep state in sync with the backbutton of the
> browser which is of course non-existant when it comes to ajax.
>
> im not really sure how gwt emulates the back button, maybe we can look at
> that and use the same approach. keep in mind that most of us are not
> javascript gurus :) this would defintely be the area where we could use the
> help/input/ideas/patches from our users :) it should be doable, but
> difficult :)
I hate to disappoint you, but i really doubt it's doable in wicket. GWT
and backbase work completely different than wicket. It's possible to
support ajax and backbutton for a framework that is completely
ajax-driven. But Wicket is not the case.
Biggest problem is updating the url. Consider the situation when you do
5 ajax requests on a page (incrementing page version by 5). Then you
reload the page (ctrl+r) and got those 5 versions reverted. That's
because it's not possible to update the url in javascript withou
reloading the page. Changing url hash doesn't help, as it's not
submitted to server.
I've been thinking about supporting ajax and backbutton in wicket, but
this thing is a real showstopper.
-Matej
>
>
>> B.t.w.: thanks for the great support, the quick response from the core
>> developers, the open mind to new ideas, etc. We made the right choice in
>> going to Wicket !
>
>
> glad to hear it!
>
> -igor
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Igor Vaynberg <ig...@gmail.com>.
On 2/8/07, Jan Vermeulen <ja...@isencia.com> wrote:
>
>
> >but what is a previous page? you said you only have a single page?
>
> Yes, we have one 'physical' Wicket page. But of course, our application
> contains various 'conceptual' pages (physically panels), i.e. components
> that make up the body of that single page, and that we go replacing as the
> user navigates. With previous, I mean the same Wicket page, but a previous
> panel.
i see
>wicket's ajax requests should never generate a new version, because ajax
> requests do
> >not change the page url and thus there is no back-button history - and so
> a
> >version is not needed.
>
> That's why I started this thread in the first place: we are using ajax
> requests to replace these 'conceptual pages' (panels), and would have
> liked
> a history of that. But for what I read around here, this would be a hell
> of
> a job. I suppose we should re-render the whole page each time.
hmm....yes it would be quiet difficult. the thing is that wicket is not a
100% ajax driven framework so we have some limitations when compared to the
likes of backbase and gwt when it comes to things such as this. you see our
versioning is designed to keep state in sync with the backbutton of the
browser which is of course non-existant when it comes to ajax.
im not really sure how gwt emulates the back button, maybe we can look at
that and use the same approach. keep in mind that most of us are not
javascript gurus :) this would defintely be the area where we could use the
help/input/ideas/patches from our users :) it should be doable, but
difficult :)
> B.t.w.: thanks for the great support, the quick response from the core
> developers, the open mind to new ideas, etc. We made the right choice in
> going to Wicket !
glad to hear it!
-igor
Re: Single-page applications: bad idea in Wicket ?
Posted by Jan Vermeulen <ja...@isencia.com>.
>but what is a previous page? you said you only have a single page?
Yes, we have one 'physical' Wicket page. But of course, our application
contains various 'conceptual' pages (physically panels), i.e. components
that make up the body of that single page, and that we go replacing as the
user navigates. With previous, I mean the same Wicket page, but a previous
panel.
>wicket's ajax requests should never generate a new version, because ajax
requests do
>not change the page url and thus there is no back-button history - and so a
>version is not needed.
That's why I started this thread in the first place: we are using ajax
requests to replace these 'conceptual pages' (panels), and would have liked
a history of that. But for what I read around here, this would be a hell of
a job. I suppose we should re-render the whole page each time.
Jan.
B.t.w.: thanks for the great support, the quick response from the core
developers, the open mind to new ideas, etc. We made the right choice in
going to Wicket !
--
View this message in context: http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html#a8873296
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Single-page applications: bad idea in Wicket ?
Posted by Igor Vaynberg <ig...@gmail.com>.
On 2/8/07, Jan Vermeulen <ja...@isencia.com> wrote:
>
> So is it a bad practice to simulate this back-button behaviour in buttons
> within the page ?
i think so, wicket handles all this for you by detecting changes to the page
(when page.dirty() is called)
We have a lot of pages where 'exit' or 'cancel' buttons
> mean 'go back to the previous page'.
>
but what is a previous page? you said you only have a single page? wicket's
ajax requests should never generate a new version, because ajax requests do
not change the page url and thus there is no back-button history - and so a
version is not needed.
-igor
Re: Single-page applications: bad idea in Wicket ?
Posted by Jan Vermeulen <ja...@isencia.com>.
>This would work fine now i guess in the latest code of 1.3
>But that is because a page version is now always a different instance.
>Because we don't rollback anymore
>the same page instance (there is no changelist anymore)
We're working with the Wicket 2.0 trunk. Will these changes of 1.3 be
applied to 2.0 ?
>But this will not work when you use the accessstackpagemap (the normal
>httpsessionstore impl)
>Because then what happens is that the current page is changed underneath
>your own call.
>that could really result in all kind of strange things.
We actually are having all kinds of strange behavior because of changes to
the current page: we are programmatically doing back-button behaviour by
retrieving the previous page/version pair from the pageStore. This is
causing problems due to the fact that we have only one page: so the undo is
applied to the same page instance that is being changed due to submit.
So is it a bad practice to simulate this back-button behaviour in buttons
within the page ? We have a lot of pages where 'exit' or 'cancel' buttons
mean 'go back to the previous page'.
>I also don't know if currentversionnumber-1 is the right page you want.
>Because if the version number is already increased before that onsubmit
call
>(not very likely)
>then -1 is the page you just got from and not the page before that.
I know. I used RequestParameters.getVersionNumber() in some other test. The
result is different if you change the input.
--
View this message in context: http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html#a8867182
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Single-page applications: bad idea in Wicket ?
Posted by Johan Compagner <jc...@gmail.com>.
hmmm
new Button<Object>(form,"previous") {
public void onSubmit() {
getPage().getVersion(getPage().getCurrentVersionNumber()-1);
}
};
This would work fine now i guess in the latest code of 1.3
But that is because a page version is now always a different instance.
Because we don't rollback anymore
the same page instance (there is no changelist anymore)
But this will not work when you use the accessstackpagemap (the normal
httpsessionstore impl)
Because then what happens is that the current page is changed underneath
your own call.
that could really result in all kind of strange things.
That page getVersion is really an wicket internal thing...
I also don't know if currentversionnumber-1 is the right page you want.
Because if the version number is already increased before that onsubmit call
(not very likely)
then -1 is the page you just got from and not the page before that.
johan
On 2/7/07, Jan Vermeulen <ja...@isencia.com> wrote:
>
>
> Here is the code of a page that can simulate the problem:
>
> The java source:
>
> import wicket.markup.html.WebPage;
> import wicket.markup.html.basic.Label;
> import wicket.markup.html.form.Button;
> import wicket.markup.html.form.Form;
> import wicket.markup.html.form.TextField;
> import wicket.model.IModel;
> import wicket.model.Model;
>
> public class TestPage extends WebPage {
> private static final long serialVersionUID = 1L;
>
> @SuppressWarnings("serial")
> public TestPage()
> {
> super();
>
> Form form = new Form(this,"form");
> new TextField<String>(form,"input",new
> Model<String>()).setVersioned(true);
> new Button<String>(form,"ok") {
> public void onSubmit() {
> }
> };
> new Button<Object>(form,"previous") {
> public void onSubmit() {
>
> getPage().getVersion(getPage().getCurrentVersionNumber()-1);
> }
> };
>
> IModel<Integer> outputModel = new IModel<Integer>() {
> public Integer getObject() {
>
> return(getPage().getCurrentVersionNumber());
> }
> public void setObject(Integer object) {}
> public void detach() {}
> };
> new Label(this,"output",outputModel);
> }
> }
>
> the markup:
> <html>
> <head>
> <title>TestPage</title>
> </head>
> <body>
> <h1>TestPage</h1>
> <form wicket:id="form">
> <input type="text" wicket:id="input"></input>
> <button wicket:id="ok" type=submit>OK</button>
> <button wicket:id="previous" type=submit>Previous</button>
> </form>
> Version: <span wicket:id="output"></span>
> </body>
> </html>
>
> The problem occurs whenever you change the value of the input field, and
> hits the Previous button.
> If you created 3 versions already, it will render the contents of the
> version 1 with versionnumber 2.
> And if you hit the Previous buton once again, it will render the contents
> of
> version 3 with versionnumber 1 (this last one because it finally called
> endVersion after the undo, saving the pending changeList).
>
> So you are telling me I cannot call getVersion(oldVersionNumber) on a page
> while the flag FLAG_NEW_VERSION is true ? I cannot read this flag from
> outside. If what I do is wrong, shouldn't there be some protection against
> this type of erroneous usage ?
>
> Jan.
>
>
> Johan Compagner wrote:
> >
> >>
> >> * each time beginVersion is called, the versionNumber is incremented
> and
> >> a
> >> new changeList is created. But that new changeList is NOT added to the
> >> stack
> >> of changeLists.
> >
> >
> > yes thats right that is done in the endVersion() call.
> > Adding it before hand shouldn't make any sense.
> >
> >
> > * when getVersion(int versionNumber) is called with an older
> versionNumber
> >> after a call to beginVersion() and before a call to endVersion(), the
> >> undo()
> >> method is called, which pops the last changeList from the stack and
> >> decrements the versionNumber. Since the 'current' changeList is not yet
> >> on
> >> the stack, it pops one more changeList from the stack than it should.
> >
> >
> > This is really really wrong. This should never be possible
> > How does it happens that that call to getVersion() is done twice at the
> > same
> > time??
> > A page shouldn't be accesses more then once (at the same time)
> >
> >
> > Something to be corrected ? Mayby the newly created changeList should be
> >> added to the stack immediately ? Or is it more correct to not increment
> >> the
> >> versionNumber until the call to endVersion() ?
> >
> >
> >
> > No it shouldn't because when happens then if the second call did happen
> > for
> > an old version?
> > And another request is happening at the same time for another?
> > Thats really bad, shouldn't happen at anytime. So if you have a test
> case
> > for that then
> > i would really like to see it.
> >
> > johan
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html#a8850275
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Jan Vermeulen <ja...@isencia.com>.
Here is the code of a page that can simulate the problem:
The java source:
import wicket.markup.html.WebPage;
import wicket.markup.html.basic.Label;
import wicket.markup.html.form.Button;
import wicket.markup.html.form.Form;
import wicket.markup.html.form.TextField;
import wicket.model.IModel;
import wicket.model.Model;
public class TestPage extends WebPage {
private static final long serialVersionUID = 1L;
@SuppressWarnings("serial")
public TestPage()
{
super();
Form form = new Form(this,"form");
new TextField<String>(form,"input",new
Model<String>()).setVersioned(true);
new Button<String>(form,"ok") {
public void onSubmit() {
}
};
new Button<Object>(form,"previous") {
public void onSubmit() {
getPage().getVersion(getPage().getCurrentVersionNumber()-1);
}
};
IModel<Integer> outputModel = new IModel<Integer>() {
public Integer getObject() {
return(getPage().getCurrentVersionNumber());
}
public void setObject(Integer object) {}
public void detach() {}
};
new Label(this,"output",outputModel);
}
}
the markup:
<html>
<head>
<title>TestPage</title>
</head>
<body>
<h1>TestPage</h1>
<form wicket:id="form">
<input type="text" wicket:id="input"></input>
<button wicket:id="ok" type=submit>OK</button>
<button wicket:id="previous" type=submit>Previous</button>
</form>
Version: <span wicket:id="output"></span>
</body>
</html>
The problem occurs whenever you change the value of the input field, and
hits the Previous button.
If you created 3 versions already, it will render the contents of the
version 1 with versionnumber 2.
And if you hit the Previous buton once again, it will render the contents of
version 3 with versionnumber 1 (this last one because it finally called
endVersion after the undo, saving the pending changeList).
So you are telling me I cannot call getVersion(oldVersionNumber) on a page
while the flag FLAG_NEW_VERSION is true ? I cannot read this flag from
outside. If what I do is wrong, shouldn't there be some protection against
this type of erroneous usage ?
Jan.
Johan Compagner wrote:
>
>>
>> * each time beginVersion is called, the versionNumber is incremented and
>> a
>> new changeList is created. But that new changeList is NOT added to the
>> stack
>> of changeLists.
>
>
> yes thats right that is done in the endVersion() call.
> Adding it before hand shouldn't make any sense.
>
>
> * when getVersion(int versionNumber) is called with an older versionNumber
>> after a call to beginVersion() and before a call to endVersion(), the
>> undo()
>> method is called, which pops the last changeList from the stack and
>> decrements the versionNumber. Since the 'current' changeList is not yet
>> on
>> the stack, it pops one more changeList from the stack than it should.
>
>
> This is really really wrong. This should never be possible
> How does it happens that that call to getVersion() is done twice at the
> same
> time??
> A page shouldn't be accesses more then once (at the same time)
>
>
> Something to be corrected ? Mayby the newly created changeList should be
>> added to the stack immediately ? Or is it more correct to not increment
>> the
>> versionNumber until the call to endVersion() ?
>
>
>
> No it shouldn't because when happens then if the second call did happen
> for
> an old version?
> And another request is happening at the same time for another?
> Thats really bad, shouldn't happen at anytime. So if you have a test case
> for that then
> i would really like to see it.
>
> johan
>
>
--
View this message in context: http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html#a8850275
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Single-page applications: bad idea in Wicket ?
Posted by Johan Compagner <jc...@gmail.com>.
>
> * each time beginVersion is called, the versionNumber is incremented and a
> new changeList is created. But that new changeList is NOT added to the
> stack
> of changeLists.
yes thats right that is done in the endVersion() call.
Adding it before hand shouldn't make any sense.
* when getVersion(int versionNumber) is called with an older versionNumber
> after a call to beginVersion() and before a call to endVersion(), the
> undo()
> method is called, which pops the last changeList from the stack and
> decrements the versionNumber. Since the 'current' changeList is not yet on
> the stack, it pops one more changeList from the stack than it should.
This is really really wrong. This should never be possible
How does it happens that that call to getVersion() is done twice at the same
time??
A page shouldn't be accesses more then once (at the same time)
Something to be corrected ? Mayby the newly created changeList should be
> added to the stack immediately ? Or is it more correct to not increment
> the
> versionNumber until the call to endVersion() ?
No it shouldn't because when happens then if the second call did happen for
an old version?
And another request is happening at the same time for another?
Thats really bad, shouldn't happen at anytime. So if you have a test case
for that then
i would really like to see it.
johan
Re: Single-page applications: bad idea in Wicket ?
Posted by Jan Vermeulen <ja...@isencia.com>.
Talking about bugs and referring to the thread
http://www.nabble.com/refactor-storing-pages-and-versions-tf2943670.html#a8231263:
We are probably one of the few who did overwrite the UndoPageVersionManager,
and the reason is a bug in that implementation:
* each time beginVersion is called, the versionNumber is incremented and a
new changeList is created. But that new changeList is NOT added to the stack
of changeLists.
* when getVersion(int versionNumber) is called with an older versionNumber
after a call to beginVersion() and before a call to endVersion(), the undo()
method is called, which pops the last changeList from the stack and
decrements the versionNumber. Since the 'current' changeList is not yet on
the stack, it pops one more changeList from the stack than it should.
Something to be corrected ? Mayby the newly created changeList should be
added to the stack immediately ? Or is it more correct to not increment the
versionNumber until the call to endVersion() ?
Jan.
Eelco Hillenius wrote:
>
>> if there are problems with 2.0 supporting this then they should be
>> addressed, feel free to open jira issues.
>
> It's in 1.3 too (and yes, in fact it *is* potentially problematic for
> the app we're working on as well). And there is JIRA issue
> http://issues.apache.org/jira/browse/WICKET-201 (which refers to
> http://www.nabble.com/refactor-storing-pages-and-versions-tf2943670.html#a8231263).
>
> Eelco
>
>
--
View this message in context: http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html#a8832724
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Single-page applications: bad idea in Wicket ?
Posted by Eelco Hillenius <ee...@gmail.com>.
> if there are problems with 2.0 supporting this then they should be
> addressed, feel free to open jira issues.
It's in 1.3 too (and yes, in fact it *is* potentially problematic for
the app we're working on as well). And there is JIRA issue
http://issues.apache.org/jira/browse/WICKET-201 (which refers to
http://www.nabble.com/refactor-storing-pages-and-versions-tf2943670.html#a8231263).
Eelco
Re: Single-page applications: bad idea in Wicket ?
Posted by Igor Vaynberg <ig...@gmail.com>.
i work on an application that is mostly panel driven as well, albeit we do
not use that much ajax _yet_. so there is definenetely nothing wrong with
this approach, any component hierarchy goes.
if there are problems with 2.0 supporting this then they should be
addressed, feel free to open jira issues.
-igor
On 2/6/07, Jan Vermeulen <ja...@isencia.com> wrote:
>
>
> We are currently building an application in Wicket (2.0) that has only a
> single page: that page contains a border where template markup is defined.
> The body of that border is a panel that gets replaced while the user
> navigates through the application (something similar to the wizard
> implementation in Wicket, but without having created all wizard panels
> from
> the start).
>
> Advantages:
> * we use Ajax requestTargets that only replace the changing part of the
> page: less flicker, less network traffic.
> * as a templating alternative (compared to the extension templating
> mechanism), it allows for the body of the template NOT to be an extension
> of
> the template page.
> * if the action is limited to an smaller part of the page (f.i. a modal
> dialog), same logic applies.
>
> Problems with Wicket:
> * the SecondLevelCachePageStore is 'page-oriented': while I remain in the
> same page, nothing gets flushed to disk.
> * the UndoVersionManager is maintained in the page, and so its changeLists
> are using up memory as long as that page is not serialized to disk. I am
> aware of the open discussion on refactoring of the pageStore &
> versionManager: the 'single-page application' is an extreme case of the
> 'replace-component' syndrome (cfr.
>
> http://www.nabble.com/refactor-storing-pages-and-versions-tf2943670.html#a8231263
> ).
> * since the last change in Wicket 2.0 with 'mergeversion' in the
> UndoVersionManager, all Ajax requests are by default considered as
> candidate
> for merging to the actual version i.s.o. creating a new version. This is a
> good idea for changes applied to the same page. But in our case, page
> navigation is also done through ajax requests, and here we clearly want a
> new version for these requests. We solved this problem overwriting the
> Request.mergeVersion() method. But we felt that there might be a more
> generic need to differenciate between ajax requests that require merging
> and
> ajax requests that require a new version.
>
> Did we take the wrong approach ? Or should Wicket be better prepared to
> handle a lot of ajax modifications to the same page ?
>
>
> --
> View this message in context:
> http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html#a8831903
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Johan Compagner <jc...@gmail.com>.
Maybe if such a hybrid url pointed only to a page id. And not a version or
better said
always the last version....
Then the refresh would not be a problem..
But i dont know if we can generate urls that are in the browser that just
always gets the last
page version. Because how do you go back then?
So if hybrid urls (we already kind of have hybrid urls...) did also contain
version info besides the pageid then the current fix is still needed.
johan
On 2/6/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> this is where matej's idea of hybrid urls comes in. perhaps he can
> elaborate
> a bit more...
>
> -igor
>
>
> On 2/6/07, Johan Compagner <jc...@gmail.com> wrote:
> >
> > On 2/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > > Problems with Wicket:
> > > > * the SecondLevelCachePageStore is 'page-oriented': while I remain
> in
> > > the
> > > > same page, nothing gets flushed to disk.
> >
> >
> > first it should get flushed to disk, eelco was always complaining that
> we
> > saved to much
> > I just fixed it more so that saves are only happening when it really
> > should
> > be happening
> > 1> when the page is created and pushed to the pagemap
> > 2> when a version change is made. (ajax or not)
> >
> > > * the UndoVersionManager is maintained in the page, and so its
> > changeLists
> > > > are using up memory as long as that page is not serialized to disk.
> I
> > am
> > > > aware of the open discussion on refactoring of the pageStore &
> > > > versionManager: the 'single-page application' is an extreme case of
> > the
> > > > 'replace-component' syndrome (cfr.
> > > >
> > >
> >
> http://www.nabble.com/refactor-storing-pages-and-versions-tf2943670.html#a8231263
> > > ).
> > >
> > > As you can see from that thread it is an issue I've been pushing for a
> > > while to be looked at (Johan!). So there is nothing wrong with you
> > > following a component replacement strategy rather than page based,
> > > just something wrong with Wicket (it's a bug).
> >
> >
> > yes this is fixed now. the SecondLevelCache doesn't hold any changelist
> > anymore
> > so when a back button is used the page is read from disk.
> > we do now have our own IPageVersionManager for the second level cache
> > that doesn't do much any more except incrementing the version number
> > and storing the page to the filestore when an endVersion is called.
> >
> >
> > > * since the last change in Wicket 2.0 with 'mergeversion' in the
> > > > UndoVersionManager, all Ajax requests are by default considered as
> > > candidate
> > > > for merging to the actual version i.s.o. creating a new version.
> This
> > is
> > > a
> > > > good idea for changes applied to the same page. But in our case,
> page
> > > > navigation is also done through ajax requests, and here we clearly
> > want
> > > a
> > > > new version for these requests. We solved this problem overwriting
> the
> > > > Request.mergeVersion() method. But we felt that there might be a
> more
> > > > generic need to differenciate between ajax requests that require
> > merging
> > > and
> > > > ajax requests that require a new version.
> > >
> > > I'll leave that for someone else to comment on, as I missed the idea
> > > behind that. Can someone explain on the dev list?
> >
> >
> >
> > Ajax request shouln't update the version of a page.
> > Because everything thats on the page that isn't rerendered still points
> to
> > the old version of the page
> > including the url in the browser. So if you click a link/submit a form
> it
> > directly does an undo
> > And ajax isn't added to the backbutton because thats what an ajax
> request
> > is. So no version
> > should be created because there is no stack in the browser.
> >
> > One other example, if you alter the page on an ajax request and a
> version
> > is
> > made.
> > Then you do a refresh in the browser.. all the things the ajax requests
> > did
> > change on the page are reverted!! Gone!
> >
> > Now the big question is when you do want to have a backbutton with ajax
> > request.
> > How are we going to support that. and how is it done?
> > How is the history in the browser altered? And with what kind of url?
> >
> > johan
> >
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Igor Vaynberg <ig...@gmail.com>.
this is where matej's idea of hybrid urls comes in. perhaps he can elaborate
a bit more...
-igor
On 2/6/07, Johan Compagner <jc...@gmail.com> wrote:
>
> On 2/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > > Problems with Wicket:
> > > * the SecondLevelCachePageStore is 'page-oriented': while I remain in
> > the
> > > same page, nothing gets flushed to disk.
>
>
> first it should get flushed to disk, eelco was always complaining that we
> saved to much
> I just fixed it more so that saves are only happening when it really
> should
> be happening
> 1> when the page is created and pushed to the pagemap
> 2> when a version change is made. (ajax or not)
>
> > * the UndoVersionManager is maintained in the page, and so its
> changeLists
> > > are using up memory as long as that page is not serialized to disk. I
> am
> > > aware of the open discussion on refactoring of the pageStore &
> > > versionManager: the 'single-page application' is an extreme case of
> the
> > > 'replace-component' syndrome (cfr.
> > >
> >
> http://www.nabble.com/refactor-storing-pages-and-versions-tf2943670.html#a8231263
> > ).
> >
> > As you can see from that thread it is an issue I've been pushing for a
> > while to be looked at (Johan!). So there is nothing wrong with you
> > following a component replacement strategy rather than page based,
> > just something wrong with Wicket (it's a bug).
>
>
> yes this is fixed now. the SecondLevelCache doesn't hold any changelist
> anymore
> so when a back button is used the page is read from disk.
> we do now have our own IPageVersionManager for the second level cache
> that doesn't do much any more except incrementing the version number
> and storing the page to the filestore when an endVersion is called.
>
>
> > * since the last change in Wicket 2.0 with 'mergeversion' in the
> > > UndoVersionManager, all Ajax requests are by default considered as
> > candidate
> > > for merging to the actual version i.s.o. creating a new version. This
> is
> > a
> > > good idea for changes applied to the same page. But in our case, page
> > > navigation is also done through ajax requests, and here we clearly
> want
> > a
> > > new version for these requests. We solved this problem overwriting the
> > > Request.mergeVersion() method. But we felt that there might be a more
> > > generic need to differenciate between ajax requests that require
> merging
> > and
> > > ajax requests that require a new version.
> >
> > I'll leave that for someone else to comment on, as I missed the idea
> > behind that. Can someone explain on the dev list?
>
>
>
> Ajax request shouln't update the version of a page.
> Because everything thats on the page that isn't rerendered still points to
> the old version of the page
> including the url in the browser. So if you click a link/submit a form it
> directly does an undo
> And ajax isn't added to the backbutton because thats what an ajax request
> is. So no version
> should be created because there is no stack in the browser.
>
> One other example, if you alter the page on an ajax request and a version
> is
> made.
> Then you do a refresh in the browser.. all the things the ajax requests
> did
> change on the page are reverted!! Gone!
>
> Now the big question is when you do want to have a backbutton with ajax
> request.
> How are we going to support that. and how is it done?
> How is the history in the browser altered? And with what kind of url?
>
> johan
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Matej Knopp <ma...@knopp.sk>.
Al Maw wrote:
> Matej Knopp wrote:
>> First of all, the hybrid urls would fix the refresh problem, but
>> definitely won't fix ajax back button.
>>
>> I don't see much we can do about supporting back button with ajax.
>> That can be possible with full blown ajax framework (like backbase),
>> but wicket was never meant to be it.
>>
>> I see multiple problems:
>> 1 - the urls of page links have to be changed. Fixing href of anchors
>> could be possible (although a big ugly hack if you ask me), but we
>> have lot of url in generated javascript. I don't see easy and reliable
>> way to fix it.
>
> I need to look into this in more detail, but do we generate URLs in
> JavaScript that matter when things change? If so, we surely already need
> to be reloading that JavaScript file? So it won't work in an AJAX world
> anyway, if you see what I mean. If the URL is generated within the AJAX
> requestcycle, then it should be fine - we can append the # reference there.
By javascript url i mean things like onclick="wicketAjaxGet('<url>',
...). or even window.location, etc. you get the idea
>
>> Another problem is the page url. It would reflect old version and
>> there is nothing we can do about it.
>>
>> So if we supported ajax versioning, imagine this situation. User comes
>> to a page, interact with it and creates 20 new versions. Then he for
>> some reason refreshes the page and gets those 20 versions reverted.
>> This is IMHO _much_ worse than not versioning at all.
>
> Yeah, you need to update the URL and add a #versionNumber anchor to it,
> so this doesn't happen. IIRC, Safari has issues with this - it doesn't
> update the history properly so this approach doesn't work well with that
> browser.
>
>> Only way we can alter url in javascript is to change the hash (part of
>> url after #). Unfortunately, the hash doesn't get submitted to the
>> server, so on next request the server can not find out what the hash was.
>
> This is the approach Google use no some of their apps to fix the
> back-button issue - you keep a version number after the hash. You can
> obviously push this over in your AJAX requests, but you need it to work
> for non-AJAX stuff too, as you say. The things you need to fix are
> pretty much anything with a URL in, right? So we could just walk the DOM
> on each AJAX round-trip and add/change any src/link/href/whatever to
> have a version number in it as a parameter? I don't think that's that
> much of a hack, fwiw. See above for Javascript thoughts, although more
> investigation required on that (I don't know if you might have a
> component that is generated in page version 3 need to maintain a URL to
> a component generated in page version 2 - I don't think this makes
> sense, in which case this is all probably pretty straightforward).
You're not listening :)
It doesn't matter if you put the hash in url or not, beceuse it will
_not_ be submitted on request.
So if you increase page version and then refresh page (ctrl+r), the hash
will not get to server, thus the version will be reverterd. Full blown
ajax toolkits do this differently. You will get the page from server
(without hash), and after that, an ajaxrequesttarget is fired that loads
the page content (you can use the version information in the ajaxrequest
target, that's not an issue). But with approach like this, the crawlers
will no longer be able to index your site.
>
> I'm not sure how all this interacts if you genuinely want to link to a
> page using an anchor. :)
>
> http://www.contentwithstyle.co.uk/Articles/38/ is definitely worth a read.
>
>
> Al
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Al Maw <wi...@almaw.com>.
Matej Knopp wrote:
> First of all, the hybrid urls would fix the refresh problem, but
> definitely won't fix ajax back button.
>
> I don't see much we can do about supporting back button with ajax. That
> can be possible with full blown ajax framework (like backbase), but
> wicket was never meant to be it.
>
> I see multiple problems:
> 1 - the urls of page links have to be changed. Fixing href of anchors
> could be possible (although a big ugly hack if you ask me), but we have
> lot of url in generated javascript. I don't see easy and reliable way to
> fix it.
I need to look into this in more detail, but do we generate URLs in
JavaScript that matter when things change? If so, we surely already need
to be reloading that JavaScript file? So it won't work in an AJAX world
anyway, if you see what I mean. If the URL is generated within the AJAX
requestcycle, then it should be fine - we can append the # reference there.
> Another problem is the page url. It would reflect old version and there
> is nothing we can do about it.
>
> So if we supported ajax versioning, imagine this situation. User comes
> to a page, interact with it and creates 20 new versions. Then he for
> some reason refreshes the page and gets those 20 versions reverted. This
> is IMHO _much_ worse than not versioning at all.
Yeah, you need to update the URL and add a #versionNumber anchor to it,
so this doesn't happen. IIRC, Safari has issues with this - it doesn't
update the history properly so this approach doesn't work well with that
browser.
> Only way we can alter url in javascript is to change the hash (part of
> url after #). Unfortunately, the hash doesn't get submitted to the
> server, so on next request the server can not find out what the hash was.
This is the approach Google use no some of their apps to fix the
back-button issue - you keep a version number after the hash. You can
obviously push this over in your AJAX requests, but you need it to work
for non-AJAX stuff too, as you say. The things you need to fix are
pretty much anything with a URL in, right? So we could just walk the DOM
on each AJAX round-trip and add/change any src/link/href/whatever to
have a version number in it as a parameter? I don't think that's that
much of a hack, fwiw. See above for Javascript thoughts, although more
investigation required on that (I don't know if you might have a
component that is generated in page version 3 need to maintain a URL to
a component generated in page version 2 - I don't think this makes
sense, in which case this is all probably pretty straightforward).
I'm not sure how all this interacts if you genuinely want to link to a
page using an anchor. :)
http://www.contentwithstyle.co.uk/Articles/38/ is definitely worth a read.
Al
Re: Single-page applications: bad idea in Wicket ?
Posted by Matej Knopp <ma...@knopp.sk>.
First of all, the hybrid urls would fix the refresh problem, but
definitely won't fix ajax back button.
I don't see much we can do about supporting back button with ajax. That
can be possible with full blown ajax framework (like backbase), but
wicket was never meant to be it.
I see multiple problems:
1 - the urls of page links have to be changed. Fixing href of anchors
could be possible (although a big ugly hack if you ask me), but we have
lot of url in generated javascript. I don't see easy and reliable way to
fix it.
Another problem is the page url. It would reflect old version and there
is nothing we can do about it.
So if we supported ajax versioning, imagine this situation. User comes
to a page, interact with it and creates 20 new versions. Then he for
some reason refreshes the page and gets those 20 versions reverted. This
is IMHO _much_ worse than not versioning at all.
Only way we can alter url in javascript is to change the hash (part of
url after #). Unfortunately, the hash doesn't get submitted to the
server, so on next request the server can not find out what the hash was.
-Matej
Eelco Hillenius wrote:
> On 2/6/07, Johan Compagner <jc...@gmail.com> wrote:
>> My question also was how we are going to support it in wicket.
>> If anybody has a good idea.. What kind of urls do you need from wicket..
>
> If you increase the version, you need to update all the links with the
> new version info in it in the page you reply back to. Sucks to do, but
> at least the whole computation takes place at the client. Then you
> need to generate a new location so that you can react on the back
> event, and when that happens, you need to revert those links to the
> previous state (so we'd need to store that info in the client as
> well). Etc.
>
> There's quite a few articles out there, for instance see
> http://dev2dev.bea.com/pub/a/2006/01/ajax-back-button.html
>
> What it takes from us now is to use our brains and come up with a solution.
>
> Eelco
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Eelco Hillenius <ee...@gmail.com>.
On 2/6/07, Johan Compagner <jc...@gmail.com> wrote:
> My question also was how we are going to support it in wicket.
> If anybody has a good idea.. What kind of urls do you need from wicket..
If you increase the version, you need to update all the links with the
new version info in it in the page you reply back to. Sucks to do, but
at least the whole computation takes place at the client. Then you
need to generate a new location so that you can react on the back
event, and when that happens, you need to revert those links to the
previous state (so we'd need to store that info in the client as
well). Etc.
There's quite a few articles out there, for instance see
http://dev2dev.bea.com/pub/a/2006/01/ajax-back-button.html
What it takes from us now is to use our brains and come up with a solution.
Eelco
Re: Single-page applications: bad idea in Wicket ?
Posted by Johan Compagner <jc...@gmail.com>.
My question also was how we are going to support it in wicket.
If anybody has a good idea.. What kind of urls do you need from wicket..
johan
On 2/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > Now the big question is when you do want to have a backbutton with ajax
> > request.
> > How are we going to support that. and how is it done?
> > How is the history in the browser altered? And with what kind of url?
>
> I don't know the details, but frameworks like Dojo and GWT support it,
> and I think there are quite a few articles on this topic on the net.
>
> Eelco
>
Re: Single-page applications: bad idea in Wicket ?
Posted by Eelco Hillenius <ee...@gmail.com>.
> Now the big question is when you do want to have a backbutton with ajax
> request.
> How are we going to support that. and how is it done?
> How is the history in the browser altered? And with what kind of url?
I don't know the details, but frameworks like Dojo and GWT support it,
and I think there are quite a few articles on this topic on the net.
Eelco
Re: Single-page applications: bad idea in Wicket ?
Posted by Johan Compagner <jc...@gmail.com>.
On 2/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > Problems with Wicket:
> > * the SecondLevelCachePageStore is 'page-oriented': while I remain in
> the
> > same page, nothing gets flushed to disk.
first it should get flushed to disk, eelco was always complaining that we
saved to much
I just fixed it more so that saves are only happening when it really should
be happening
1> when the page is created and pushed to the pagemap
2> when a version change is made. (ajax or not)
> * the UndoVersionManager is maintained in the page, and so its changeLists
> > are using up memory as long as that page is not serialized to disk. I am
> > aware of the open discussion on refactoring of the pageStore &
> > versionManager: the 'single-page application' is an extreme case of the
> > 'replace-component' syndrome (cfr.
> >
> http://www.nabble.com/refactor-storing-pages-and-versions-tf2943670.html#a8231263
> ).
>
> As you can see from that thread it is an issue I've been pushing for a
> while to be looked at (Johan!). So there is nothing wrong with you
> following a component replacement strategy rather than page based,
> just something wrong with Wicket (it's a bug).
yes this is fixed now. the SecondLevelCache doesn't hold any changelist
anymore
so when a back button is used the page is read from disk.
we do now have our own IPageVersionManager for the second level cache
that doesn't do much any more except incrementing the version number
and storing the page to the filestore when an endVersion is called.
> * since the last change in Wicket 2.0 with 'mergeversion' in the
> > UndoVersionManager, all Ajax requests are by default considered as
> candidate
> > for merging to the actual version i.s.o. creating a new version. This is
> a
> > good idea for changes applied to the same page. But in our case, page
> > navigation is also done through ajax requests, and here we clearly want
> a
> > new version for these requests. We solved this problem overwriting the
> > Request.mergeVersion() method. But we felt that there might be a more
> > generic need to differenciate between ajax requests that require merging
> and
> > ajax requests that require a new version.
>
> I'll leave that for someone else to comment on, as I missed the idea
> behind that. Can someone explain on the dev list?
Ajax request shouln't update the version of a page.
Because everything thats on the page that isn't rerendered still points to
the old version of the page
including the url in the browser. So if you click a link/submit a form it
directly does an undo
And ajax isn't added to the backbutton because thats what an ajax request
is. So no version
should be created because there is no stack in the browser.
One other example, if you alter the page on an ajax request and a version is
made.
Then you do a refresh in the browser.. all the things the ajax requests did
change on the page are reverted!! Gone!
Now the big question is when you do want to have a backbutton with ajax
request.
How are we going to support that. and how is it done?
How is the history in the browser altered? And with what kind of url?
johan
Re: Single-page applications: bad idea in Wicket ?
Posted by Eelco Hillenius <ee...@gmail.com>.
> Problems with Wicket:
> * the SecondLevelCachePageStore is 'page-oriented': while I remain in the
> same page, nothing gets flushed to disk.
> * the UndoVersionManager is maintained in the page, and so its changeLists
> are using up memory as long as that page is not serialized to disk. I am
> aware of the open discussion on refactoring of the pageStore &
> versionManager: the 'single-page application' is an extreme case of the
> 'replace-component' syndrome (cfr.
> http://www.nabble.com/refactor-storing-pages-and-versions-tf2943670.html#a8231263).
As you can see from that thread it is an issue I've been pushing for a
while to be looked at (Johan!). So there is nothing wrong with you
following a component replacement strategy rather than page based,
just something wrong with Wicket (it's a bug).
> * since the last change in Wicket 2.0 with 'mergeversion' in the
> UndoVersionManager, all Ajax requests are by default considered as candidate
> for merging to the actual version i.s.o. creating a new version. This is a
> good idea for changes applied to the same page. But in our case, page
> navigation is also done through ajax requests, and here we clearly want a
> new version for these requests. We solved this problem overwriting the
> Request.mergeVersion() method. But we felt that there might be a more
> generic need to differenciate between ajax requests that require merging and
> ajax requests that require a new version.
I'll leave that for someone else to comment on, as I missed the idea
behind that. Can someone explain on the dev list?
> Did we take the wrong approach ? Or should Wicket be better prepared to
> handle a lot of ajax modifications to the same page ?
Your approach is fine and Wicket is at fault here.
Eelco