subject:"Re\: \[Wicket\-user\] Nice Url"

hi igor,

thanx a lot for this clarification!

cheers,
martin


On Sun, 2007-04-29 at 18:05 -0700, Igor Vaynberg wrote:
 in reality this isnt how its supposed to work.
 
 usually you would have something like this:
 
 searchpage {
   private criteria crit;
 
searchpage() {
   add(new searchform(form, new PropertyModel(this, crit)); 
   add(new resultsview(view, new PropertyModel(this, crit));
}
 }
 
 that way the form and the view are bound to the same criteria object.
 the form modifies it, and the view renders according to it. you would
 not call any setresponsepage in the form, the same insatance of the
 page would be reused. that is the wicket way. however, if you must
 have that nice bookmarkable url then you need to call
 setresponsepage(class, pageparams) from the form. it is not as clean,
 but it works. 
 
 -igor
 
 On 4/29/07, Martin Grotzke [EMAIL PROTECTED] wrote:
 On Sun, 2007-04-29 at 17:41 -0700, Igor Vaynberg wrote:
  no, once the form is submitted the page is no longer
 bookmarkable and
  so it will lose any bookmarkable/mounted url.
 
  if you want to keep it you can call
 setresponsepage( page.class,
  params) in onsubmit(), but in your case that is silly since
  searchresultspage probably contains the submitted form
 anyways?
 well, i can do this (setResponsePage with params).
 the SearchResultsPage indeed has a also an instance of the
 form, 
 and the user can also initiate a search on the
 SearchResultsPage.
 
 so for each search the SearchForm.onSubmit creates a new
 SearchResultsPage and (indirectly) a new SearchForm...
 
 i just wonder if this this is the way how wicket should work,
 or if 
 this stateless way is s.th. that is not really the target of
 component based frameworks...
 
 thanx  cheers,
 martin
 
 
 
  -igor
 
 
  On 4/29/07, Martin Grotzke  [EMAIL PROTECTED]
 wrote:
  hi all,
 
  i'm just starting with wicket and have a simple
 search
  form, that leads to a SearchResultsPage. 
 
  the SearchResultsPage is mounted as a bookmarkable
 page (via
  mountBookmarkablePage(/search,
 SearchResultsPage.class);),
  although the url that is shown then contains s.th.
 like
  ?wicket:interface=:6:searchForm::IFormSubmitListener...
 
  is it possible to have a nicer url for the submitted
 form?
 
  i'm using wicket 1.2.6 right now...
 
  thanx in advance,
  cheers,
  martin
 
 
 
 
 
 - 
  This SF.net email is sponsored by DB2 Express
  Download DB2 Express C - the FREE version of DB2
 express and
  take
  control of your XML. No limits. Just data. Click to
 get it 
  now.
  http://sourceforge.net/powerbar/db2/
  ___
  Wicket-user mailing list 
  Wicket-user@lists.sourceforge.net
 
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 
 
 -
  This SF.net email is sponsored by DB2 Express
  Download DB2 Express C - the FREE version of DB2 express and
 take 
  control of your XML. No limits. Just data. Click to get it
 now.
  http://sourceforge.net/powerbar/db2/
  ___ Wicket-user
 mailing list Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 -- 
 Martin Grotzke
 http://www.javakaffee.de/blog/
 
 
 -
 This SF.net email is sponsored by DB2 Express 
 Download DB2 Express C - the FREE version of DB2 express and
 take
 control of your XML. No limits. Just data. Click to get it
 now.
 http://sourceforge.net/powerbar/db2/
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express

Re: [Wicket-user] nice url with submitted form

hi igor,

i'm trying to implement your advice, but don't really know
how to do this.

what would the SearchForm then look like? does the form itself
use the model and how is the input field added to the form?

and how can the ResultsView access the value of the PropertyModel?
the model has a getObject(Component) accessor - does this mean that
the ResultsView would need pass the SearchPage into getObject?

thanx  cheers,
martin



On Sun, 2007-04-29 at 18:05 -0700, Igor Vaynberg wrote:
 in reality this isnt how its supposed to work.
 
 usually you would have something like this:
 
 searchpage {
   private criteria crit;
 
searchpage() {
   add(new searchform(form, new PropertyModel(this, crit)); 
   add(new resultsview(view, new PropertyModel(this, crit));
}
 }
 
 that way the form and the view are bound to the same criteria object.
 the form modifies it, and the view renders according to it. you would
 not call any setresponsepage in the form, the same insatance of the
 page would be reused. that is the wicket way. however, if you must
 have that nice bookmarkable url then you need to call
 setresponsepage(class, pageparams) from the form. it is not as clean,
 but it works. 
 
 -igor
 
 On 4/29/07, Martin Grotzke [EMAIL PROTECTED] wrote:
 On Sun, 2007-04-29 at 17:41 -0700, Igor Vaynberg wrote:
  no, once the form is submitted the page is no longer
 bookmarkable and
  so it will lose any bookmarkable/mounted url.
 
  if you want to keep it you can call
 setresponsepage( page.class,
  params) in onsubmit(), but in your case that is silly since
  searchresultspage probably contains the submitted form
 anyways?
 well, i can do this (setResponsePage with params).
 the SearchResultsPage indeed has a also an instance of the
 form, 
 and the user can also initiate a search on the
 SearchResultsPage.
 
 so for each search the SearchForm.onSubmit creates a new
 SearchResultsPage and (indirectly) a new SearchForm...
 
 i just wonder if this this is the way how wicket should work,
 or if 
 this stateless way is s.th. that is not really the target of
 component based frameworks...
 
 thanx  cheers,
 martin
 
 
 
  -igor
 
 
  On 4/29/07, Martin Grotzke  [EMAIL PROTECTED]
 wrote:
  hi all,
 
  i'm just starting with wicket and have a simple
 search
  form, that leads to a SearchResultsPage. 
 
  the SearchResultsPage is mounted as a bookmarkable
 page (via
  mountBookmarkablePage(/search,
 SearchResultsPage.class);),
  although the url that is shown then contains s.th.
 like
  ?wicket:interface=:6:searchForm::IFormSubmitListener...
 
  is it possible to have a nicer url for the submitted
 form?
 
  i'm using wicket 1.2.6 right now...
 
  thanx in advance,
  cheers,
  martin
 
 
 
 
 
 - 
  This SF.net email is sponsored by DB2 Express
  Download DB2 Express C - the FREE version of DB2
 express and
  take
  control of your XML. No limits. Just data. Click to
 get it 
  now.
  http://sourceforge.net/powerbar/db2/
  ___
  Wicket-user mailing list 
  Wicket-user@lists.sourceforge.net
 
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 
 
 -
  This SF.net email is sponsored by DB2 Express
  Download DB2 Express C - the FREE version of DB2 express and
 take 
  control of your XML. No limits. Just data. Click to get it
 now.
  http://sourceforge.net/powerbar/db2/
  ___ Wicket-user
 mailing list Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 -- 
 Martin Grotzke
 http://www.javakaffee.de/blog/
 
 
 -
 This SF.net email is sponsored by DB2 Express 
 Download DB2 Express C - the FREE version of DB2 express and
 take
 control of your XML. No limits. Just data. Click to get it
 now.

Re: [Wicket-user] nice url with submitted form


i suggest you read here:
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models

the idea is pretty simple:
the form submits its data into a bean, and the view renders according to
that bean. this is accomplished by having the form and the view's models
connected to the same bean via models.

-igor


On 4/30/07, Martin Grotzke [EMAIL PROTECTED] wrote:


hi igor,

i'm trying to implement your advice, but don't really know
how to do this.

what would the SearchForm then look like? does the form itself
use the model and how is the input field added to the form?

and how can the ResultsView access the value of the PropertyModel?
the model has a getObject(Component) accessor - does this mean that
the ResultsView would need pass the SearchPage into getObject?

thanx  cheers,
martin



On Sun, 2007-04-29 at 18:05 -0700, Igor Vaynberg wrote:
 in reality this isnt how its supposed to work.

 usually you would have something like this:

 searchpage {
   private criteria crit;

searchpage() {
   add(new searchform(form, new PropertyModel(this, crit));
   add(new resultsview(view, new PropertyModel(this, crit));
}
 }

 that way the form and the view are bound to the same criteria object.
 the form modifies it, and the view renders according to it. you would
 not call any setresponsepage in the form, the same insatance of the
 page would be reused. that is the wicket way. however, if you must
 have that nice bookmarkable url then you need to call
 setresponsepage(class, pageparams) from the form. it is not as clean,
 but it works.

 -igor

 On 4/29/07, Martin Grotzke [EMAIL PROTECTED] wrote:
 On Sun, 2007-04-29 at 17:41 -0700, Igor Vaynberg wrote:
  no, once the form is submitted the page is no longer
 bookmarkable and
  so it will lose any bookmarkable/mounted url.
 
  if you want to keep it you can call
 setresponsepage( page.class,
  params) in onsubmit(), but in your case that is silly since
  searchresultspage probably contains the submitted form
 anyways?
 well, i can do this (setResponsePage with params).
 the SearchResultsPage indeed has a also an instance of the
 form,
 and the user can also initiate a search on the
 SearchResultsPage.

 so for each search the SearchForm.onSubmit creates a new
 SearchResultsPage and (indirectly) a new SearchForm...

 i just wonder if this this is the way how wicket should work,
 or if
 this stateless way is s.th. that is not really the target of
 component based frameworks...

 thanx  cheers,
 martin


 
  -igor
 
 
  On 4/29/07, Martin Grotzke  [EMAIL PROTECTED]
 wrote:
  hi all,
 
  i'm just starting with wicket and have a simple
 search
  form, that leads to a SearchResultsPage.
 
  the SearchResultsPage is mounted as a bookmarkable
 page (via
  mountBookmarkablePage(/search,
 SearchResultsPage.class);),
  although the url that is shown then contains s.th.
 like
 
?wicket:interface=:6:searchForm::IFormSubmitListener...
 
  is it possible to have a nicer url for the submitted
 form?
 
  i'm using wicket 1.2.6 right now...
 
  thanx in advance,
  cheers,
  martin
 
 
 
 

-
  This SF.net email is sponsored by DB2 Express
  Download DB2 Express C - the FREE version of DB2
 express and
  take
  control of your XML. No limits. Just data. Click to
 get it
  now.
  http://sourceforge.net/powerbar/db2/
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
 
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 

-
  This SF.net email is sponsored by DB2 Express
  Download DB2 Express C - the FREE version of DB2 express and
 take
  control of your XML. No limits. Just data. Click to get it
 now.
  http://sourceforge.net/powerbar/db2/
  ___ Wicket-user
 mailing list Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 --
 Martin Grotzke
 http://www.javakaffee.de/blog/

Re: [Wicket-user] nice url with submitted form

hi igor,

i hope i got the idea now. i post my beans here, it would be nice
if could tell me if anything's not following the right path :)

// the start page, simply with the search form
public Index(final PageParameters parameters) {
LOG.debug( Creating new Index page with params  + parameters );
add( new SearchForm( searchForm, new Model() ) );
}

// the search form
public SearchForm(String id, IModel model) {
super( id, model );
add( new TextField( query, model ) );
}

@Override
protected void onSubmit() {
// set response page with page params for bookmarkable urls
final PageParameters params = new PageParameters();
params.add( query, (String) getModelObject() );
setResponsePage( SearchPage.class, params );
}

// the search page with form and results
private String _userInput;

public SearchPage(final PageParameters parameters) {
_userInput = parameters.getString( query );
add( new SearchForm( searchForm, new PropertyModel( this, userInput 
) ) ); 
add( new SearchResultsView( productList, new PropertyModel( this, 
userInput ), this ) );
}

public String getUserInput() {
return _userInput;
}

public void setUserInput( String userInput ) {
_userInput = userInput;
}


cheers,
martin


On Mon, 2007-04-30 at 14:02 -0700, Igor Vaynberg wrote:
 i suggest you read here:
 http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket
 +models
 
 the idea is pretty simple: 
 the form submits its data into a bean, and the view renders according
 to that bean. this is accomplished by having the form and the view's
 models connected to the same bean via models.
 
 -igor
 
 
 On 4/30/07, Martin Grotzke [EMAIL PROTECTED] wrote:
 hi igor,
 
 i'm trying to implement your advice, but don't really know
 how to do this.
 
 what would the SearchForm then look like? does the form itself
 use the model and how is the input field added to the form? 
 
 and how can the ResultsView access the value of the
 PropertyModel?
 the model has a getObject(Component) accessor - does this mean
 that
 the ResultsView would need pass the SearchPage into getObject?
 
 thanx  cheers, 
 martin
 
 
 
 On Sun, 2007-04-29 at 18:05 -0700, Igor Vaynberg wrote:
  in reality this isnt how its supposed to work.
 
  usually you would have something like this:
 
  searchpage { 
private criteria crit;
 
 searchpage() {
add(new searchform(form, new PropertyModel(this,
 crit));
add(new resultsview(view, new PropertyModel(this,
 crit)); 
 }
  }
 
  that way the form and the view are bound to the same
 criteria object.
  the form modifies it, and the view renders according to it.
 you would
  not call any setresponsepage in the form, the same insatance
 of the 
  page would be reused. that is the wicket way. however, if
 you must
  have that nice bookmarkable url then you need to call
  setresponsepage(class, pageparams) from the form. it is not
 as clean,
  but it works. 
 
  -igor
 
  On 4/29/07, Martin Grotzke [EMAIL PROTECTED]
 wrote:
  On Sun, 2007-04-29 at 17:41 -0700, Igor Vaynberg
 wrote: 
   no, once the form is submitted the page is no
 longer
  bookmarkable and
   so it will lose any bookmarkable/mounted url.
  
   if you want to keep it you can call 
  setresponsepage( page.class,
   params) in onsubmit(), but in your case that is
 silly since
   searchresultspage probably contains the submitted
 form
  anyways? 
  well, i can do this (setResponsePage with params).
  the SearchResultsPage indeed has a also an instance
 of the
  form,
  and the user can also initiate a search on the 
  SearchResultsPage.
 
  so for each search the SearchForm.onSubmit creates a
 new
  SearchResultsPage and (indirectly) a new
 SearchForm...
 
  i just wonder if this this is the way how wicket
 should work, 
  or if
  this stateless way is s.th. that is not really the
 target of
  component based frameworks...
 
  thanx  cheers,
  martin
 
 
  
   -igor

Re: [Wicket-user] nice url with submitted form

On Mon, 2007-04-30 at 23:55 +0200, Martin Grotzke wrote:
 hi igor,
 
 i hope i got the idea now. i post my beans here, 
aehem, sorry - forgot to include SearchResultsView:

public SearchResultsView(String id, PropertyModel model ) {
super( id, model );
final String query = (String) getModelObject();
final List? extends Product products = 
((StealthShopApplication)getApplication()).getSearchService().find( query );
setList( products );
}

@SuppressWarnings(serial)
@Override
protected void populateItem( ListItem listItem ) {
final Product product = 
(Product)listItem.getModelObject();
listItem.add( new Label(id, product.getId() ) );
listItem.add( new Label( title, product.getTitle() ) );
listItem.add( new Label( description, product.getDescription() ) );
listItem.add(new Link(showDetailsLink){
public void onClick(){
PageParameters pp = new PageParameters();
pp.add(productId, product.getId());
setResponsePage(Index.class, pp);
}
});
}

cheers :)
martin


 it would be nice
 if could tell me if anything's not following the right path :)
 
 // the start page, simply with the search form
 public Index(final PageParameters parameters) {
 LOG.debug( Creating new Index page with params  + parameters );
 add( new SearchForm( searchForm, new Model() ) );
 }
 
 // the search form
 public SearchForm(String id, IModel model) {
 super( id, model );
 add( new TextField( query, model ) );
 }
 
 @Override
 protected void onSubmit() {
 // set response page with page params for bookmarkable urls
 final PageParameters params = new PageParameters();
 params.add( query, (String) getModelObject() );
 setResponsePage( SearchPage.class, params );
 }
 
 // the search page with form and results
 private String _userInput;
 
 public SearchPage(final PageParameters parameters) {
 _userInput = parameters.getString( query );
 add( new SearchForm( searchForm, new PropertyModel( this, 
 userInput ) ) ); 
 add( new SearchResultsView( productList, new PropertyModel( this, 
 userInput ), this ) );
 }
 
 public String getUserInput() {
 return _userInput;
 }
 
 public void setUserInput( String userInput ) {
 _userInput = userInput;
 }
 
 
 cheers,
 martin
 
 
 On Mon, 2007-04-30 at 14:02 -0700, Igor Vaynberg wrote:
  i suggest you read here:
  http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket
  +models
  
  the idea is pretty simple: 
  the form submits its data into a bean, and the view renders according
  to that bean. this is accomplished by having the form and the view's
  models connected to the same bean via models.
  
  -igor
  
  
  On 4/30/07, Martin Grotzke [EMAIL PROTECTED] wrote:
  hi igor,
  
  i'm trying to implement your advice, but don't really know
  how to do this.
  
  what would the SearchForm then look like? does the form itself
  use the model and how is the input field added to the form? 
  
  and how can the ResultsView access the value of the
  PropertyModel?
  the model has a getObject(Component) accessor - does this mean
  that
  the ResultsView would need pass the SearchPage into getObject?
  
  thanx  cheers, 
  martin
  
  
  
  On Sun, 2007-04-29 at 18:05 -0700, Igor Vaynberg wrote:
   in reality this isnt how its supposed to work.
  
   usually you would have something like this:
  
   searchpage { 
 private criteria crit;
  
  searchpage() {
 add(new searchform(form, new PropertyModel(this,
  crit));
 add(new resultsview(view, new PropertyModel(this,
  crit)); 
  }
   }
  
   that way the form and the view are bound to the same
  criteria object.
   the form modifies it, and the view renders according to it.
  you would
   not call any setresponsepage in the form, the same insatance
  of the 
   page would be reused. that is the wicket way. however, if
  you must
   have that nice bookmarkable url then you need to call
   setresponsepage(class, pageparams) from the form. it is not
  as clean,
   but it works. 
  
   -igor
  
   On 4/29/07, Martin Grotzke [EMAIL PROTECTED]
  wrote:
   On Sun, 2007-04-29 at 17:41 -0700, Igor Vaynberg
  wrote: 
no, once the form is submitted the page is no
  longer
   bookmarkable and
so it will

Re: [Wicket-user] nice url with submitted form


On 4/30/07, Martin Grotzke [EMAIL PROTECTED] wrote:


On Mon, 2007-04-30 at 23:55 +0200, Martin Grotzke wrote:
 hi igor,

 i hope i got the idea now. i post my beans here,
aehem, sorry - forgot to include SearchResultsView:

public SearchResultsView(String id, PropertyModel model ) {
super( id, model );
final String query = (String) getModelObject();
final List? extends Product products =
((StealthShopApplication)getApplication()).getSearchService().find( query );
setList( products );



the above isnt right because the list is refreshed only when the
searchresultsview is created - which only happens once.

instead

class resultsmodel extends abstractreadonlymodel {
 private imodel query;
 public resultsmodel(imodel query) { this.query=query; }
 public object getobject() {
  return
((StealthShopApplication)getApplication()).getSearchService().find(
query.getobject() );
 }
 public void detach() { query.detach(); }
}

setmodel(new resultsmodel(model));

that way listview will get fresh results every page refresh

-igor
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] nice url with submitted form

On Mon, 2007-04-30 at 15:07 -0700, Igor Vaynberg wrote:
 On 4/30/07, Martin Grotzke [EMAIL PROTECTED] wrote:
 On Mon, 2007-04-30 at 23:55 +0200, Martin Grotzke wrote:
  hi igor,
 
  i hope i got the idea now. i post my beans here,
 aehem, sorry - forgot to include SearchResultsView:
 
 public SearchResultsView(String id, PropertyModel model )
 { 
 super( id, model );
 final String query = (String) getModelObject();
 final List? extends Product products =
 ((StealthShopApplication)getApplication()).getSearchService().find( 
 query ); 
 setList( products );
 
 the above isnt right because the list is refreshed only when the
 searchresultsview is created - which only happens once.
hmm, but the SearchPage is created for each request, that shows a
LOG.debug( Creating new SearchPage with params  + parameters );
that I added to the constructor of the SearchPage.

this should be caused by the onSubmit implementation of the SearchForm:

protected void onSubmit() {
// set response page with page params for bookmarkable urls
final PageParameters params = new PageParameters();
params.add( query, (String) getModelObject() );
setResponsePage( SearchPage.class, params );
}

which I implemented like this to have bookmarkable urls.
therefore the SearchResultsView is created for each request.

is this wrong in terms of lifecycle of wicket pages?
would there be another possibility to achieve bookmarkable
pages with a form submit?

cheers,
martin


 
 instead
 
 class resultsmodel extends abstractreadonlymodel { 
   private imodel query;
   public resultsmodel(imodel query) { this.query=query; }
   public object getobject() {
return
 ((StealthShopApplication)getApplication()).getSearchService().find( 
 query.getobject () );
   }
   public void detach() { query.detach(); }
 }
 
 setmodel(new resultsmodel(model));
 
 that way listview will get fresh results every page refresh
 
 -igor
 
 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___ Wicket-user mailing list 
 Wicket-user@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/wicket-user
-- 
Martin Grotzke
http://www.javakaffee.de/blog/


signature.asc
Description: This is a digitally signed message part
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] nice url with submitted form


if you want to maintain the bookmarkable url then no. but this is atypical
of how wicket lifecycle usually works. the model i showed is better because
if you reuse the searchresultsview outside of this lifecycle you are
creating it will still work properly, but if you have no plans on reusing it
then i guess what you do will work too.

-igor


On 4/30/07, Martin Grotzke [EMAIL PROTECTED] wrote:


On Mon, 2007-04-30 at 15:07 -0700, Igor Vaynberg wrote:
 On 4/30/07, Martin Grotzke [EMAIL PROTECTED] wrote:
 On Mon, 2007-04-30 at 23:55 +0200, Martin Grotzke wrote:
  hi igor,
 
  i hope i got the idea now. i post my beans here,
 aehem, sorry - forgot to include SearchResultsView:

 public SearchResultsView(String id, PropertyModel model )
 {
 super( id, model );
 final String query = (String) getModelObject();
 final List? extends Product products =

((StealthShopApplication)getApplication()).getSearchService().find( query );
 setList( products );

 the above isnt right because the list is refreshed only when the
 searchresultsview is created - which only happens once.
hmm, but the SearchPage is created for each request, that shows a
LOG.debug( Creating new SearchPage with params  + parameters );
that I added to the constructor of the SearchPage.

this should be caused by the onSubmit implementation of the SearchForm:

protected void onSubmit() {
// set response page with page params for bookmarkable urls
final PageParameters params = new PageParameters();
params.add( query, (String) getModelObject() );
setResponsePage( SearchPage.class, params );
}

which I implemented like this to have bookmarkable urls.
therefore the SearchResultsView is created for each request.

is this wrong in terms of lifecycle of wicket pages?
would there be another possibility to achieve bookmarkable
pages with a form submit?

cheers,
martin



 instead

 class resultsmodel extends abstractreadonlymodel {
   private imodel query;
   public resultsmodel(imodel query) { this.query=query; }
   public object getobject() {
return
 ((StealthShopApplication)getApplication()).getSearchService().find(
query.getobject () );
   }
   public void detach() { query.detach(); }
 }

 setmodel(new resultsmodel(model));

 that way listview will get fresh results every page refresh

 -igor


-
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
Martin Grotzke
http://www.javakaffee.de/blog/

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] nice url with submitted form

On Mon, 2007-04-30 at 15:23 -0700, Igor Vaynberg wrote:
 if you want to maintain the bookmarkable url then no. but this is
 atypical of how wicket lifecycle usually works. 
ok. do I have to take anything in acount if i use wicket in this
atypical way?

however, until now it feels very good to work with wicket, even
with this more action/mvc like (stateless) aproach... :)

 the model i showed is better because if you reuse the
 searchresultsview outside of this lifecycle you are creating it will
 still work properly, but if you have no plans on reusing it then i
 guess what you do will work too. 
ok, i'll keep that in mind.

thanx a lot for your help,
cheers,
martin


 
 -igor
 
 
 On 4/30/07, Martin Grotzke [EMAIL PROTECTED] wrote:
 On Mon, 2007-04-30 at 15:07 -0700, Igor Vaynberg wrote:
  On 4/30/07, Martin Grotzke [EMAIL PROTECTED]
 wrote:
  On Mon, 2007-04-30 at 23:55 +0200, Martin Grotzke
 wrote: 
   hi igor,
  
   i hope i got the idea now. i post my beans here,
  aehem, sorry - forgot to include SearchResultsView:
 
  public SearchResultsView(String id,
 PropertyModel model ) 
  {
  super( id, model );
  final String query = (String)
 getModelObject();
  final List? extends Product products =
 
 ((StealthShopApplication)getApplication()).getSearchService().find( 
 query ); 
  setList( products );
 
  the above isnt right because the list is refreshed only when
 the
  searchresultsview is created - which only happens once.
 hmm, but the SearchPage is created for each request, that
 shows a 
 LOG.debug( Creating new SearchPage with params  +
 parameters );
 that I added to the constructor of the SearchPage.
 
 this should be caused by the onSubmit implementation of the
 SearchForm:
 
 protected void onSubmit() { 
 // set response page with page params for bookmarkable
 urls
 final PageParameters params = new PageParameters();
 params.add( query, (String) getModelObject() );
 setResponsePage( SearchPage.class, params );
 }
 
 which I implemented like this to have bookmarkable urls.
 therefore the SearchResultsView is created for each request.
 
 is this wrong in terms of lifecycle of wicket pages? 
 would there be another possibility to achieve bookmarkable
 pages with a form submit?
 
 cheers,
 martin
 
 
 
  instead
 
  class resultsmodel extends abstractreadonlymodel {
private imodel query; 
public resultsmodel(imodel query) { this.query=query; }
public object getobject() {
 return
 
 ((StealthShopApplication)getApplication()).getSearchService().find( 
 query.getobject () ); 
}
public void detach() { query.detach(); }
  }
 
  setmodel(new resultsmodel(model));
 
  that way listview will get fresh results every page refresh
 
  -igor 
 
 
 
 -
  This SF.net email is sponsored by DB2 Express
  Download DB2 Express C - the FREE version of DB2 express and
 take
  control of your XML. No limits. Just data. Click to get it
 now.
  http://sourceforge.net/powerbar/db2/
  ___ Wicket-user
 mailing list Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 -- 
 Martin Grotzke
 http://www.javakaffee.de/blog/
 
 
 -
 This SF.net email is sponsored by DB2 Express 
 Download DB2 Express C - the FREE version of DB2 express and
 take
 control of your XML. No limits. Just data. Click to get it
 now.
 http://sourceforge.net/powerbar/db2/
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/

Re: [Wicket-user] nice url with submitted form


On 4/30/07, Martin Grotzke [EMAIL PROTECTED] wrote:


On Mon, 2007-04-30 at 15:23 -0700, Igor Vaynberg wrote:
 if you want to maintain the bookmarkable url then no. but this is
 atypical of how wicket lifecycle usually works.
ok. do I have to take anything in acount if i use wicket in this
atypical way?



noep, nothing special to watch out for.



however, until now it feels very good to work with wicket, even
with this more action/mvc like (stateless) aproach... :)



it feels even better once you use the normal lifecycle :)

-igor



the model i showed is better because if you reuse the
 searchresultsview outside of this lifecycle you are creating it will
 still work properly, but if you have no plans on reusing it then i
 guess what you do will work too.
ok, i'll keep that in mind.

thanx a lot for your help,
cheers,
martin



 -igor


 On 4/30/07, Martin Grotzke [EMAIL PROTECTED] wrote:
 On Mon, 2007-04-30 at 15:07 -0700, Igor Vaynberg wrote:
  On 4/30/07, Martin Grotzke [EMAIL PROTECTED]
 wrote:
  On Mon, 2007-04-30 at 23:55 +0200, Martin Grotzke
 wrote:
   hi igor,
  
   i hope i got the idea now. i post my beans here,
  aehem, sorry - forgot to include SearchResultsView:
 
  public SearchResultsView(String id,
 PropertyModel model )
  {
  super( id, model );
  final String query = (String)
 getModelObject();
  final List? extends Product products =
 

((StealthShopApplication)getApplication()).getSearchService().find( query );
  setList( products );
 
  the above isnt right because the list is refreshed only when
 the
  searchresultsview is created - which only happens once.
 hmm, but the SearchPage is created for each request, that
 shows a
 LOG.debug( Creating new SearchPage with params  +
 parameters );
 that I added to the constructor of the SearchPage.

 this should be caused by the onSubmit implementation of the
 SearchForm:

 protected void onSubmit() {
 // set response page with page params for bookmarkable
 urls
 final PageParameters params = new PageParameters();
 params.add( query, (String) getModelObject() );
 setResponsePage( SearchPage.class, params );
 }

 which I implemented like this to have bookmarkable urls.
 therefore the SearchResultsView is created for each request.

 is this wrong in terms of lifecycle of wicket pages?
 would there be another possibility to achieve bookmarkable
 pages with a form submit?

 cheers,
 martin


 
  instead
 
  class resultsmodel extends abstractreadonlymodel {
private imodel query;
public resultsmodel(imodel query) { this.query=query; }
public object getobject() {
 return
 

((StealthShopApplication)getApplication()).getSearchService().find(
query.getobject () );
}
public void detach() { query.detach(); }
  }
 
  setmodel(new resultsmodel(model));
 
  that way listview will get fresh results every page refresh
 
  -igor
 
 

-
  This SF.net email is sponsored by DB2 Express
  Download DB2 Express C - the FREE version of DB2 express and
 take
  control of your XML. No limits. Just data. Click to get it
 now.
  http://sourceforge.net/powerbar/db2/
  ___ Wicket-user
 mailing list Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 --
 Martin Grotzke
 http://www.javakaffee.de/blog/


-
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and
 take
 control of your XML. No limits. Just data. Click to get it
 now.
 http://sourceforge.net/powerbar/db2/
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user




-
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/

Re: [Wicket-user] nice url with submitted form

On Mon, 2007-04-30 at 15:42 -0700, Igor Vaynberg wrote:
 On 4/30/07, Martin Grotzke [EMAIL PROTECTED] wrote:
 On Mon, 2007-04-30 at 15:23 -0700, Igor Vaynberg wrote:
  if you want to maintain the bookmarkable url then no. but
 this is
  atypical of how wicket lifecycle usually works.
 ok. do I have to take anything in acount if i use wicket in
 this 
 atypical way?
 
 noep, nothing special to watch out for.
cool :)

  
 however, until now it feels very good to work with wicket,
 even 
 with this more action/mvc like (stateless) aproach... :)
 
 it feels even better once you use the normal lifecycle :)
jepp, i believe this :) i have written apps with wingS some times ago
and i loved it - but we could only use for cms-like apps, not for end
users...

now we're going to build s.th. like a shop and i'm looking for
frameworks that match our needs. probably spring-mvc or tapestry would
also be candidates, but what i've read about wicket sounded better :)

cheers,
martin


 
 -igor
  
 
 
  the model i showed is better because if you reuse the
  searchresultsview outside of this lifecycle you are creating
 it will
  still work properly, but if you have no plans on reusing it
 then i
  guess what you do will work too. 
 ok, i'll keep that in mind.
 
 thanx a lot for your help,
 cheers,
 martin
 
 
 
  -igor
 
 
  On 4/30/07, Martin Grotzke [EMAIL PROTECTED]
 wrote:
  On Mon, 2007-04-30 at 15:07 -0700, Igor Vaynberg
 wrote:
   On 4/30/07, Martin Grotzke
 [EMAIL PROTECTED]
  wrote:
   On Mon, 2007-04-30 at 23:55 +0200, Martin
 Grotzke
  wrote:
hi igor,
   
i hope i got the idea now. i post my
 beans here, 
   aehem, sorry - forgot to include
 SearchResultsView:
  
   public SearchResultsView(String id,
  PropertyModel model )
   { 
   super( id, model );
   final String query = (String)
  getModelObject();
   final List? extends Product
 products = 
  
 
 ((StealthShopApplication)getApplication()).getSearchService().find( 
 query );
   setList( products );
  
   the above isnt right because the list is refreshed
 only when 
  the
   searchresultsview is created - which only happens
 once.
  hmm, but the SearchPage is created for each request,
 that
  shows a
  LOG.debug ( Creating new SearchPage with params  +
  parameters );
  that I added to the constructor of the SearchPage.
 
  this should be caused by the onSubmit implementation
 of the 
  SearchForm:
 
  protected void onSubmit() {
  // set response page with page params for
 bookmarkable
  urls
  final PageParameters params = new
 PageParameters(); 
  params.add( query, (String)
 getModelObject() );
  setResponsePage( SearchPage.class, params );
  }
 
  which I implemented like this to have bookmarkable
 urls. 
  therefore the SearchResultsView is created for each
 request.
 
  is this wrong in terms of lifecycle of wicket pages?
  would there be another possibility to achieve
 bookmarkable 
  pages with a form submit?
 
  cheers,
  martin
 
 
  
   instead
  
   class resultsmodel extends abstractreadonlymodel
 { 
 private imodel query;
 public resultsmodel(imodel query)
 { this.query=query; }
 public object getobject() {
  return
   
 
 ((StealthShopApplication)getApplication()).getSearchService().find( 
 query.getobject () );
 }
 public void detach() { query.detach(); }
   }
  
   setmodel(new resultsmodel(model));
  
   that way listview will get fresh results

Re: [Wicket-user] nice url with submitted form

2007-04-29 Thread Igor Vaynberg


no, once the form is submitted the page is no longer bookmarkable and so it
will lose any bookmarkable/mounted url.

if you want to keep it you can call setresponsepage(page.class, params) in
onsubmit(), but in your case that is silly since searchresultspage probably
contains the submitted form anyways?

-igor


On 4/29/07, Martin Grotzke [EMAIL PROTECTED] wrote:


hi all,

i'm just starting with wicket and have a simple search
form, that leads to a SearchResultsPage.

the SearchResultsPage is mounted as a bookmarkable page (via
mountBookmarkablePage(/search, SearchResultsPage.class);),
although the url that is shown then contains s.th. like
?wicket:interface=:6:searchForm::IFormSubmitListener...

is it possible to have a nicer url for the submitted form?

i'm using wicket 1.2.6 right now...

thanx in advance,
cheers,
martin



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] nice url with submitted form

2007-04-29 Thread Martin Grotzke

On Sun, 2007-04-29 at 17:41 -0700, Igor Vaynberg wrote:
 no, once the form is submitted the page is no longer bookmarkable and
 so it will lose any bookmarkable/mounted url.
 
 if you want to keep it you can call setresponsepage(page.class,
 params) in onsubmit(), but in your case that is silly since
 searchresultspage probably contains the submitted form anyways? 
well, i can do this (setResponsePage with params).
the SearchResultsPage indeed has a also an instance of the form,
and the user can also initiate a search on the SearchResultsPage.

so for each search the SearchForm.onSubmit creates a new
SearchResultsPage and (indirectly) a new SearchForm...

i just wonder if this this is the way how wicket should work, or if
this stateless way is s.th. that is not really the target of
component based frameworks...

thanx  cheers,
martin


 
 -igor
 
 
 On 4/29/07, Martin Grotzke [EMAIL PROTECTED] wrote:
 hi all,
 
 i'm just starting with wicket and have a simple search
 form, that leads to a SearchResultsPage.
 
 the SearchResultsPage is mounted as a bookmarkable page (via
 mountBookmarkablePage(/search, SearchResultsPage.class);),
 although the url that is shown then contains s.th. like
 ?wicket:interface=:6:searchForm::IFormSubmitListener...
 
 is it possible to have a nicer url for the submitted form? 
 
 i'm using wicket 1.2.6 right now...
 
 thanx in advance,
 cheers,
 martin
 
 
 
 
 -
 This SF.net email is sponsored by DB2 Express 
 Download DB2 Express C - the FREE version of DB2 express and
 take
 control of your XML. No limits. Just data. Click to get it
 now.
 http://sourceforge.net/powerbar/db2/
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___ Wicket-user mailing list 
 Wicket-user@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/wicket-user
-- 
Martin Grotzke
http://www.javakaffee.de/blog/


signature.asc
Description: This is a digitally signed message part
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] nice url with submitted form

2007-04-29 Thread Igor Vaynberg


in reality this isnt how its supposed to work.

usually you would have something like this:

searchpage {
 private criteria crit;

  searchpage() {
 add(new searchform(form, new PropertyModel(this, crit));
 add(new resultsview(view, new PropertyModel(this, crit));
  }
}

that way the form and the view are bound to the same criteria object. the
form modifies it, and the view renders according to it. you would not call
any setresponsepage in the form, the same insatance of the page would be
reused. that is the wicket way. however, if you must have that nice
bookmarkable url then you need to call setresponsepage(class, pageparams)
from the form. it is not as clean, but it works.

-igor

On 4/29/07, Martin Grotzke [EMAIL PROTECTED] wrote:


On Sun, 2007-04-29 at 17:41 -0700, Igor Vaynberg wrote:
 no, once the form is submitted the page is no longer bookmarkable and
 so it will lose any bookmarkable/mounted url.

 if you want to keep it you can call setresponsepage(page.class,
 params) in onsubmit(), but in your case that is silly since
 searchresultspage probably contains the submitted form anyways?
well, i can do this (setResponsePage with params).
the SearchResultsPage indeed has a also an instance of the form,
and the user can also initiate a search on the SearchResultsPage.

so for each search the SearchForm.onSubmit creates a new
SearchResultsPage and (indirectly) a new SearchForm...

i just wonder if this this is the way how wicket should work, or if
this stateless way is s.th. that is not really the target of
component based frameworks...

thanx  cheers,
martin



 -igor


 On 4/29/07, Martin Grotzke [EMAIL PROTECTED] wrote:
 hi all,

 i'm just starting with wicket and have a simple search
 form, that leads to a SearchResultsPage.

 the SearchResultsPage is mounted as a bookmarkable page (via
 mountBookmarkablePage(/search, SearchResultsPage.class);),
 although the url that is shown then contains s.th. like
 ?wicket:interface=:6:searchForm::IFormSubmitListener...

 is it possible to have a nicer url for the submitted form?

 i'm using wicket 1.2.6 right now...

 thanx in advance,
 cheers,
 martin




-
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and
 take
 control of your XML. No limits. Just data. Click to get it
 now.
 http://sourceforge.net/powerbar/db2/
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user




-
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
Martin Grotzke
http://www.javakaffee.de/blog/

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Nice Url

I guess you are replying just to the sentence  Stateless pages are most likely bookmarkable.and then taking about wicket 1.x not wicket 2.0 (because then it is populated for you)But in 1.x a page is not stateless when a form resides on it thats impossible.
Maybe most likely bookmarkable was a bit wrong. It doesn't have to be ofcourse you could make such a page from anyother type of request (form submit or link click from another request)But the thing is that in default wicket 
1.x such a page will be statefull again because we redirectto it (redirect after post). And that will make the page also statefull...johanOn 10/20/06, 
Eelco Hillenius [EMAIL PROTECTED] wrote:
On 10/20/06, Johan Compagner [EMAIL PROTECTED] wrote: all bookmarkable pages can have forms.. that is already possible at the moment we had bookmarkable pages (like
 wicket 0.x) Again you mixup the notion of Bookmarkable and Stateless Those are NOT the same, especially bookmarkable in regards to stateless. the other way around, Stateless pages are most likely bookmarkable.
No, I don't think so. Are you telling me those forms are populatedautomatically from a 'bookmarkable' url? I think not, and thus youhave to interpret/ repopulate the form yourself. Now bookmarkableforms in the way they are in 
2.0 now can be used just as normal formwith the only difference from an end-user's perspective that you can'tdepend on instance variables.Eelco-
Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

and such a thing would disable also the backbutton. That would be ofcourse good and bad :)johanOn 10/21/06, Upayavira
[EMAIL PROTECTED] wrote:Eelco Hillenius wrote: Such a strategy would be possible, but one downside of it is that that
only works with submits. We have some testing code for client side state saving (serialized page written to a hidden field). We haven't put a lot of effort in it to complete it - though the basic idea works
- as it is not something any of the current committers really believe in. However, if you want to see how a strategy like you proposed could be done, you could check that out (it's in 2.0, ClientPageSavingSessionStore).
That is sending state back to the client - I'm talking about passing akey back, just not in the URL. But yes, you are showing that hiddenfields can be used. I'm sure ways could be worked around to get links to
work (bit of _javascript_ to do a post via a hidden form). Of course, any contributions in the form of patches are always welcome and might serve as a good starting point for further discussion :)
Heh, well, wouldn't that be nice. I'd love to have some time to do someopen source coding. Instead I just make do with writing emails :-)Regards, Upayavira On 10/20/06, Upayavira
[EMAIL PROTECTED] wrote: Eelco Hillenius wrote: On 10/20/06, Johan Compagner [EMAIL PROTECTED] wrote: all bookmarkable pages can have forms..
that is already possible at the moment we had bookmarkable pages (like wicket 0.x) Again you mixup the notion of Bookmarkable and Stateless
Those are NOT the same, especially bookmarkable in regards to stateless. the other way around, Stateless pages are most likely bookmarkable. No, I don't think so. Are you telling me those forms are populated
automatically from a 'bookmarkable' url? I think not, and thus you have to interpret/ repopulate the form yourself. Now bookmarkable forms in the way they are in 2.0 now can be used just as normal form
with the only difference from an end-user's perspective that you can't depend on instance variables. Just a thought coming from Cocoon-land. Cocoon has the concept of continuations in server-side _javascript_, and
this can be used to maintain state. Although the programming model is different, the need is the same - when you connect to the backend server, to identify yourself in some way so
that you can be reconnected with your particular state. The session itself is too general - you need something particular to your form/etc. Cocoon handles this with a continuation ID. Using Cocoon's sitemap, you
can configure it to get that ID either from within the URL, or from a request parameter (or anywhere else you might care to think of). I always tended to put the continuation ID into a hidden field on the
page, as I wanted to maintain pretty URLs (even if those URLs weren't 'RESTful' - i.e if you bookmark it you won't go back to that particular state). Is it possible in Wicket to use a hidden field to pass that state
information rather than tacking it onto the URL? Regards, Upayavira - Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1
based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___ Wicket-user mailing list Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user-Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___Wicket-user mailing list
Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo

Re: [Wicket-user] Nice Url

2006-10-21 Thread Matej Knopp

I'm affraid that the hidden field would not be a very good alternative. 
Wicket does redirect after post, if you are using redirect to 
render/buffer, which IMHO 99,9% people do.

So if you send the page id in hidden field and then refresh the page, 
new page instance will be created.

-Matej

Eelco Hillenius wrote:
 That is sending state back to the client - I'm talking about passing a
 key back, just not in the URL.
 
 Yeah, I got that. What you mean is the part that now makes the path to
 the request target (like pagemap/ page(version)/ component combi).
 
 But yes, you are showing that hidden
 fields can be used.
 
 That was my point. The mechanism is the same except that in whereas
 client state saving would get the state back by deserializing, your
 proposal would get it by using that key etc. In fact, that part really
 isn't much more than configuring a custom target resolver.
 
 I'm sure ways could be worked around to get links to
 work (bit of javascript to do a post via a hidden form).
 
 Yeah. Probably best by using postprocessing like that client state
 saving experiment doesn. That's the least intrusive and most robust
 imo.
 
 Of course, any contributions in the form of patches are always welcome
 and might serve as a good starting point for further discussion :)
 Heh, well, wouldn't that be nice. I'd love to have some time to do some
 open source coding. Instead I just make do with writing emails :-)
 
 Damn users and incubation mentors ;)
 
 
 Eelco
 
 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Nice Url

even worse. If you refresh the page you will get the homepageBecause the only thing we put in the url is that key that then is in a hidden field...johanOn 10/21/06,
Matej Knopp [EMAIL PROTECTED] wrote:
I'm affraid that the hidden field would not be a very good alternative.Wicket does redirect after post, if you are using redirect torender/buffer, which IMHO 99,9% people do.So if you send the page id in hidden field and then refresh the page,
new page instance will be created.-MatejEelco Hillenius wrote: That is sending state back to the client - I'm talking about passing a key back, just not in the URL. Yeah, I got that. What you mean is the part that now makes the path to
the request target (like pagemap/ page(version)/ component combi). But yes, you are showing that hidden fields can be used. That was my point. The mechanism is the same except that in whereas
client state saving would get the state back by deserializing, your proposal would get it by using that key etc. In fact, that part really isn't much more than configuring a custom target resolver.
I'm sure ways could be worked around to get links to work (bit of _javascript_ to do a post via a hidden form). Yeah. Probably best by using postprocessing like that client state
saving experiment doesn. That's the least intrusive and most robust imo. Of course, any contributions in the form of patches are always welcome and might serve as a good starting point for further discussion :)
Heh, well, wouldn't that be nice. I'd love to have some time to do some open source coding. Instead I just make do with writing emails :-) Damn users and incubation mentors ;)
Eelco - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___ Wicket-user mailing list Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user-Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___Wicket-user mailing list
Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Nice Url

On 10/21/06, Matej Knopp [EMAIL PROTECTED] wrote:
 I'm affraid that the hidden field would not be a very good alternative.
 Wicket does redirect after post, if you are using redirect to
 render/buffer, which IMHO 99,9% people do.

I don't think it matters much actually. Whether you post that
information as part of the url, or as a hidden field, it all ends up
in the same pile. The rules for pagemap/ pageversion etc are the same,
and it is to be interpreted during target resolving. The redirect is
to a rendered page, which already has the hidden field in it, like it
otherwise would have the links with all the information in it.

For the record, I would certainly not prefer this to be the standard
mechanism for Wicket, even if it was implemented. But if people like
this alternative and someone coded it, that would be fine.

Eelco

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Nice Url

if the page was bookmarkable and if the user does specify a mount for every page...But the dangerous thing is that a page could also be none bookmarkable at all what then?So i think this kind of solution is not really possible.
johanOn 10/21/06, Matej Knopp [EMAIL PROTECTED] wrote:
Not really, we could use the mount point in url, if the page isbookmarkable.Johan Compagner wrote: even worse. If you refresh the page you will get the homepage Because the only thing we put in the url is that key that then is in a
hidden field... johan On 10/21/06, *Matej Knopp* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
I'm affraid that the hidden field would not be a very good alternative. Wicket does redirect after post, if you are using redirect to render/buffer, which IMHO 99,9% people do.
So if you send the page id in hidden field and then refresh the page, new page instance will be created. -Matej Eelco Hillenius wrote: That is sending state back to the client - I'm talking about
passing a key back, just not in the URL. Yeah, I got that. What you mean is the part that now makes the path to the request target (like pagemap/ page(version)/ component combi).
But yes, you are showing that hidden fields can be used. That was my point. The mechanism is the same except that in whereas
client state saving would get the state back by deserializing, your proposal would get it by using that key etc. In fact, that part really isn't much more than configuring a custom target resolver.
I'm sure ways could be worked around to get links to work (bit of _javascript_ to do a post via a hidden form). Yeah. Probably best by using postprocessing like that client state
saving experiment doesn. That's the least intrusive and most robust imo. Of course, any contributions in the form of patches are always welcome
and might serve as a good starting point for further discussion :) Heh, well, wouldn't that be nice. I'd love to have some time to do some open source coding. Instead I just make do with writing emails :-)
Damn users and incubation mentors ;) Eelco -
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server
v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___
Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your
job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___ Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
- Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___
Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
-Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimohttp://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo

Re: [Wicket-user] Nice Url

its the refresh button of the browser that is not supported then anymore (and also the back button will not work completely except jumping mount points..)johanOn 10/21/06, 
Eelco Hillenius [EMAIL PROTECTED] wrote:
On 10/21/06, Matej Knopp [EMAIL PROTECTED] wrote: I'm affraid that the hidden field would not be a very good alternative. Wicket does redirect after post, if you are using redirect to
 render/buffer, which IMHO 99,9% people do.I don't think it matters much actually. Whether you post thatinformation as part of the url, or as a hidden field, it all ends upin the same pile. The rules for pagemap/ pageversion etc are the same,
and it is to be interpreted during target resolving. The redirect isto a rendered page, which already has the hidden field in it, like itotherwise would have the links with all the information in it.For the record, I would certainly not prefer this to be the standard
mechanism for Wicket, even if it was implemented. But if people likethis alternative and someone coded it, that would be fine.Eelco-
Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Nice Url

No, what you guys are forgetting is that it has to work with a custom
resolving process. So the hidden field would be read before. It would
be part of wicket.request.IRequestCodingStrategy#decode(wicket.Request),
where the hidden field would be read and put in the RequestParameters
object. Something like that. If we want it, we could do it, that's the
morale.

Eelco


On 10/21/06, Johan Compagner [EMAIL PROTECTED] wrote:
 even worse. If you refresh the page you will get the homepage
 Because the only thing we put in the url is that key that then is in a
 hidden field...

 johan



 On 10/21/06, Matej Knopp [EMAIL PROTECTED] wrote:
  I'm affraid that the hidden field would not be a very good alternative.
  Wicket does redirect after post, if you are using redirect to
  render/buffer, which IMHO 99,9% people do.
 
  So if you send the page id in hidden field and then refresh the page,
  new page instance will be created.
 
  -Matej
 
  Eelco Hillenius wrote:
   That is sending state back to the client - I'm talking about passing a
   key back, just not in the URL.
  
   Yeah, I got that. What you mean is the part that now makes the path to
   the request target (like pagemap/ page(version)/ component combi).
  
   But yes, you are showing that hidden
   fields can be used.
  
   That was my point. The mechanism is the same except that in whereas
   client state saving would get the state back by deserializing, your
   proposal would get it by using that key etc. In fact, that part really
   isn't much more than configuring a custom target resolver.
  
   I'm sure ways could be worked around to get links to
   work (bit of javascript to do a post via a hidden form).
  
   Yeah. Probably best by using postprocessing like that client state
   saving experiment doesn. That's the least intrusive and most robust
   imo.
  
   Of course, any contributions in the form of patches are always welcome
   and might serve as a good starting point for further discussion :)
   Heh, well, wouldn't that be nice. I'd love to have some time to do some
   open source coding. Instead I just make do with writing emails :-)
  
   Damn users and incubation mentors ;)
  
  
   Eelco
  
  
 -
   Using Tomcat but need to do more? Need to support web services,
 security?
   Get stuff done quickly with pre-integrated technology to make your job
 easier
   Download IBM WebSphere Application Server v.1.0.1 based on Apache
 Geronimo
  
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
  
 https://lists.sourceforge.net/lists/listinfo/wicket-user
  
 
 
 
 -
  Using Tomcat but need to do more? Need to support web services, security?
  Get stuff done quickly with pre-integrated technology to make your job
 easier
  Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 


 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job
 easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642

 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user




-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Nice Url

First of all a hidden field can't be read when you do a fresh of an url that is redirected after postBut now i think about it. That isn't possibleThe render to buffer and then redirect to that buffer is impossible. That can't be done then anymore because
you can't sent an url to the browser that is just the homepage root or a mount point and then resolve it to the buffer that is still waiting for it to render. We need some state in the url then. So yes it could work also with refresh
But the big warning dialog of the browser will then popup Resent post data (or something like that).Because we never can do a redirect after post anymore.And all the links must do then also a post ofcourse. And refreshing the page will result in that action posted again. (a delete or save action)
But then the url will always be the homepage or the mount point that is shown in the browser.johanOn 10/21/06, Eelco Hillenius
[EMAIL PROTECTED] wrote:No, what you guys are forgetting is that it has to work with a custom
resolving process. So the hidden field would be read before. It wouldbe part of wicket.request.IRequestCodingStrategy#decode(wicket.Request),where the hidden field would be read and put in the RequestParameters
object. Something like that. If we want it, we could do it, that's themorale.EelcoOn 10/21/06, Johan Compagner [EMAIL PROTECTED] wrote: even worse. If you refresh the page you will get the homepage
Because the only thing we put in the url is that key that then is in a hidden field... johan On 10/21/06, Matej Knopp [EMAIL PROTECTED]
wrote: I'm affraid that the hidden field would not be a very good alternative. Wicket does redirect after post, if you are using redirect to render/buffer, which IMHO 99,9% people do.
So if you send the page id in hidden field and then refresh the page, new page instance will be created. -Matej Eelco Hillenius wrote:
That is sending state back to the client - I'm talking about passing a key back, just not in the URL. Yeah, I got that. What you mean is the part that now makes the path to
the request target (like pagemap/ page(version)/ component combi). But yes, you are showing that hidden fields can be used.
That was my point. The mechanism is the same except that in whereas client state saving would get the state back by deserializing, your proposal would get it by using that key etc. In fact, that part really
isn't much more than configuring a custom target resolver. I'm sure ways could be worked around to get links to work (bit of _javascript_ to do a post via a hidden form).
Yeah. Probably best by using postprocessing like that client state saving experiment doesn. That's the least intrusive and most robust imo.
Of course, any contributions in the form of patches are always welcome and might serve as a good starting point for further discussion :) Heh, well, wouldn't that be nice. I'd love to have some time to do some
open source coding. Instead I just make do with writing emails :-) Damn users and incubation mentors ;) Eelco
- Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___
Wicket-user mailing list Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user - Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server
v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___ Wicket-user mailing list Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user-Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere

Re: [Wicket-user] Nice Url

On 10/21/06, Johan Compagner [EMAIL PROTECTED] wrote:
 First of all a hidden field can't be read when you do a fresh of an url that
 is redirected after post
 But now i think about it. That isn't possible
 The render to buffer and then redirect to that buffer is impossible. That
 can't be done then anymore because
 you can't sent an url to the browser that is just the homepage root or a
 mount point and then resolve it to the buffer that is
 still waiting for it to render. We need some state in the url then. So  yes
 it could work also with refresh
 But the big warning dialog of the browser will then popup Resent post data
 (or something like that).
 Because we never can do a redirect after post anymore.
 And all the links must do then also a post ofcourse. And refreshing the page
 will result in that action posted again. (a delete or save action)
 But then the url will always be the homepage or the mount point that is
 shown in the browser.

Yeah. That wouldn't be pretty. But that's something else than impossible.

Look, I'm not even arguing I want this method. I just wonder how we
got from the can-do to the can't-do mentality. Sometimes things are
awkward to achieve, and some may actually really be impossible. But
we've had a dozen of instances where we thought something would be
very difficult which turned out pretty doable after all. So rather
than saying we can't do this, we should keep thinking about ways how
we could (which does not mean we actually implement it) and list the
advantages and disadvantages that what have.

Just my 2c,

Eelco

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Nice Url

Btw, just checking out ClientPageSavingSessionStore, but that doesn't
really work currently :)

Eelco

On 10/21/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
 On 10/21/06, Johan Compagner [EMAIL PROTECTED] wrote:
  First of all a hidden field can't be read when you do a fresh of an url that
  is redirected after post
  But now i think about it. That isn't possible
  The render to buffer and then redirect to that buffer is impossible. That
  can't be done then anymore because
  you can't sent an url to the browser that is just the homepage root or a
  mount point and then resolve it to the buffer that is
  still waiting for it to render. We need some state in the url then. So  yes
  it could work also with refresh
  But the big warning dialog of the browser will then popup Resent post data
  (or something like that).
  Because we never can do a redirect after post anymore.
  And all the links must do then also a post ofcourse. And refreshing the page
  will result in that action posted again. (a delete or save action)
  But then the url will always be the homepage or the mount point that is
  shown in the browser.

 Yeah. That wouldn't be pretty. But that's something else than impossible.

 Look, I'm not even arguing I want this method. I just wonder how we
 got from the can-do to the can't-do mentality. Sometimes things are
 awkward to achieve, and some may actually really be impossible. But
 we've had a dozen of instances where we thought something would be
 very difficult which turned out pretty doable after all. So rather
 than saying we can't do this, we should keep thinking about ways how
 we could (which does not mean we actually implement it) and list the
 advantages and disadvantages that what have.

 Just my 2c,

 Eelco


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Nice Url

no that is only done half way it is not really usable, just a test case how it could be done..When we don't finish it (i don't think i will do that) then it should be removed before the final of 2.0johan
On 10/21/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Btw, just checking out ClientPageSavingSessionStore, but that doesn'treally work currently :)EelcoOn 10/21/06, Eelco Hillenius [EMAIL PROTECTED]
wrote: On 10/21/06, Johan Compagner [EMAIL PROTECTED] wrote: First of all a hidden field can't be read when you do a fresh of an url that is redirected after post
But now i think about it. That isn't possible The render to buffer and then redirect to that buffer is impossible. That can't be done then anymore because you can't sent an url to the browser that is just the homepage root or a
mount point and then resolve it to the buffer that is still waiting for it to render. We need some state in the url then. Soyes it could work also with refresh But the big warning dialog of the browser will then popup Resent post data
(or something like that). Because we never can do a redirect after post anymore. And all the links must do then also a post ofcourse. And refreshing the page will result in that action posted again. (a delete or save action)
But then the url will always be the homepage or the mount point that is shown in the browser. Yeah. That wouldn't be pretty. But that's something else than impossible.
Look, I'm not even arguing I want this method. I just wonder how we got from the can-do to the can't-do mentality. Sometimes things are awkward to achieve, and some may actually really be impossible. But
we've had a dozen of instances where we thought something would be very difficult which turned out pretty doable after all. So rather than saying we can't do this, we should keep thinking about ways how
we could (which does not mean we actually implement it) and list the advantages and disadvantages that what have. Just my 2c, Eelco-
Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Nice Url

On 10/21/06, Johan Compagner [EMAIL PROTECTED] wrote:
 no that is only done half way it is not really usable, just a test case how
 it could be done..
 When we don't finish it (i don't think i will do that) then it should be
 removed before the final of 2.0

Yeah, we should remove it then. Looking at it, we would need a
different strategy for that anyway. It would be more like:

1) This session store should get the session like eg.
HttpSessionStore. I think trying to encode the whole session would be
just too much (and we're not actually even doing that here).
ClientPageSavingSessionStore now presumes that the last request was
encoded by Wicket, but that is a problem for things like shared
resources and bookmarkable pages. The thing we want encoded is the
state of the last request if that is relevant for call backs (in
effect the rendered page).
2) StateWriter is something we would need, but it would need to be
extended to converting all links to use a submit too. For this we
would probably need to have a javascript function that dynamically
builds a form or post. Links etc would be converted to use this.
2a) I learned recently that 255 is not an actual limit for gets, but
merely a very outdated 'recommeded' length. For internet explorer this
maximum is 2,048 (http://support.microsoft.com/kb/208427) and I read
other browsers even exceed that. I haven't measured it, but wouldn't
that be enough for one serialized page to hold? A thing to consider is
not to worry about posts in the first place (you could argue this is a
trade off users have to consider themselves), but put this encoded
state in the links we return in urlFor. We could do that, as the
complete hierarchy is known in 2.0. Additionally, with that method,
there could be a nice optimization, where we ask the component itself
for it's 'contribution' to the encoded state (don't aks me how that
would work right now, it's just a wild thought). Of course, there
would be the overhead that every link on the page would have that full
state initially, but that would be something we could optimize later
as well.
3) The session store  should only intercept the getAttribute requests
for the page map. On that request, it should return an on-the-fly
pagemap, with the one page reconstructed from the session state that
was sent with the request. That pagemap could be lazily constructed
and reused throughout the request, and onEndRequest it would be
cleared again.

These are just a bunch of wild thoughts. I'm convinced that if we
wanted and 2a would be viable, we wouldn't be that far off to working
client side state saving. The nice urls 'problem' that this thread
started with is still something else, and I agree with Johan and Matej
that there are a number of problems with it (most notably mounting and
redirect to buffer not working), and thinking about it a bit more,
even though we probably could achieve something like this if we really
tried hard, it wouldn't be for any advantage other then that the urls
would like 'nicer'. The thing that I proposed in a thread two weeks
ago: components contributing 'state' to urls would at least have the
advantage of bringing totally tweakable stateless pages a step closer.
This case doesn't have that advantage. And concerning client side
state saving, I'm still unconvinced that this is better to have than
just server state saving. On the contrary. The only thing interesting
about it is the technical challenge and the additional choice it would
provide our users.


Eelco

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Nice Url

2a: encoding the page in a links is not possible we will not be able to hold all the pages in just 2k!And as you said the pages whould be HUGE because every link then have that page state encoded in the link over and over again
so 20 links on one page would be 20 times 2K just for all the links.So that is really not an option. You don't have to serialize the whole http sessiononly 2 objects: the wicket session and the current page (and the pagemap but the pagemap isn't usefull at all in this situation, it doesn't do anything)
this i don't get:ClientPageSavingSessionStore now presumes that the last request wasencoded by Wicket, but that is a problem for things like sharedresources and bookmarkable pages.
that doesn't matter. a shared resource or bookmarkable url call just don't have the wicketstate hidden field in the requestso the page is not deserialized and put in the map. But that map doesn't have to be filled because the request isn't comming in for an existing page.
johanOn 10/21/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 10/21/06, Johan Compagner [EMAIL PROTECTED] wrote: no that is only done half way it is not really usable, just a test case how it could be done..
When we don't finish it (i don't think i will do that) then it should be removed before the final of 2.0Yeah, we should remove it then. Looking at it, we would need adifferent strategy for that anyway. It would be more like:
1) This session store should get the session like eg.HttpSessionStore. I think trying to encode the whole session would bejust too much (and we're not actually even doing that here).ClientPageSavingSessionStore now presumes that the last request was
encoded by Wicket, but that is a problem for things like sharedresources and bookmarkable pages. The thing we want encoded is thestate of the last request if that is relevant for call backs (ineffect the rendered page).
2) StateWriter is something we would need, but it would need to beextended to converting all links to use a submit too. For this wewould probably need to have a _javascript_ function that dynamicallybuilds a form or post. Links etc would be converted to use this.
2a) I learned recently that 255 is not an actual limit for gets, butmerely a very outdated 'recommeded' length. For internet explorer thismaximum is 2,048 (http://support.microsoft.com/kb/208427
) and I readother browsers even exceed that. I haven't measured it, but wouldn'tthat be enough for one serialized page to hold? A thing to consider isnot to worry about posts in the first place (you could argue this is a
trade off users have to consider themselves), but put this encodedstate in the links we return in urlFor. We could do that, as thecomplete hierarchy is known in 2.0. Additionally, with that method,there could be a nice optimization, where we ask the component itself
for it's 'contribution' to the encoded state (don't aks me how thatwould work right now, it's just a wild thought). Of course, therewould be the overhead that every link on the page would have that fullstate initially, but that would be something we could optimize later
as well.3) The session storeshould only intercept the getAttribute requestsfor the page map. On that request, it should return an on-the-flypagemap, with the one page reconstructed from the session state that
was sent with the request. That pagemap could be lazily constructedand reused throughout the request, and onEndRequest it would becleared again.These are just a bunch of wild thoughts. I'm convinced that if we
wanted and 2a would be viable, we wouldn't be that far off to workingclient side state saving. The nice urls 'problem' that this threadstarted with is still something else, and I agree with Johan and Matej
that there are a number of problems with it (most notably mounting andredirect to buffer not working), and thinking about it a bit more,even though we probably could achieve something like this if we reallytried hard, it wouldn't be for any advantage other then that the urls
would like 'nicer'. The thing that I proposed in a thread two weeksago: components contributing 'state' to urls would at least have theadvantage of bringing totally tweakable stateless pages a step closer.
This case doesn't have that advantage. And concerning client sidestate saving, I'm still unconvinced that this is better to have thanjust server state saving. On the contrary. The only thing interestingabout it is the technical challenge and the additional choice it would
provide our users.Eelco-Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimohttp://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___Wicket-user mailing listWicket-user@lists.sourceforge.net

Re: [Wicket-user] Nice Url