Re: AjaxButton doesn't work in WebMarkupContainer

[Pointbreak]

Well the error messages kind of gives it away, doesn't it?

But to explain further: setDefaultFormProcessing(false) doesn't mean the
button can be placed outside a a form. It means that the default
validation and submit behavior of the form is not executed when pressing
the button. Why do you want to use AjaxButton? Outside a form AjaxLink
does the job as you already discovered... 

On Thu, Mar 28, 2013, at 18:45, eugenebalt wrote:
> I have the below block of code. A Link or an AjaxLink works perfectly
> here
> inside a WebMarkupContainer. But when I use an AjaxButton (with a
> setDefaultFormProcessing=False), I get an error. Thanks
> 
>   AjaxButton linkCopy = new AjaxButton("linkCopy") {
> 
>   @Override
>   protected void onSubmit(AjaxRequestTarget arg0, Form 
> arg1) {
>   // TODO Auto-generated method stub
>   
>   }   
>   };
>   linkCopy.setDefaultFormProcessing(false);
>   wmcMarkup.add(linkCopy);
> 
> Error:
> java.lang.IllegalStateException: form was not specified in the
> constructor
> and cannot be found in the hierarchy of the component this behavior is
> attached to
>   at
> org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.getForm(AjaxFormSubmitBehavior.java:92)
>   at
> org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.getEventHandler(AjaxFormSubmitBehavior.java:108)
>   at
> org.apache.wicket.ajax.markup.html.form.AjaxButton$1.getEventHandler(AjaxButton.java:131)
>   at
> org.apache.wicket.ajax.AjaxEventBehavior.onComponentTag(AjaxEventBehavior.java:111)
>   at
> org.apache.wicket.behavior.AbstractAjaxBehavior.onComponentTag(AbstractAjaxBehavior.java:134)
>   at org.apache.wicket.Component.renderComponentTag(Component.java:4009)
>   at org.apache.wicket.Component.renderComponent(Component.java:2610)
> 
> 
> 
> 
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/AjaxButton-doesn-t-work-in-WebMarkupContainer-tp4657633.html
> Sent from the Users forum mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Proper resource versioning

[Pointbreak]

I don't think there's anything wrong with serving resources from the
webapp-folder, and making the webapp container (e.g. jetty) responsible
for serving them instead of Wicket. Most webapp containers will serve
static resources much more efficiently than any servlet-based (including
Wicket's) approach will do. It's also easier to switch to CDN, because
your resources are already served as static resources. Just change to
the new URL's. The container should be able to serve your static
resources with proper long-time caching headers. You should make sure
that the paths of these resources contain a version, so that when you
update a resource to a new version, clients will see it as a new
(uncached) resource. You can add the links directly in your markup, or
use UrlResourceReference in your java for this approach. The result is
the same.

Serving with Wicket (e.g. PackagedResourceReference) makes sense if:
- You need the locale/style/variation resource lookups of
PackagedResourceReference
- You want Wicket to automatically detect new versions of resources
(wicket changes the url to include a version number)
- You want to serve resources from the classpath, instead of the webapp
folder

Cheers

On Wed, Mar 27, 2013, at 23:24, Dan Retzlaff wrote:
> Hi, Bertrand. I don't have all your answers, but I can share my
> experience.
> 
> First, when you say you serve files out of webapp folder, do you mean
> you're not using any ResourceReference? Just absolute paths from markup?
> I
> think improving that is the first thing to do. You need to process
> resource
> references in Java so you can introduce versions, CDN base URLs, etc.
> 
> The main caching problem we had was that after upgrades, some clients had
> the old CSS cached and the site looked funky for them. So we went through
> and made sure all CSS is served through PackageResourceReferences.
> Wicket's
> default versioning strategy then did its magic and that complaint
> stopped.
> 
> With respect to @import, we have many @imports in our source LESS, but by
> the time it's being served, the CSS is flat. So versioning that is
> enough.
> It's possible but I think far less likely that this kind of caching
> problem
> will happen for images and fonts. Direct references to these from our
> application still go through ResourceReferences just so they can be
> served
> from CDN, but we don't worry about relative-path includes from CSS.
> 
> Hope that helps.
> 
> Dan
> 
> On Wed, Mar 27, 2013 at 2:15 PM, Bertrand Guay-Paquet <
> ber...@step.polymtl.ca> wrote:
> 
> > Hello,
> >
> > I'm trying to figure out the optimal way to deal with caching and out of
> > date resources and can't really find which methodology to adopt.
> >
> > Considering that:
> > a) css and js files are only accessed from web pages
> > b) image files are accessed from web pages and from email clients (links
> > stored for a long time)
> > c) image files are referenced from css (e.g. background-image url)
> > d) font files are accessed from web pages and maybe eventually from email
> > clients
> > e) some css files currently use "@import" statements to include other css
> > files (this could be removed if needed)
> > f) css, js, fonts and images currently are all located in the webapp
> > folder (i.e. I wasn't able to access them with PackageResourceReference)
> > g) whatever the approach, it needs to be compatible with eventual usage of
> > CDN services
> >
> > Questions:
> > 1- Which files should be versioned?
> > 2- Should they be versioned using Wicket's ResourceReferences?
> > 3- Are there other considerations I haven't thought about?
> > 4- Which successful approaches are in use now by other Wicker users?
> >
> > Thanks for your insight!
> >
> > Regards,
> > Bertrand
> >
> > --**--**-
> > To unsubscribe, e-mail: 
> > users-unsubscribe@wicket.**apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Serverside caching of IResource's that are expensive to generate

[Pointbreak]

Cool! I took a slightly different route, as explained in a previous
mail. I may try to find some time to see if both implementations could
be merged, but I'll have to check license issues first. What I built is
tightly integrated with Less4J so I'm not so sure merging the two would
make sense for wicket-bootstrap anyway.

I put a few comments inline below. Will try to make some time free later
to have a look at the pull request.

Cheers

On Wed, Mar 27, 2013, at 15:50, Martin Grigorov wrote:
> Hi,
> 
> At https://github.com/l0rdn1kk0n/wicket-bootstrap/compare/cached-less you
> may see the diff between master and cached-less branches.
> I still have to discuss the changes with Michael Haitz but your feedback
> is
> welcome too!
> 
> LessResourceReference is a specialization of CssResourceReference so it
> can
> be used like:
> 
> 
>  @Override
> public void renderHead(IHeaderResponse response) {
> super.renderHead(response);
> 
> response.render(CssHeaderItem.forReference(new
> LessResourceReference(HomePage.class, "demo.less")));
> }

You don't need a CssResourceReference for that, any ResourceReference
can be used like that.

> LessPackageResource is a specialization of CssPackageResource so all that
> is valid for CPR is valid for LPR too - compression, minified name, etc.

Why would you want to have a minified name for your less source file?
Only the output after compilation goes to the client. The compression (I
guess you mean minification) can be handled by Less as well.

> The real logic is in LessCacheManager that handles the server side
> caching
> for the generated CSS content per Less resource.
> As I explained earlier:
> - if a request without 'If-Modified-Since' request header is being
> processed then the cache manager is being advised
> - if there is no CSS content entry in the cache then the Less resource is
> compiled on the fly
> - if there is CSS entry then it is returned
> - if there is 'If-Modified-Since' then it is used by the cache manager to
> compare it against the last modification time of the root Less resource
> and
> all imports in it
> - if the Less resource is newer then the cache manager returns either the
> generated CSS or re-generates a new one if the CSS has been generated is
> before the last modification of the Less file(s)

Please note that LessSource.URLSource is not threadsafe, your
CacheManager seems to assume that. I went the same route as you, caching
LessSource, but made my own threadsafe LessSource implementation for
that (and also to @imports much much more flexible).

> 
> On Tue, Mar 26, 2013 at 11:29 AM, Pointbreak
>  > wrote:
> 
> > Thanks!
> >
> > Just FYI: with Less4j it's actually quite easy to get the modification
> > time of the most recently updated import, since it creates a list of all
> > used imports on the top level LessSource
> >
> > On Tue, Mar 26, 2013, at 10:13, Martin Grigorov wrote:
> > > Hi,
> > >
> > > As Dan explained at the moment Wicket provides just the logic for client
> > > side caching. And this is enough for _static_ resources.
> > > The case with Less/SASS/Stylus and similar resources is a bit more
> > > complicated because they are not static, unless you compile them at the
> > > client side.
> > > Wicket uses the last modification time of the resource to decide whether
> > > to
> > > stream it back to the client. If the resource is not modified then
> > > response
> > > with code 304 (Not Modified) is returned, _without_ body.
> > >
> > > For dynamically created resources this is not enough. The CSS content
> > > should be generated once, for the first client, and then cached for all
> > > following clients. Response with code 304 should be returned for clients
> > > which have already received the compiled CSS content and the modification
> > > time of the .less file is still the same.
> > >
> > > The more complex logic should be in
> > > LessResourceStream#getModificationTime() - it may contain @import's and
> > > it
> > > should return the modification time of the import with the most recent
> > > update.
> > >
> > > CachingResourceStreamLocator is about caching the location of the
> > > resource,
> > > i.e. the location of the resource with the most specific attributes -
> > > locale, variation and style.  Wicket will still read the input stream of
> > > the resource if the response is with code 200.
> > > CachingResourceStreamLocator
> > > just saves the time of checking all combinations of
>

Re: Serverside caching of IResource's that are expensive to generate

[Pointbreak]

Thanks!

Just FYI: with Less4j it's actually quite easy to get the modification
time of the most recently updated import, since it creates a list of all
used imports on the top level LessSource

On Tue, Mar 26, 2013, at 10:13, Martin Grigorov wrote:
> Hi,
> 
> As Dan explained at the moment Wicket provides just the logic for client
> side caching. And this is enough for _static_ resources.
> The case with Less/SASS/Stylus and similar resources is a bit more
> complicated because they are not static, unless you compile them at the
> client side.
> Wicket uses the last modification time of the resource to decide whether
> to
> stream it back to the client. If the resource is not modified then
> response
> with code 304 (Not Modified) is returned, _without_ body.
> 
> For dynamically created resources this is not enough. The CSS content
> should be generated once, for the first client, and then cached for all
> following clients. Response with code 304 should be returned for clients
> which have already received the compiled CSS content and the modification
> time of the .less file is still the same.
> 
> The more complex logic should be in
> LessResourceStream#getModificationTime() - it may contain @import's and
> it
> should return the modification time of the import with the most recent
> update.
> 
> CachingResourceStreamLocator is about caching the location of the
> resource,
> i.e. the location of the resource with the most specific attributes -
> locale, variation and style.  Wicket will still read the input stream of
> the resource if the response is with code 200. 
> CachingResourceStreamLocator
> just saves the time of checking all combinations of
> scope/name/locale/variation/style every time.
> 
> I'll work to improve Wicket Bootstrap Less module with this.
> And probably ConcatBundleResource will need similar optimizations.
> 
> 
> 
> 
> On Tue, Mar 26, 2013 at 10:36 AM, Michael Haitz
> wrote:
> 
> > Wicket has a CachingResourceStreamLocator that caches the resource streams.
> >
> > here's my wicket less implementation, could be helpful too:
> > https://github.com/l0rdn1kk0n/wicket-bootstrap/tree/master/bootstrap-less
> >
> >
> > Am 26.03.2013 um 01:01 schrieb Pointbreak  > >:
> >
> > > I have implemented a LessCssResource (it generates a CSS resource from
> > > Less source files) + LessCssResourceReference. Since computing the CSS
> > > is expensive, I would like to cache the generated CSS on the server,
> > > once generated. It is unclear to me whether Wicket has mechanisms to do
> > > this. I expected that IStaticCacheableResource would also provide the
> > > means to do server side caching (in addition to setting the correct
> > > headers and decorating the url for client-side caching). But this
> > > doesn't seem to be the case.
> > >
> > > When I look at what happens when doing a second page request/refresh
> > > after all browser caches are cleared, it seems that for IResource's that
> > > implement IStaticCacheableResource (including my LessCssResource, but
> > > also e.g. ConcatBundleResource from wicket core):
> > >
> > > * Resource.newResourceResponse is called (which obviously results in a
> > > recompute of the entire response)
> > > * Resource.getCacheableResourceStream is called (which also does a
> > > recompute of the entire response)
> > > * All implementations of these methods in wicket core resources are
> > > designed so that both calls do a full recompute of the actual response
> > > (which duplicates the effort for every page that uses a resource)
> > > * The Resource itself is recreated for every request (I could cache it
> > > in e.g. LessCssResourceReference, but nothing in wicket core abuses
> > > ResourceReferences for server side caching of Resources, so I'd like to
> > > know if there is a better approach).
> > >
> > > I have looked at Wickets own implementations of Resources that would
> > > benefit from server side caching and happen to implement
> > > IStaticCachableResource (e.g. ConcatBundleResource) and they seem to
> > > have the same behaviour: no server-side caching, and for each request
> > > the resource is actually computed multiple times: once for the actual
> > > response, once for computing the cache-key to decorate the url.
> > >
> > > Hence I would like to know:
> > >
> > > * Should the duplicate expensive compute of various Wicket core
> > > IStaticCacheableResource implementations not be fixed?
>

Re: Serverside caching of IResource's that are expensive to generate

[Pointbreak]

CachingResourceStreamLocator only caches the location of files so that
after the first lookup Wicket doesn't have to find out the correct
locale, style, and variant for each consecutive request. It doesn't help
with resources for which the content is expensive to generate. Like my
LessCssResource, but also e.g. wickets ConcatBundleResource, or e.g.
resources for server-side thumbnail creation.

I had a quick look at your wicket less implementation yesterday. Mine is
a bit different (as far as I can tell from a quick glance at the
source):

* I only support/use Less4J
* I use the @import features of Less4J, you seem to have added your own
way of bundling multiple less files into one
* I added my own implementation of LessSource that allows @import
lookups for classpath, and filesystem (also absolute paths), and use the
style/variant in @import lookups in the same way wicket does for
resource lookups.
* I don't extends CssResourceReference, which also mitigates (I think)
the need for a ResourceStreamLocator

I would probably have tried your implementation first if it did support
a flexible enough @import for my needs

Cheers, Gerrit

On Tue, Mar 26, 2013, at 9:36, Michael Haitz wrote:
> Wicket has a CachingResourceStreamLocator that caches the resource
> streams.
> 
> here's my wicket less implementation, could be helpful too:
> https://github.com/l0rdn1kk0n/wicket-bootstrap/tree/master/bootstrap-less
> 
> 
> Am 26.03.2013 um 01:01 schrieb Pointbreak
> :
> 
> > I have implemented a LessCssResource (it generates a CSS resource from
> > Less source files) + LessCssResourceReference. Since computing the CSS
> > is expensive, I would like to cache the generated CSS on the server,
> > once generated. It is unclear to me whether Wicket has mechanisms to do
> > this. I expected that IStaticCacheableResource would also provide the
> > means to do server side caching (in addition to setting the correct
> > headers and decorating the url for client-side caching). But this
> > doesn't seem to be the case.
> > 
> > When I look at what happens when doing a second page request/refresh
> > after all browser caches are cleared, it seems that for IResource's that
> > implement IStaticCacheableResource (including my LessCssResource, but
> > also e.g. ConcatBundleResource from wicket core):
> > 
> > * Resource.newResourceResponse is called (which obviously results in a
> > recompute of the entire response)
> > * Resource.getCacheableResourceStream is called (which also does a
> > recompute of the entire response)
> > * All implementations of these methods in wicket core resources are
> > designed so that both calls do a full recompute of the actual response
> > (which duplicates the effort for every page that uses a resource)
> > * The Resource itself is recreated for every request (I could cache it
> > in e.g. LessCssResourceReference, but nothing in wicket core abuses
> > ResourceReferences for server side caching of Resources, so I'd like to
> > know if there is a better approach). 
> > 
> > I have looked at Wickets own implementations of Resources that would
> > benefit from server side caching and happen to implement
> > IStaticCachableResource (e.g. ConcatBundleResource) and they seem to
> > have the same behaviour: no server-side caching, and for each request
> > the resource is actually computed multiple times: once for the actual
> > response, once for computing the cache-key to decorate the url.
> > 
> > Hence I would like to know:
> > 
> > * Should the duplicate expensive compute of various Wicket core
> > IStaticCacheableResource implementations not be fixed?
> > * Does Wicket provide any mechanism for server side caching of IResource
> > implementations?
> > 
> > Thanks
> > 
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> > 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Serverside caching of IResource's that are expensive to generate

[Pointbreak]

Fair enough. I also see that in deployment mode wicket actually caches
the decorated url of resources for the entire application lifetime, so
the Resource.getCacheableResourceStream isn't repeated each time a page
is rendered with a reference to a resource.

On Tue, Mar 26, 2013, at 2:09, Dan Retzlaff wrote:
> I believe Wicket's resource versioning and caching logic simply provides
> advice in HTTP response headers, and decorates filenames if so
> configured.
> Do your requests come directly to Wicket's container? We reverse proxy
> with
> HTTPD, which is probably better at caching than a Java solution could
> ever
> be.
> 
> On Mon, Mar 25, 2013 at 5:01 PM, Pointbreak
> wrote:
> 
> > I have implemented a LessCssResource (it generates a CSS resource from
> > Less source files) + LessCssResourceReference. Since computing the CSS
> > is expensive, I would like to cache the generated CSS on the server,
> > once generated. It is unclear to me whether Wicket has mechanisms to do
> > this. I expected that IStaticCacheableResource would also provide the
> > means to do server side caching (in addition to setting the correct
> > headers and decorating the url for client-side caching). But this
> > doesn't seem to be the case.
> >
> > When I look at what happens when doing a second page request/refresh
> > after all browser caches are cleared, it seems that for IResource's that
> > implement IStaticCacheableResource (including my LessCssResource, but
> > also e.g. ConcatBundleResource from wicket core):
> >
> > * Resource.newResourceResponse is called (which obviously results in a
> > recompute of the entire response)
> > * Resource.getCacheableResourceStream is called (which also does a
> > recompute of the entire response)
> > * All implementations of these methods in wicket core resources are
> > designed so that both calls do a full recompute of the actual response
> > (which duplicates the effort for every page that uses a resource)
> > * The Resource itself is recreated for every request (I could cache it
> > in e.g. LessCssResourceReference, but nothing in wicket core abuses
> > ResourceReferences for server side caching of Resources, so I'd like to
> > know if there is a better approach).
> >
> > I have looked at Wickets own implementations of Resources that would
> > benefit from server side caching and happen to implement
> > IStaticCachableResource (e.g. ConcatBundleResource) and they seem to
> > have the same behaviour: no server-side caching, and for each request
> > the resource is actually computed multiple times: once for the actual
> > response, once for computing the cache-key to decorate the url.
> >
> > Hence I would like to know:
> >
> > * Should the duplicate expensive compute of various Wicket core
> > IStaticCacheableResource implementations not be fixed?
> > * Does Wicket provide any mechanism for server side caching of IResource
> > implementations?
> >
> > Thanks
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Serverside caching of IResource's that are expensive to generate

[Pointbreak]

I have implemented a LessCssResource (it generates a CSS resource from
Less source files) + LessCssResourceReference. Since computing the CSS
is expensive, I would like to cache the generated CSS on the server,
once generated. It is unclear to me whether Wicket has mechanisms to do
this. I expected that IStaticCacheableResource would also provide the
means to do server side caching (in addition to setting the correct
headers and decorating the url for client-side caching). But this
doesn't seem to be the case.

When I look at what happens when doing a second page request/refresh
after all browser caches are cleared, it seems that for IResource's that
implement IStaticCacheableResource (including my LessCssResource, but
also e.g. ConcatBundleResource from wicket core):

* Resource.newResourceResponse is called (which obviously results in a
recompute of the entire response)
* Resource.getCacheableResourceStream is called (which also does a
recompute of the entire response)
* All implementations of these methods in wicket core resources are
designed so that both calls do a full recompute of the actual response
(which duplicates the effort for every page that uses a resource)
* The Resource itself is recreated for every request (I could cache it
in e.g. LessCssResourceReference, but nothing in wicket core abuses
ResourceReferences for server side caching of Resources, so I'd like to
know if there is a better approach). 

I have looked at Wickets own implementations of Resources that would
benefit from server side caching and happen to implement
IStaticCachableResource (e.g. ConcatBundleResource) and they seem to
have the same behaviour: no server-side caching, and for each request
the resource is actually computed multiple times: once for the actual
response, once for computing the cache-key to decorate the url.

Hence I would like to know:

* Should the duplicate expensive compute of various Wicket core
IStaticCacheableResource implementations not be fixed?
* Does Wicket provide any mechanism for server side caching of IResource
implementations?

Thanks

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Question about name suffix that wicket appends to ResourceReferences

[Pointbreak]

Thanks!

On Fri, Mar 22, 2013, at 14:07, Thomas Götz wrote:
> Please have a look at FilenameWithVersionResourceCachingStrategy.
> 
>-Tom
> 
> 
> On 22.03.2013, at 14:01, Pointbreak 
> wrote:
> 
> > When rendering the header items for packeded resource references, wicket
> > appends a suffix like "-ver-1363953702887" to the name of the resource.
> > Can somebody point me add the place in the code where this suffix is
> > generated and/or document if/how this could be disabled (preferably on a
> > case by case basis)?
> > 
> > Thanks!
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Question about name suffix that wicket appends to ResourceReferences

[Pointbreak]

When rendering the header items for packeded resource references, wicket
appends a suffix like "-ver-1363953702887" to the name of the resource.
Can somebody point me add the place in the code where this suffix is
generated and/or document if/how this could be disabled (preferably on a
case by case basis)?

Thanks!

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Prioritize header items in html templates

[Pointbreak]

The Java based header contributions are for css, and javascript mostly.
Is there a practical way to get title, meta, and other 'special' tags
appear before contributed headeritems in the head then?

On Tue, Mar 19, 2013, at 13:48, Martin Grigorov wrote:
> Hi,
> 
> I think this is not possible.
>  is just a convenience. The full power is in the Java based
> header contributors.
> 
> 
> On Tue, Mar 19, 2013 at 2:42 PM, Pointbreak
> wrote:
> 
> > Is there a way (in Wicket 6) to prioritize items in wicket:head/head
> > elements to get them inside the head of the final page before all code
> > contributed header items? I.e. something like PriorityHeaderItem, but
> > applied to the markup of an item in the wicket:head of a template?
> >
> > Thanks!
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
> 
> 
> -- 
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com <http://jweekend.com/>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Prioritize header items in html templates

[Pointbreak]

Is there a way (in Wicket 6) to prioritize items in wicket:head/head
elements to get them inside the head of the final page before all code
contributed header items? I.e. something like PriorityHeaderItem, but
applied to the markup of an item in the wicket:head of a template?

Thanks!

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket Session Expiration - Ajax interactions

[Pointbreak]

Why don't you just keep the session alive as long as the user has an
ajax page open? You can easily do this by letting the page do a timed
ajax call to the server every x minutes, where x is slightly less than
your session timeout.

On Mon, Jan 21, 2013, at 17:56, sthomps wrote:
> I'm currently in the process of evaluating frameworks.  We are currently
> using Wicket 1.4.
> 
> The ones I've looked at so far have been Vaadin, Tapestry 5.4, and Wicket
> 6.0.
> 
> Vaadin I ruled out for various reasons.
> 
> One of the problems that our users have complained quite a bit about is
> the
> dreaded PageExpiration problem.
> 
> In Wicket 6.0 the issue is resolved somewhat by the framework recreating
> the
> page and then issuing a redirect.
> 
> While understand why it does this
> 
> // If the page is stateful then we cannot assume that the listener
> interface
> is
> // invoked on its initial state (right after page initialization) and
> that
> its
> // component and/or behavior will be available. That's why the listener
> interface
> // should be ignored and the best we can do is to re-paint the newly
> constructed
> // page.
> 
> it's still not the solution we want.  The Ajax interaction should
> continue
> on as normal.
> 
> Due to how Tapestry is architected, this is not an isssue.
> 
> In Wicket 1.4, I got around this somewhat by extending the
> WebRequestCycleProcessor and recreating the request when a PageExpiration
> was encountered.
> 
> It doesn't appear that I can carry this forward in Wicket 6.0.
> 
> I just want to make sure that I'm not missing anything.
> 
> Thanks
> 
> 
> 
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Wicket-Session-Expiration-Ajax-interactions-tp4655591.html
> Sent from the Users forum mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Call Wicket repeatedly from JQplot (Jquery based) graphing framework

[Pointbreak]

With that code the javascript should be added to the markup (which is
easy to check if you view the source form your browser). Your problem is
that the generated javascript is incorrect: you have no closing [']
after the url. That would have shown up if you opened the page in
Firebug with Scripts enabled.

On Wed, Oct 31, 2012, at 0:08, baguahsingi wrote:
> Hi,
> 
> I would like to call Wicket repeatedly to obtain data from a service for
> a
> JQplot chart.  I need to do this as the data is obtained from a slow web
> service.  The user will then see a graph that will gradually build up
> after
> each new set of data from the server is added to it.  
> 
> I've had some success with this part. The user clicks a button to start
> building the graph, however, I cannot work out how to call for more data
> from javaScript to Wicket, then back again from Wicket to javaScript to
> add
> the new data to the JQplot graph.  
> 
> Code below (there will be a flag to signal to the javaScript that there's
> no
> more graph data, but it's not there yet):
> 
> public class GraphPanel extends ParentPanel   {
>   
>   @SpringBean
>   private GraphDataService graphDataService;
>   
>   private Integer dataId;
> 
>   public GraphPanel ( String id, Integer dataId) {
>   
>   super(id);
> this.dataId = dataId;
>   buildPage();
>   }
> 
>   
>   public void buildPage() {
>   
>   
> //Link used for button to start to obtain chart data
>   add( new AjaxLink( "getGraphData" ){ 
>   public void onClick( AjaxRequestTarget target ){ 
>   
>   getChartData(target);
>   
>   }
>   } ); 
>   
> //behaviour used to obtain url for call back from
> javaScript
>   final AbstractDefaultAjaxBehavior 
> jsCallbackBehaviourForMoreChartData =
> new AbstractDefaultAjaxBehavior() {
> 
>   @Override
>   protected void respond(AjaxRequestTarget target) {
>   
>   getChartData(target);
>   }
>   };
>   
>   getBasePage().add(jsCallbackBehaviourForMoreChartData);
>   
>   final CharSequence url =
> jsCallbackBehaviourForMoreChartData.getCallbackUrl();
>   
> //behaviour to provide javaScript function which I can
> call
> from my javaScript
> //function if it needs to get more data. This function is
> not added to mark up...
>   add(new Behavior() {
>  private static final long serialVersionUID = 1L;
>  
>  @Override
>   public void renderHead(Component component, 
> IHeaderResponse response) {
>   super.renderHead(component, response);
>   
>   String js = "function callWicket() { var wcall 
> = wicketAjaxGet ('"
>   + url + ", function() { }, 
> function() { } ) }";
>   response.renderJavaScript(js, "myScript");
>   
>   }
> });
>   }
> 
> private void getChartData(AjaxRequestTarget target) {
>   
>   
>   GraphData graphData = null;
>   try {
>   graphData = graphDataService.getChartData(dataId);
>   } catch (GraphDataFailureException e) {
>   // TODO Need to report error to user somehow
>   
>   }
> //This method just builds a String in the format required
> for JQplot 
>   String jsVar = buildChartDataAsJavaScriptVariable(graphData);
>   String chartTitle = graphData.getTitle();
>   List namesOfSeriesOnGraph = 
> graphData.getNamesOfGraphSeries();
> 
>   String legendNames = 
> Arrays.toString(namesOfSeriesOnGraph.toArray(new
> String[namesOfSeriesOnGraph.size()]));
> 
>   String javaScriptFunctionCall= 
> "buildChart('chartDivContainer',[" + jsVar
> + "],'" + chartTitle + ", " + legendNames + ")";
> 
>   target.appendJavaScript(javaScriptFunctionCall);
>   }
> }
> 
> I want the abstract Behaviour added to the panel above to provide me with
> some javaScript so that I can call back to Wicket.  This javaScript is
> not
> added to the mark up.  When I paste the url from the getCallbackUrl()
> into
> the browser but I get XML back:
> 
>  encoding="wicket1">buildChart('chartDivContainer',[[[135161736,
> 22.76].all my graph data.
> 
> Can anyone point me in the 

Re: Custom CSS for Feedback message is broken in 1.5

[Pointbreak]

[X] Other suggestion: don't have a class on the span, or even better,
don't have the span element at all inside the list-item

For any customisations beyound this, just create your own FeedbackPanel,
it's easy and gives complete control.

On Sun, Oct 28, 2012, at 17:03, Sebastien wrote:
> Hi,
> 
> To sum-up this thread: we have a (not huge, but still) design issue that
> annoys several users. A patch* has been provided but some questions
> remains...
> Given this, I would suggest a kind-of vote about the several points
> discussed earlier, in order to enlighten the dev-team about the preferred
> choice of their (beloved) users.**
> 
> Here are some possible options:
> [ ] Please apply the patch as-is. It currently provides 2 methods
> (#getListCSSClass and #getLabelCSSClass), #getCSSClass is marked a
> deprecated until marked as private (or removed)
> [ ] Do not apply the patch as-is, #getCSSClass should be kept (not marked
> as deprecated)
> [ ] Do not apply the patch as-is, I do not agree with the 2 method names.
> I
> would have preferred: (please specify)
> [ ] This is not an issue; this does not need to be "corrected"
> [ ] Other suggestion: (please specify)
> 
> Thanks in advance for your contribution,
> Sebastien
> 
> (*) https://issues.apache.org/jira/browse/WICKET-4831
> (**) Sure, dev-team opinion is also kindly asked! :)

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: [DISCUSS] Security Frameworks

[Pointbreak]

[X] I use Shiro

Because it's simple in use and simple to integrate with Wicket or other
frameworks, but still powerful enough for most security related tasks.
And because I liked it more than Spring Security three years or so ago.
I think Spring Security is more feature complete out of the box though.

On Thu, Oct 18, 2012, at 06:08, Jeremy Thomerson wrote:
> Our of curiosity: among the wider community: what security framework(s)
> do
> you use with with Wicket, and why?
> 
> [  ] I use my own custom framework
> [  ] I use Shiro
> [  ] I use Spring Security
> [  ] I use WASP/Swarm
> [  ] Other (please specify)
> 
> And don't forget the "why".
> 
> -- 
> Jeremy Thomerson
> http://wickettraining.com

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket and jQuery UI

[Pointbreak]

But why not for tabs, accordion, slider, and other jquery components?
That gives you much more flexibility in separating what a component
logically does (e.g. render various sections of data, widgets, etc.),
from how it is shown and interacted with in the browser (view as tabs,
steps in a widget, accordion, just plain sections, ...). In jquery-ui
itself you also add it as a behavior to a DOM element. So why not offer
that flexibility in the Wicket integration? Idem ditto for things like
draggable, droppable, etc. Why not offer the possibility to make any
existing wicket panel/component a draggable by having a
DraggableBehavior? In wicket-jquery-ui you need to subclass a Draggable
panel, which is obviously not possible with already existing
components/panels.

Just to clarify: this is my very personal opinion on how a jquery
integration should be designed (and actually how I've done it for many
projects so far). That's obviously very subjective. It looks like an
impressive library nonetheless!

On Tue, Oct 2, 2012, at 15:30, Sébastien Gautrin wrote:
> Hi Pointbreak,
> 
> At least for wicket-jquery-ui, it offers also pure behaviours 
> integration for jquery extensions that are pure behaviours (such as 
> Droppable). I think wiQuery does as well. For ease of defining such 
> things for you own component, it is the main goal of wicket-jquery-ui; 
> take a look at the three tutorials Sebastien made (sebfz1) for 
> wicket-jquery-ui: 
> http://code.google.com/p/wicket-jquery-ui/w/list?q=label:How-To (note: 
> Sebastien is the author of wicket-jquery-ui).
> 
> More on the topic, I as well would welcome experience returns from 
> people who used both (though personally I'm inclined to use 
> wicket-jquery-ui at the moment, but that's also because I'm biaised 
> after having been really impressed at how fast Sebastien integrated run 
> fox software Datepicker component to wicket-jquery-ui while doing his 
> tutorial#3).
> 
> Pointbreak wrote:
> > It's a very long time ago that I looked at the API's, so it's likely
> > things have changed since that time. But the problem I had with both
> > products is that they are mostly component based API's (meaning they
> > offer an Accordion component, Autocomplete component, etc.). Imho, a
> > much more flexible approach for JQuery integration is to offer all
> > jquery-ui functionality as behaviors. That way existing components (both
> > from core, other libraries, or your own code) can more easily be
> > augmented with jqeury-ui functionality. And since it's easy enough to do
> > it yourself with a few lines of code, I opted to don't use these
> > libraries at all.
> > There are a few things that require more thought (e.g. jQuery Tab-UI
> > combined integrated with Wicket-Ajax functionality, but at least back
> > then these frameworks didn't offer that in a flexible way either).
> >
> > So I would say, check the libraries for how you are supposed to add the
> > jquery functionality (behavior vs component hierarchy), and don't be
> > afraid to just roll your own if necessary. It's not that much extra
> > functionality that the library offers over just using raw Wicket and
> > jQuery.
> >
> > My 2cnts.
> >
> > On Tue, Oct 2, 2012, at 13:02, ronny.v...@consult.nordea.com wrote:
> >> Hi
> >>
> >> I was not thinking about  the base, ie AbstractDefaultAjaxBehavior.
> >>
> >> I was thinking about using one off the API - several components - could
> >> be accordion? could be some effects etc.
> >>
> >> So I was thinking about who has tried out both API's - has some
> >> experiences and suggest this API because bla bla.
> >>
> >> Hope I explain myself fully here.
> >>
> >> - Ronny
> >>
> >> -Original Message-
> >> From: Martin Grigorov [mailto:mgrigo...@apache.org]
> >> Sent: 02 October 2012 08:52
> >> To: users@wicket.apache.org
> >> Subject: Re: Wicket and jQuery UI
> >>
> >> Hi,
> >>
> >> On Tue, Oct 2, 2012 at 9:28 AM,   wrote:
> >>> Hi Wicket
> >>>
> >>> I have been looking at a) wiQuery and b) wicket-jquery-ui
> >>>
> >>> What API to use when doing a bridge between Wicket and jQuery UI?
> >> What exactly do you need ?
> >>
> >> The "bridge" is AbstractDefaultAjaxBehavior - the base Ajax behavior.
> >>
> >>> Recommendations and experience would be very much welcomed.
> >>>
> >>> Thanks in advance!
> >>>
> >>> Best regards/Med venlig

Re: Wicket and jQuery UI

[Pointbreak]

It's a very long time ago that I looked at the API's, so it's likely
things have changed since that time. But the problem I had with both
products is that they are mostly component based API's (meaning they
offer an Accordion component, Autocomplete component, etc.). Imho, a
much more flexible approach for JQuery integration is to offer all
jquery-ui functionality as behaviors. That way existing components (both
from core, other libraries, or your own code) can more easily be
augmented with jqeury-ui functionality. And since it's easy enough to do
it yourself with a few lines of code, I opted to don't use these
libraries at all.
There are a few things that require more thought (e.g. jQuery Tab-UI
combined integrated with Wicket-Ajax functionality, but at least back
then these frameworks didn't offer that in a flexible way either).

So I would say, check the libraries for how you are supposed to add the
jquery functionality (behavior vs component hierarchy), and don't be
afraid to just roll your own if necessary. It's not that much extra
functionality that the library offers over just using raw Wicket and
jQuery.

My 2cnts.

On Tue, Oct 2, 2012, at 13:02, ronny.v...@consult.nordea.com wrote:
> Hi
> 
> I was not thinking about  the base, ie AbstractDefaultAjaxBehavior.
> 
> I was thinking about using one off the API - several components - could
> be accordion? could be some effects etc.
> 
> So I was thinking about who has tried out both API's - has some
> experiences and suggest this API because bla bla.
> 
> Hope I explain myself fully here.
> 
> - Ronny
> 
> -Original Message-
> From: Martin Grigorov [mailto:mgrigo...@apache.org] 
> Sent: 02 October 2012 08:52
> To: users@wicket.apache.org
> Subject: Re: Wicket and jQuery UI
> 
> Hi,
> 
> On Tue, Oct 2, 2012 at 9:28 AM,   wrote:
> > Hi Wicket
> >
> > I have been looking at a) wiQuery and b) wicket-jquery-ui
> >
> > What API to use when doing a bridge between Wicket and jQuery UI?
> 
> What exactly do you need ?
> 
> The "bridge" is AbstractDefaultAjaxBehavior - the base Ajax behavior.
> 
> >
> > Recommendations and experience would be very much welcomed.
> >
> > Thanks in advance!
> >
> > Best regards/Med venlig hilsen
> > Ronny Voss
> >
> > Nordea Bank Danmark A/S
> > Online & Securities Processing Solutions Strandgade 3
> > DK-1401 København K
> > Mobile: +45 26711952
> > E-mail: 
> > ronny.v...@consult.nordea.com

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket rendering jquery late

[Pointbreak]

If your panel depends on jquery, you should render the reference to
jquery also in your panel.

On Wed, Sep 26, 2012, at 13:40, Oscar Besga Arcauz wrote:
>  Hi wickers !
> 
> I've a problem with wicket and jquery resource rendering.
> 
> My webpage has many panels wich uses jquery, and they have javascript
> attached to it. 
> This panel-dependant javascript uses jquery, so I render jquery with a
> resourcerefernce in the webpage. 
> (The page doesn't use ajax because I want to mantain page stateless and
> bookmarkable.)
> 
> The problem is that the javascript attached to panel is rendered first
> into the page, and the jquery reference is the last. 
> so, when the page fully renders, i've some 'ReferenceError: $ is not
> defined' errors in webrowser console.
> 
> ¿ Has anyone experienced similar problems ?
> 
> 
> Other little question: wicket6 uses jquery 1.7.2; has anyone tried with
> 1.8.x ?
> 
> Thanks in advance
> 
> 
> > > > Oscar Besga Arcauz  < < < 
> 
> 
> PS. 
> 
> Example code (little long) --->
> 
> public class MyPage extends WebPage {
> 
> 
> public MyPage (PageParameters parameters) {
> super(parameters);
> add(new MyPageJsBehaviour());
> add(new MyPanel("mypanel"));
> }
> 
> 
> private class MyPageJsBehaviour extends Behavior {
> 
> @Override
> public void renderHead(Component component, IHeaderResponse
> response) {
> 
> response.render(JavaScriptHeaderItem.forReference(JQueryResourceReference.get(),"jquery"));
> super.renderHead(component,response);
>}
> }
> 
> }
> 
> 
> public class MyPanel extends Panel {
> 
> 
> public MyPanel(String id,String lang) {
> super(id);
> add(new MyPanelJsBehaviour());
> }
> 
> private class MyPanelJsBehaviour extends Behavior {
> 
> @Override
> public void renderHead(Component component, IHeaderResponse
> response) {
> super.renderHead(component,response);
> response.render(JavaScriptHeaderItem.forReference(new
> JavaScriptResourceReference(MyPanel .class,
> "MyPanel.js"),"mypaneljs"));
> /**
> //MyPanel.js
> $(function () { // <-- here arises the error, as $ is not
> defined because MyPanel.js is loaded before jquery !!!
>$('mypanel').dosomething();
> });
> **/
> }
> }
> 
> }
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Best practices for passing configurations, such as Facebook app_id, to JavaScript

[Pointbreak]

I would use PackageTextTemplate to render the javascript, e.g. put your
javascript in MyPage.js along with the other templates, and use
${facebookId} for the id, then add this to your class:

@Override public void renderHead(IHeaderResponse response) {
super.renderHead(response);
PackageTextTemplate javascript = new
PackageTextTemplate(MyPage.class, MyPage.class.getSimpleName() +
".js");
Map vars = new HashMap();
vars.put("facebookId", facebookId);
response.renderOnDomReadyJavaScript(javascript.asString(vars));
}

On Wed, Aug 29, 2012, at 15:09, Fergal Keating wrote:
> *HTML*
> *
> *
> 
> /* script will be
> rendered here */
> 
> *JAVA*
> 
> String FacbookJS = " var facebookID = \"" +
> this.getfacebookID(CurrentDomain) + "\"); ";
> Label FacebookLabel = new Label("Facebookjs", FacbookJS );
> 
> addOrReplace( FacebookLabel.setEscapeModelStrings(false));
> 
> On 27 August 2012 15:33, Alec Swan  wrote:
> 
> > Hello,
> >
> > We deploy our web app on different domains which means that JavaScript
> > Facebook integration needs to use different app_id values. I am
> > planning to store these values in a configuration file and wonder how
> > to expose them to JavaScript. I would also like to write a unit test
> > that verifies that settings were passed correctly.
> >
> > I could use a HeaderContributor to inject raw JavaScript, but this
> > doesn't seem to be very unit-testable. I could create a  which
> > attributes/elements contain the settings, which seems to be more
> > unit-testable.
> >
> > Thoughts?
> >
> > Thanks,
> >
> > Alec
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
> 
> 
> -- 
> Fergal Keating
> IT Senior Engineer
> ---
> e. fergal.keat...@directski.com
> p. NA
> w. www.directski.com

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket tags in output markup may change styles

[Pointbreak]

You should at least escape your ':', i.e. something like: BODY
WICKET\:MESSAGE * {   }
But I doubt it will work on any browser. If you really want to keep the
wicket:message tags (imho you're better of without them), you could wrap
them in another container (div/span) and use that conatiner as a css
scope to style your messages.

On Tue, Aug 21, 2012, at 17:55, Adriano dos Santos Fernandes wrote:
> Hi!
> 
> I was creating a website with Wicket and the CSS styles were fine.
> 
> Then I decided to replace some texts with  and it
> changed the formatting.
> 
> I know setStripWicketTags(true), but I prefer to have it working with
> setStripWicketTags(false) in dev. mode.
> 
> The html is actually a XHTML transitional. The affected style is related
> to "body * { ... }".
> 
> I tried things like "body *:* { ... }" and it fixed the problem, but
> introduced another ones. I'm even not sure this is a valid CSS syntax.
> 
> Has anyone have a hint on a good way to solve this problem?
> 
> Sorry to not create a quickstart, maybe this is well know thing, but it
> never happened to me till now.
> 
> 
> Adriano
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: page version and forms

[Pointbreak]

The tree node selections are fully handled by ajax requests, so they
will (obviously) never change the url of the page. Change the selection
of e.g. the dropdown for "Content", and you will see that the url
changes.

There are ways to have forms without version/id information in the URL.
Search this list for e.g. NoVersionMount. Such solutions do change how
Wicket behaves with the back-button/page-refresh, since a new version of
the page will always be returned in that case.

On Tue, Aug 21, 2012, at 13:16, Alex Shubert wrote:
> [...]
> Anyway: what does your answer has to do with my question? One more
> time: how that example manage not to increase page version shown in
> url on every tree node selection?
> thanks
> [...]
> 
> 
> On 21 August 2012 14:39, Martin Grigorov  wrote:
> > The deployed examples use Wicket 1.4.
> >
> > http://wicket-tree.appspot.com/?wicket:interface=:0:1:::
> >
> > On Tue, Aug 21, 2012 at 1:35 PM, Alex Shubert  
> > wrote:
> >> They are using
> >> Form form = new Form("form");
> >>
> >> and still no version in url on round-trips. Also, FilterForm from
> >> Wicket API doesn't extends StatelessForm while your answer states that
> >> must be the case.
> >>
> >>
> >> On 21 August 2012 14:20, Martin Grigorov  wrote:
> >>> Use StatelessForm instead.
> >>>
> >>> On Tue, Aug 21, 2012 at 1:06 PM, Alex Shubert  
> >>> wrote:
>  Hello
> 
>  Recently I found wicket tree control
> 
>  http://wicket-tree.appspot.com/nested
> 
>   and one there is a thing I can't understand: while the page contains
>  Form it looks like not versioned. I mean there are no version number
>  in a url.
>  How does it work then? Is there any clear way to build pages
>  containing Form without explicit version number in url except some
>  black magic involved ( modified MountedMapper )
> 
> 
> 
> 
>  --
>  Best regards
>  Alexandr
> 
>  -
>  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>  For additional commands, e-mail: users-h...@wicket.apache.org
> 
> >>>
> >>>
> >>>
> >>> --
> >>> Martin Grigorov
> >>> jWeekend
> >>> Training, Consulting, Development
> >>> http://jWeekend.com
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> Best regards
> >> Alexandr
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >
> >
> >
> > --
> > Martin Grigorov
> > jWeekend
> > Training, Consulting, Development
> > http://jWeekend.com
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> 
> 
> 
> -- 
> Best regards
> Alexandr
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket Application on GoDaddy

[Pointbreak]

You probably have another webapp already mounted as root context (in
your webapps/ROOT). You obviously can't have two webapps under the
root... 

On Tue, Apr 3, 2012, at 09:31, Satrix wrote:
> I changed the name of WAR file to ROOT.war but no luck now it's
> www.domain.com/ROOT/home :/
> From what I know there is tomcat 5 running
> 
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Wicket-Application-on-GoDaddy-tp4529071p4529402.html
> Sent from the Users forum mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: What real life scenario calls for page ID?

[Pointbreak]

On Thu, Mar 22, 2012, at 15:46, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 3:39 PM, heikki  wrote:
> > What's the point in refreshing if it returns exactly the same page as
> > before ?
> 
> it allows components such as datatables and others that pull data from
> the database to refresh, while preserving other things.
> 
> think of it this way:
> 
> i have a page with two tabs. the first tab shows a table of data, and
> the second tab shows the graph of data.
> i load the page through a bookmarkable page and switch to the second
> tab to look at the graph.
> 
> ten minutes later i want to refresh the graph, so i refresh the page.
> but now, instead of looking at the graph i am looking at the table
> again because in the new instance of the page the first tab is
> selected.
> 
> what if it takes me three or four clicks to get to the graph? it is
> very frustrating to lose your navigation just because you refreshed
> 
> another example is a log viewer. suppose i have a form on the top that
> lets me select a way to filter log entries such as thread name and
> severity. i say i want to look at warnings and up from the worker 15
> thread. the table below filters the log. ten minutes later i want to
> see new log entries, so i refresh. but because a new page instance is
> created i have to reselect the severity and thread name.

Ok, and now split the above use cases over two sessions. Load the page,
turn to the required tabs, filter log entries like you want etc. Then
bookmark, and the next day at some point open the page from the
bookmark, expecting not having the described frustrations. But you will
have exactly the frustrations described above, and more: the page
instance you will be looking at depends on what you did in your current
session at some point, as the bookmark possibly refers to an old page
id. To a user this is completely random.

Hence we use the NoVersionMount, and model the UI changes you described
either via page parameters, in server side user-preferences, or in the
client side (web browser) state. Solving both what you describe above
and making it possible to bookmark that between sessions. 

Again: it's not for every app. It's nice that wicket can keep such state
automatically for you. But doing that has drawbacks as well, listed by
some in this thread. It would be nice to have NoVersionMount like 
functionality more easily available. Unless of course it's broken, but
so far it doesn't seem to be.

And now I go for a beer, and will forget this thread for at least a very
long sunny spring weekend.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: What real life scenario calls for page ID?

[Pointbreak]

On Thu, Mar 22, 2012, at 14:34, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 1:58 PM, Pointbreak
>  wrote:
> > On Thu, Mar 22, 2012, at 12:30, Igor Vaynberg wrote:
> >> On Thu, Mar 22, 2012 at 12:24 PM, Pointbreak
> >>  wrote:
> >> > On Thu, Mar 22, 2012, at 12:05, Igor Vaynberg wrote:
> >> >> On Thu, Mar 22, 2012 at 11:55 AM, Pointbreak
> >> >>  wrote:
> >> >> > On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
> >> >> >> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
> >> >> >>  wrote:
> >> >> >> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
> >> >> >> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
> >> >> >> >>  wrote:
> >> >> >> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> >> >> >> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
> >> >> >> >> >>  wrote:
> >> >> >> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> >> >> >> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> >> >> >> >> >> >>  wrote:
> >> >> >> >> >> >> > On Sun, Mar 18, 2012, at 20:00, Igor Vaynberg wrote:
> >> >> >> >> >> >> >> i think there is some confusion here. wicket 1.4 had 
> >> >> >> >> >> >> >> page ids. it also
> >> >> >> >> >> >> >> had page versions. in 1.5 we simply merged page id and 
> >> >> >> >> >> >> >> page version
> >> >> >> >> >> >> >> into the same variable - page id. this made things much 
> >> >> >> >> >> >> >> simpler and
> >> >> >> >> >> >> >> also allowed some usecases that were not possible when 
> >> >> >> >> >> >> >> the two were
> >> >> >> >> >> >> >> separate.
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> you dont have to go very far to come up with an example 
> >> >> >> >> >> >> >> where page id is
> >> >> >> >> >> >> >> useful.
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> 1. suppose you have a page with panel A that has a link
> >> >> >> >> >> >> >> 2. user hits a link on the page that swaps panel A for 
> >> >> >> >> >> >> >> panel B
> >> >> >> >> >> >> >> 3. user presses the back button
> >> >> >> >> >> >> >> 4. user clicks the link on panel A
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> now if you turn off page id and therefore page 
> >> >> >> >> >> >> >> versioning it goes like
> >> >> >> >> >> >> >> this
> >> >> >> >> >> >> >> 1. wicket creates page and assigns it id 1
> >> >> >> >> >> >> >> 2. page id 1 now has panel B instead of panel A
> >> >> >> >> >> >> >> 3. page with id 1 is rerendered
> >> >> >> >> >> >> >> 4. wicket loads page with id 1. user gets an error 
> >> >> >> >> >> >> >> because it cannot
> >> >> >> >> >> >> >> find the link component the user clicked since the page 
> >> >> >> >> >> >> >> has panel B
> >> >> >> >> >> >> >> instead of panel A
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >
> >> >> >> >> >> >> > This is imho not what happens with NoVersionMount. What 
> >> >> >> >> >> >> > happens is:
> >> >> >> >> >> >> >
> >> >> >> >> >> >> > 1. wicket creat

Re: What real life scenario calls for page ID?

[Pointbreak]

On Thu, Mar 22, 2012, at 12:30, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 12:24 PM, Pointbreak
>  wrote:
> > On Thu, Mar 22, 2012, at 12:05, Igor Vaynberg wrote:
> >> On Thu, Mar 22, 2012 at 11:55 AM, Pointbreak
> >>  wrote:
> >> > On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
> >> >> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
> >> >>  wrote:
> >> >> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
> >> >> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
> >> >> >>  wrote:
> >> >> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> >> >> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
> >> >> >> >>  wrote:
> >> >> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> >> >> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> >> >> >> >> >>  wrote:
> >> >> >> >> >> > On Sun, Mar 18, 2012, at 20:00, Igor Vaynberg wrote:
> >> >> >> >> >> >> i think there is some confusion here. wicket 1.4 had page 
> >> >> >> >> >> >> ids. it also
> >> >> >> >> >> >> had page versions. in 1.5 we simply merged page id and page 
> >> >> >> >> >> >> version
> >> >> >> >> >> >> into the same variable - page id. this made things much 
> >> >> >> >> >> >> simpler and
> >> >> >> >> >> >> also allowed some usecases that were not possible when the 
> >> >> >> >> >> >> two were
> >> >> >> >> >> >> separate.
> >> >> >> >> >> >>
> >> >> >> >> >> >> you dont have to go very far to come up with an example 
> >> >> >> >> >> >> where page id is
> >> >> >> >> >> >> useful.
> >> >> >> >> >> >>
> >> >> >> >> >> >> 1. suppose you have a page with panel A that has a link
> >> >> >> >> >> >> 2. user hits a link on the page that swaps panel A for 
> >> >> >> >> >> >> panel B
> >> >> >> >> >> >> 3. user presses the back button
> >> >> >> >> >> >> 4. user clicks the link on panel A
> >> >> >> >> >> >>
> >> >> >> >> >> >> now if you turn off page id and therefore page versioning 
> >> >> >> >> >> >> it goes like
> >> >> >> >> >> >> this
> >> >> >> >> >> >> 1. wicket creates page and assigns it id 1
> >> >> >> >> >> >> 2. page id 1 now has panel B instead of panel A
> >> >> >> >> >> >> 3. page with id 1 is rerendered
> >> >> >> >> >> >> 4. wicket loads page with id 1. user gets an error because 
> >> >> >> >> >> >> it cannot
> >> >> >> >> >> >> find the link component the user clicked since the page has 
> >> >> >> >> >> >> panel B
> >> >> >> >> >> >> instead of panel A
> >> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> > This is imho not what happens with NoVersionMount. What 
> >> >> >> >> >> > happens is:
> >> >> >> >> >> >
> >> >> >> >> >> > 1. wicket creates page and assigns it id 1
> >> >> >> >> >> > 2. page id 1 now has panel B instead of panel A
> >> >> >> >> >> > 3. wicket creates new page and assigns it id 2; depending on 
> >> >> >> >> >> > how the
> >> >> >> >> >> > page keeps state either a page with panel A and link, or a 
> >> >> >> >> >> > page with
> >> >> >> >> >> > Panel B is created.
> >> >> >> >> >> >
&

Re: What real life scenario calls for page ID?

[Pointbreak]

On Thu, Mar 22, 2012, at 12:30, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 12:24 PM, Pointbreak
>  wrote:
> > On Thu, Mar 22, 2012, at 12:05, Igor Vaynberg wrote:
> >> On Thu, Mar 22, 2012 at 11:55 AM, Pointbreak
> >>  wrote:
> >> > On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
> >> >> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
> >> >>  wrote:
> >> >> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
> >> >> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
> >> >> >>  wrote:
> >> >> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> >> >> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
> >> >> >> >>  wrote:
> >> >> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> >> >> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> >> >> >> >> >>  wrote:
> >> >> >> >> >> > On Sun, Mar 18, 2012, at 20:00, Igor Vaynberg wrote:
> >> >> >> >> >> >> i think there is some confusion here. wicket 1.4 had page 
> >> >> >> >> >> >> ids. it also
> >> >> >> >> >> >> had page versions. in 1.5 we simply merged page id and page 
> >> >> >> >> >> >> version
> >> >> >> >> >> >> into the same variable - page id. this made things much 
> >> >> >> >> >> >> simpler and
> >> >> >> >> >> >> also allowed some usecases that were not possible when the 
> >> >> >> >> >> >> two were
> >> >> >> >> >> >> separate.
> >> >> >> >> >> >>
> >> >> >> >> >> >> you dont have to go very far to come up with an example 
> >> >> >> >> >> >> where page id is
> >> >> >> >> >> >> useful.
> >> >> >> >> >> >>
> >> >> >> >> >> >> 1. suppose you have a page with panel A that has a link
> >> >> >> >> >> >> 2. user hits a link on the page that swaps panel A for 
> >> >> >> >> >> >> panel B
> >> >> >> >> >> >> 3. user presses the back button
> >> >> >> >> >> >> 4. user clicks the link on panel A
> >> >> >> >> >> >>
> >> >> >> >> >> >> now if you turn off page id and therefore page versioning 
> >> >> >> >> >> >> it goes like
> >> >> >> >> >> >> this
> >> >> >> >> >> >> 1. wicket creates page and assigns it id 1
> >> >> >> >> >> >> 2. page id 1 now has panel B instead of panel A
> >> >> >> >> >> >> 3. page with id 1 is rerendered
> >> >> >> >> >> >> 4. wicket loads page with id 1. user gets an error because 
> >> >> >> >> >> >> it cannot
> >> >> >> >> >> >> find the link component the user clicked since the page has 
> >> >> >> >> >> >> panel B
> >> >> >> >> >> >> instead of panel A
> >> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> > This is imho not what happens with NoVersionMount. What 
> >> >> >> >> >> > happens is:
> >> >> >> >> >> >
> >> >> >> >> >> > 1. wicket creates page and assigns it id 1
> >> >> >> >> >> > 2. page id 1 now has panel B instead of panel A
> >> >> >> >> >> > 3. wicket creates new page and assigns it id 2; depending on 
> >> >> >> >> >> > how the
> >> >> >> >> >> > page keeps state either a page with panel A and link, or a 
> >> >> >> >> >> > page with
> >> >> >> >> >> > Panel B is created.
> >> >> >> >> >> >
&

Re: What real life scenario calls for page ID?

[Pointbreak]

On Thu, Mar 22, 2012, at 12:05, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 11:55 AM, Pointbreak
>  wrote:
> > On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
> >> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
> >>  wrote:
> >> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
> >> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
> >> >>  wrote:
> >> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> >> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
> >> >> >>  wrote:
> >> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> >> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> >> >> >> >>  wrote:
> >> >> >> >> > On Sun, Mar 18, 2012, at 20:00, Igor Vaynberg wrote:
> >> >> >> >> >> i think there is some confusion here. wicket 1.4 had page ids. 
> >> >> >> >> >> it also
> >> >> >> >> >> had page versions. in 1.5 we simply merged page id and page 
> >> >> >> >> >> version
> >> >> >> >> >> into the same variable - page id. this made things much 
> >> >> >> >> >> simpler and
> >> >> >> >> >> also allowed some usecases that were not possible when the two 
> >> >> >> >> >> were
> >> >> >> >> >> separate.
> >> >> >> >> >>
> >> >> >> >> >> you dont have to go very far to come up with an example where 
> >> >> >> >> >> page id is
> >> >> >> >> >> useful.
> >> >> >> >> >>
> >> >> >> >> >> 1. suppose you have a page with panel A that has a link
> >> >> >> >> >> 2. user hits a link on the page that swaps panel A for panel B
> >> >> >> >> >> 3. user presses the back button
> >> >> >> >> >> 4. user clicks the link on panel A
> >> >> >> >> >>
> >> >> >> >> >> now if you turn off page id and therefore page versioning it 
> >> >> >> >> >> goes like
> >> >> >> >> >> this
> >> >> >> >> >> 1. wicket creates page and assigns it id 1
> >> >> >> >> >> 2. page id 1 now has panel B instead of panel A
> >> >> >> >> >> 3. page with id 1 is rerendered
> >> >> >> >> >> 4. wicket loads page with id 1. user gets an error because it 
> >> >> >> >> >> cannot
> >> >> >> >> >> find the link component the user clicked since the page has 
> >> >> >> >> >> panel B
> >> >> >> >> >> instead of panel A
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> > This is imho not what happens with NoVersionMount. What happens 
> >> >> >> >> > is:
> >> >> >> >> >
> >> >> >> >> > 1. wicket creates page and assigns it id 1
> >> >> >> >> > 2. page id 1 now has panel B instead of panel A
> >> >> >> >> > 3. wicket creates new page and assigns it id 2; depending on 
> >> >> >> >> > how the
> >> >> >> >> > page keeps state either a page with panel A and link, or a page 
> >> >> >> >> > with
> >> >> >> >> > Panel B is created.
> >> >> >> >> >
> >> >> >> >> > Hence, there is nothing broken in this scenario.
> >> >> >> >>
> >> >> >> >> we were talking about something else here. the NoVersionMount has 
> >> >> >> >> the
> >> >> >> >> problem of losing ajax state when the user refreshes the page.
> >> >> >> >>
> >> >> >> >
> >> >> >> > I believe the OP's question was for use-cases were Wickets default
> >> >> >> > behaviour would be preferred over using a strategy like 
> >> >> 

Re: What real life scenario calls for page ID?

[Pointbreak]

On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
>  wrote:
> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
> >>  wrote:
> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
> >> >>  wrote:
> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> >> >> >>  wrote:
> >> >> >> > On Sun, Mar 18, 2012, at 20:00, Igor Vaynberg wrote:
> >> >> >> >> i think there is some confusion here. wicket 1.4 had page ids. it 
> >> >> >> >> also
> >> >> >> >> had page versions. in 1.5 we simply merged page id and page 
> >> >> >> >> version
> >> >> >> >> into the same variable - page id. this made things much simpler 
> >> >> >> >> and
> >> >> >> >> also allowed some usecases that were not possible when the two 
> >> >> >> >> were
> >> >> >> >> separate.
> >> >> >> >>
> >> >> >> >> you dont have to go very far to come up with an example where 
> >> >> >> >> page id is
> >> >> >> >> useful.
> >> >> >> >>
> >> >> >> >> 1. suppose you have a page with panel A that has a link
> >> >> >> >> 2. user hits a link on the page that swaps panel A for panel B
> >> >> >> >> 3. user presses the back button
> >> >> >> >> 4. user clicks the link on panel A
> >> >> >> >>
> >> >> >> >> now if you turn off page id and therefore page versioning it goes 
> >> >> >> >> like
> >> >> >> >> this
> >> >> >> >> 1. wicket creates page and assigns it id 1
> >> >> >> >> 2. page id 1 now has panel B instead of panel A
> >> >> >> >> 3. page with id 1 is rerendered
> >> >> >> >> 4. wicket loads page with id 1. user gets an error because it 
> >> >> >> >> cannot
> >> >> >> >> find the link component the user clicked since the page has panel 
> >> >> >> >> B
> >> >> >> >> instead of panel A
> >> >> >> >>
> >> >> >> >
> >> >> >> > This is imho not what happens with NoVersionMount. What happens is:
> >> >> >> >
> >> >> >> > 1. wicket creates page and assigns it id 1
> >> >> >> > 2. page id 1 now has panel B instead of panel A
> >> >> >> > 3. wicket creates new page and assigns it id 2; depending on how 
> >> >> >> > the
> >> >> >> > page keeps state either a page with panel A and link, or a page 
> >> >> >> > with
> >> >> >> > Panel B is created.
> >> >> >> >
> >> >> >> > Hence, there is nothing broken in this scenario.
> >> >> >>
> >> >> >> we were talking about something else here. the NoVersionMount has the
> >> >> >> problem of losing ajax state when the user refreshes the page.
> >> >> >>
> >> >> >
> >> >> > I believe the OP's question was for use-cases were Wickets default
> >> >> > behaviour would be preferred over using a strategy like 
> >> >> > NoVersionMount.
> >> >> > But if I understood that incorrectly, it's now my question  ;-).
> >> >> > Imho
> >> >> > the natural behaviour a user expects for a page-refresh is a fresh
> >> >> > up-to-date version of the page. This is exactly what NoVersionMount 
> >> >> > does
> >> >> > as it forces a newly constructed page for a refresh. For OP's (Chris
> >> >> > Colman's) shopping card example this seems perfectly reasonable
> >> >> > behaviour.
> >> >>
> >> >> it is undesirable in applications that perform navigation using ajax
> >> >> panel swapping. in this case a pa

Re: What real life scenario calls for page ID?

[Pointbreak]

On Thu, Mar 22, 2012, at 11:42, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 11:37 AM, Pointbreak
>  wrote:
> > On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
> >> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
> >>  wrote:
> >> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> >> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
> >> >>  wrote:
> >> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> >> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> >> >> >>  wrote:
> >> >> >> > On Sun, Mar 18, 2012, at 20:00, Igor Vaynberg wrote:
> >> >> >> >> i think there is some confusion here. wicket 1.4 had page ids. it 
> >> >> >> >> also
> >> >> >> >> had page versions. in 1.5 we simply merged page id and page 
> >> >> >> >> version
> >> >> >> >> into the same variable - page id. this made things much simpler 
> >> >> >> >> and
> >> >> >> >> also allowed some usecases that were not possible when the two 
> >> >> >> >> were
> >> >> >> >> separate.
> >> >> >> >>
> >> >> >> >> you dont have to go very far to come up with an example where 
> >> >> >> >> page id is
> >> >> >> >> useful.
> >> >> >> >>
> >> >> >> >> 1. suppose you have a page with panel A that has a link
> >> >> >> >> 2. user hits a link on the page that swaps panel A for panel B
> >> >> >> >> 3. user presses the back button
> >> >> >> >> 4. user clicks the link on panel A
> >> >> >> >>
> >> >> >> >> now if you turn off page id and therefore page versioning it goes 
> >> >> >> >> like
> >> >> >> >> this
> >> >> >> >> 1. wicket creates page and assigns it id 1
> >> >> >> >> 2. page id 1 now has panel B instead of panel A
> >> >> >> >> 3. page with id 1 is rerendered
> >> >> >> >> 4. wicket loads page with id 1. user gets an error because it 
> >> >> >> >> cannot
> >> >> >> >> find the link component the user clicked since the page has panel 
> >> >> >> >> B
> >> >> >> >> instead of panel A
> >> >> >> >>
> >> >> >> >
> >> >> >> > This is imho not what happens with NoVersionMount. What happens is:
> >> >> >> >
> >> >> >> > 1. wicket creates page and assigns it id 1
> >> >> >> > 2. page id 1 now has panel B instead of panel A
> >> >> >> > 3. wicket creates new page and assigns it id 2; depending on how 
> >> >> >> > the
> >> >> >> > page keeps state either a page with panel A and link, or a page 
> >> >> >> > with
> >> >> >> > Panel B is created.
> >> >> >> >
> >> >> >> > Hence, there is nothing broken in this scenario.
> >> >> >>
> >> >> >> we were talking about something else here. the NoVersionMount has the
> >> >> >> problem of losing ajax state when the user refreshes the page.
> >> >> >>
> >> >> >
> >> >> > I believe the OP's question was for use-cases were Wickets default
> >> >> > behaviour would be preferred over using a strategy like 
> >> >> > NoVersionMount.
> >> >> > But if I understood that incorrectly, it's now my question  ;-).
> >> >> > Imho
> >> >> > the natural behaviour a user expects for a page-refresh is a fresh
> >> >> > up-to-date version of the page. This is exactly what NoVersionMount 
> >> >> > does
> >> >> > as it forces a newly constructed page for a refresh. For OP's (Chris
> >> >> > Colman's) shopping card example this seems perfectly reasonable
> >> >> > behaviour.
> >> >>
> >> >> it is undesirable in applications that perform navigation using ajax
> >> >> panel swapping. in this case a pa

Re: What real life scenario calls for page ID?

[Pointbreak]

On Thu, Mar 22, 2012, at 10:56, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 10:20 AM, Pointbreak
>  wrote:
> > On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> >> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
> >>  wrote:
> >> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> >> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> >> >>  wrote:
> >> >> > On Sun, Mar 18, 2012, at 20:00, Igor Vaynberg wrote:
> >> >> >> i think there is some confusion here. wicket 1.4 had page ids. it 
> >> >> >> also
> >> >> >> had page versions. in 1.5 we simply merged page id and page version
> >> >> >> into the same variable - page id. this made things much simpler and
> >> >> >> also allowed some usecases that were not possible when the two were
> >> >> >> separate.
> >> >> >>
> >> >> >> you dont have to go very far to come up with an example where page 
> >> >> >> id is
> >> >> >> useful.
> >> >> >>
> >> >> >> 1. suppose you have a page with panel A that has a link
> >> >> >> 2. user hits a link on the page that swaps panel A for panel B
> >> >> >> 3. user presses the back button
> >> >> >> 4. user clicks the link on panel A
> >> >> >>
> >> >> >> now if you turn off page id and therefore page versioning it goes 
> >> >> >> like
> >> >> >> this
> >> >> >> 1. wicket creates page and assigns it id 1
> >> >> >> 2. page id 1 now has panel B instead of panel A
> >> >> >> 3. page with id 1 is rerendered
> >> >> >> 4. wicket loads page with id 1. user gets an error because it cannot
> >> >> >> find the link component the user clicked since the page has panel B
> >> >> >> instead of panel A
> >> >> >>
> >> >> >
> >> >> > This is imho not what happens with NoVersionMount. What happens is:
> >> >> >
> >> >> > 1. wicket creates page and assigns it id 1
> >> >> > 2. page id 1 now has panel B instead of panel A
> >> >> > 3. wicket creates new page and assigns it id 2; depending on how the
> >> >> > page keeps state either a page with panel A and link, or a page with
> >> >> > Panel B is created.
> >> >> >
> >> >> > Hence, there is nothing broken in this scenario.
> >> >>
> >> >> we were talking about something else here. the NoVersionMount has the
> >> >> problem of losing ajax state when the user refreshes the page.
> >> >>
> >> >
> >> > I believe the OP's question was for use-cases were Wickets default
> >> > behaviour would be preferred over using a strategy like NoVersionMount.
> >> > But if I understood that incorrectly, it's now my question  ;-).
> >> > Imho
> >> > the natural behaviour a user expects for a page-refresh is a fresh
> >> > up-to-date version of the page. This is exactly what NoVersionMount does
> >> > as it forces a newly constructed page for a refresh. For OP's (Chris
> >> > Colman's) shopping card example this seems perfectly reasonable
> >> > behaviour.
> >>
> >> it is undesirable in applications that perform navigation using ajax
> >> panel swapping. in this case a page-refresh will essentially take you
> >> back to the homepage.
> >
> > Fair enough
> >
> >> > I have never had to build a website were it was a problem when the ajax
> >> > state was lost on page refresh.
> >>
> >> but you also have not built every wicket application...
> >
> > Obviously... to be honest, for your use case (one page ajax application
> > that performs navigation by swapping page components) I have always
> > chosen other frameworks, that are (imho) better suited for these
> > usecases.
> >
> >> > When wicket shows older versions of a
> >> > page (e.g. due to back button, bookmarking older versions, etc.), you
> >> > have to be really careful with how a page version and a model interact
> >> > to not run into trouble. You also loose bookmarkability of such pages
> >> > (in the web-browser sense, not in the wicket-sense).
> >>

Re: What real life scenario calls for page ID?

[Pointbreak]

On Thu, Mar 22, 2012, at 09:49, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 8:54 AM, Pointbreak
>  wrote:
> > On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> >> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
> >>  wrote:
> >> > On Sun, Mar 18, 2012, at 20:00, Igor Vaynberg wrote:
> >> >> i think there is some confusion here. wicket 1.4 had page ids. it also
> >> >> had page versions. in 1.5 we simply merged page id and page version
> >> >> into the same variable - page id. this made things much simpler and
> >> >> also allowed some usecases that were not possible when the two were
> >> >> separate.
> >> >>
> >> >> you dont have to go very far to come up with an example where page id is
> >> >> useful.
> >> >>
> >> >> 1. suppose you have a page with panel A that has a link
> >> >> 2. user hits a link on the page that swaps panel A for panel B
> >> >> 3. user presses the back button
> >> >> 4. user clicks the link on panel A
> >> >>
> >> >> now if you turn off page id and therefore page versioning it goes like
> >> >> this
> >> >> 1. wicket creates page and assigns it id 1
> >> >> 2. page id 1 now has panel B instead of panel A
> >> >> 3. page with id 1 is rerendered
> >> >> 4. wicket loads page with id 1. user gets an error because it cannot
> >> >> find the link component the user clicked since the page has panel B
> >> >> instead of panel A
> >> >>
> >> >
> >> > This is imho not what happens with NoVersionMount. What happens is:
> >> >
> >> > 1. wicket creates page and assigns it id 1
> >> > 2. page id 1 now has panel B instead of panel A
> >> > 3. wicket creates new page and assigns it id 2; depending on how the
> >> > page keeps state either a page with panel A and link, or a page with
> >> > Panel B is created.
> >> >
> >> > Hence, there is nothing broken in this scenario.
> >>
> >> we were talking about something else here. the NoVersionMount has the
> >> problem of losing ajax state when the user refreshes the page.
> >>
> >
> > I believe the OP's question was for use-cases were Wickets default
> > behaviour would be preferred over using a strategy like NoVersionMount.
> > But if I understood that incorrectly, it's now my question  ;-).
> > Imho
> > the natural behaviour a user expects for a page-refresh is a fresh
> > up-to-date version of the page. This is exactly what NoVersionMount does
> > as it forces a newly constructed page for a refresh. For OP's (Chris
> > Colman's) shopping card example this seems perfectly reasonable
> > behaviour.
> 
> it is undesirable in applications that perform navigation using ajax
> panel swapping. in this case a page-refresh will essentially take you
> back to the homepage.

Fair enough

> > I have never had to build a website were it was a problem when the ajax
> > state was lost on page refresh.
> 
> but you also have not built every wicket application...

Obviously... to be honest, for your use case (one page ajax application
that performs navigation by swapping page components) I have always
chosen other frameworks, that are (imho) better suited for these
usecases. 

> > When wicket shows older versions of a
> > page (e.g. due to back button, bookmarking older versions, etc.), you
> > have to be really careful with how a page version and a model interact
> > to not run into trouble. You also loose bookmarkability of such pages
> > (in the web-browser sense, not in the wicket-sense).
> 
> you also lose it if the user bookmarks the page after they click
> something on a bookmarkable page... so stripping the version off
> initial entry is not fixing the problem entirely.

I don't see this. They always get an up-to-date version of the page they
bookmarked, as it is always freshly constructed.

Ok, I can see the usecase for this page-id/version functionality.
However, I still think it would be useful if Wicket also catered for the
other usecase, where page navigation is handled by just having multiple
pages. Is there a serious flaw in the NoVersionMount strategy for these
usecases, and if not, wouldn't something like that be a valuable
contribution to Wicket? (In which case I think it should not be turned
on by a MountMapper implementation, but by a page property).

I have always considered Wicket's main strength the flexibility to have
ajax-like functionality in a page based component framework. It's a
really nice thing to be able to have support for good looking and
bookmarkable url's in such applications. And it also makes page state
management easier for these pages (i.e. when a LDM and the component
hierarchy on a page have a relation).

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: What real life scenario calls for page ID?

[Pointbreak]

On Thu, Mar 22, 2012, at 08:23, Igor Vaynberg wrote:
> On Thu, Mar 22, 2012 at 7:59 AM, Pointbreak
>  wrote:
> > On Sun, Mar 18, 2012, at 20:00, Igor Vaynberg wrote:
> >> i think there is some confusion here. wicket 1.4 had page ids. it also
> >> had page versions. in 1.5 we simply merged page id and page version
> >> into the same variable - page id. this made things much simpler and
> >> also allowed some usecases that were not possible when the two were
> >> separate.
> >>
> >> you dont have to go very far to come up with an example where page id is
> >> useful.
> >>
> >> 1. suppose you have a page with panel A that has a link
> >> 2. user hits a link on the page that swaps panel A for panel B
> >> 3. user presses the back button
> >> 4. user clicks the link on panel A
> >>
> >> now if you turn off page id and therefore page versioning it goes like
> >> this
> >> 1. wicket creates page and assigns it id 1
> >> 2. page id 1 now has panel B instead of panel A
> >> 3. page with id 1 is rerendered
> >> 4. wicket loads page with id 1. user gets an error because it cannot
> >> find the link component the user clicked since the page has panel B
> >> instead of panel A
> >>
> >
> > This is imho not what happens with NoVersionMount. What happens is:
> >
> > 1. wicket creates page and assigns it id 1
> > 2. page id 1 now has panel B instead of panel A
> > 3. wicket creates new page and assigns it id 2; depending on how the
> > page keeps state either a page with panel A and link, or a page with
> > Panel B is created.
> >
> > Hence, there is nothing broken in this scenario.
> 
> we were talking about something else here. the NoVersionMount has the
> problem of losing ajax state when the user refreshes the page.
> 

I believe the OP's question was for use-cases were Wickets default
behaviour would be preferred over using a strategy like NoVersionMount.
But if I understood that incorrectly, it's now my question  ;-). Imho
the natural behaviour a user expects for a page-refresh is a fresh
up-to-date version of the page. This is exactly what NoVersionMount does
as it forces a newly constructed page for a refresh. For OP's (Chris
Colman's) shopping card example this seems perfectly reasonable
behaviour.

I have never had to build a website were it was a problem when the ajax
state was lost on page refresh. When wicket shows older versions of a
page (e.g. due to back button, bookmarking older versions, etc.), you
have to be really careful with how a page version and a model interact
to not run into trouble. You also loose bookmarkability of such pages
(in the web-browser sense, not in the wicket-sense).

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: What real life scenario calls for page ID?

[Pointbreak]

On Sun, Mar 18, 2012, at 20:00, Igor Vaynberg wrote:
> i think there is some confusion here. wicket 1.4 had page ids. it also
> had page versions. in 1.5 we simply merged page id and page version
> into the same variable - page id. this made things much simpler and
> also allowed some usecases that were not possible when the two were
> separate.
> 
> you dont have to go very far to come up with an example where page id is
> useful.
> 
> 1. suppose you have a page with panel A that has a link
> 2. user hits a link on the page that swaps panel A for panel B
> 3. user presses the back button
> 4. user clicks the link on panel A
> 
> now if you turn off page id and therefore page versioning it goes like
> this
> 1. wicket creates page and assigns it id 1
> 2. page id 1 now has panel B instead of panel A
> 3. page with id 1 is rerendered
> 4. wicket loads page with id 1. user gets an error because it cannot
> find the link component the user clicked since the page has panel B
> instead of panel A
> 

This is imho not what happens with NoVersionMount. What happens is:

1. wicket creates page and assigns it id 1
2. page id 1 now has panel B instead of panel A
3. wicket creates new page and assigns it id 2, depending on the page
keeps state either a page with panel A and link, or a page with Panel B
is created.

Hence, there is nothing broken in this scenario.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: What real life scenario calls for page ID?

[Pointbreak]

On Sun, Mar 18, 2012, at 20:00, Igor Vaynberg wrote:
> i think there is some confusion here. wicket 1.4 had page ids. it also
> had page versions. in 1.5 we simply merged page id and page version
> into the same variable - page id. this made things much simpler and
> also allowed some usecases that were not possible when the two were
> separate.
> 
> you dont have to go very far to come up with an example where page id is
> useful.
> 
> 1. suppose you have a page with panel A that has a link
> 2. user hits a link on the page that swaps panel A for panel B
> 3. user presses the back button
> 4. user clicks the link on panel A
> 
> now if you turn off page id and therefore page versioning it goes like
> this
> 1. wicket creates page and assigns it id 1
> 2. page id 1 now has panel B instead of panel A
> 3. page with id 1 is rerendered
> 4. wicket loads page with id 1. user gets an error because it cannot
> find the link component the user clicked since the page has panel B
> instead of panel A
> 

This is imho not what happens with NoVersionMount. What happens is:

1. wicket creates page and assigns it id 1
2. page id 1 now has panel B instead of panel A
3. wicket creates new page and assigns it id 2; depending on how the
page keeps state either a page with panel A and link, or a page with
Panel B is created.

Hence, there is nothing broken in this scenario.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Using AbstractAjaxBehavior.getCallbackUrl during page construction

[Pointbreak]

We have recently upgraded our application from Wicket 1.4 to Wicket 1.5.
One problem we encounter is with Ajax handlers we have that use
AbstractAjaxBehavior.getCallbackUrl to bind serverside code to actions
in the browser. I have been debugging this, and the problem seems to be
that the callback-url puts a renderCount parameter in the url that gets
created. That renderCount however is invalid if you call
AbstractAjaxBehavior.getCallbackUrl during page construction, because in
the render phase the renderCount will be incremented. Effect: a
StalePageException will allways be thrown for such behaviours, because
the renderCount of the behaviour is always invalid. The
StalePageException leads to a new instance of the page, but again with
the same problems for these Ajax behaviours. 

I can probably workaround this by either changing the code to not use
renderCount for these bahviours (not so nice), or to change the
behaviours to move the rendering of the urls from page-construction to
page-render (is going to be a big change).

My question is: why is renderCount of a page not coupled to the page
construction, instead of to the page render. I believe many wicket pages
use a pattern that initializes their state during constructions, instead
of during render, and this renderCount issue affects all these pages
when they use Ajax. Comments?

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: What real life scenario calls for page ID?

[Pointbreak]

On Tue, Mar 20, 2012, at 10:50, Martin Grigorov wrote:
> On Tue, Mar 20, 2012 at 10:45 AM, Pointbreak
>  wrote:
> > On Tue, Mar 20, 2012, at 10:40, Martin Grigorov wrote:
> >> On Tue, Mar 20, 2012 at 10:38 AM, Pointbreak
> >>  wrote:
> >> > Yes (sort of) except you don't need two users. Just bookmark a page with
> >> > a version/id e.g. ?5, close the sessions, open a new session, do some
> >> > interaction so that another version of the page with version/id ?5
> >> > exists, and use that bookmark. Stuff like that confuses users even if
> >> > they don't care about "pretty" urls.
> >>
> >> But it is the same in 1.4.
> >> Do some Ajax interactions to swap panels for example, copy the url,
> >> then later paste it and you will see the initial version of the page,
> >> not the one with the swapped panels.
> >>
> >
> > Yes this was also the case in 1.4. But in 1.4 with
> > HybridUrlCodingStrategy you could work around that (sort of).
> 
> Please explain.

Sorry for confusion, we didn't use HybridUrlCodingStrategy, but
QueryStringUrlCodingStrategy. It doesn't put the version nr into the url
of stateful pages, but always gives the latest version of a page. That
solves the problem when bookmarking a page (because you don't bookmark a
specific version of a page, but just the page).

(It may however cause problems when users keep two versions of a page
open in two tabs and switch between them, since callbacks on one of them
are not in sync with the latest version.)

> >
> >> >
> >> > On Tue, Mar 20, 2012, at 10:07, Martin Grigorov wrote:
> >> >> On Tue, Mar 20, 2012 at 12:55 AM, Igor Vaynberg 
> >> >> 
> >> >> wrote:
> >> >> > indeed. we should check that the page pointed to by the id maps back
> >> >> > to the mount, and create a new instance based on the mount if it
> >> >> > doesnt. jira please.
> >> >>
> >> >> This is already the case, no need of a ticket for this. If there is no
> >> >> ?5 then Wicket creates ?0 and shows it.
> >> >>
> >> >> The "problem" Pointbreak actually mean is that userA may have opened
> >> >> ?5 in his session, copy the url and give it to
> >> >> userB, but userB also already have its own session and by chance he
> >> >> also had reached ?5 and these two ?5s are
> >> >> different because they may have different states for both users.
> >> >>
> >> >> The confusing part here is "bookmarkable". Now imagine that there is
> >> >> no ?pageId in the url. userA clicks several Ajax links to get to
> >> >> version5 of that page and then copy/paste the url but userB will see
> >> >> the initial state of the page, not version5 that userA actually meant.
> >> >> So it seems only ?0 is actually "bookmarkable" for stateful pages.
> >> >> Only in this case both users will see the same content (if there is no
> >> >> special logic for user permissions involved).
> >> >>
> >> >> If userA wants to fully share his page with userB then he has to share
> >> >> his session too, i.e. both ?5 and jessionid= has to be in the pasted
> >> >> url. I don't recomment this!
> >> >>
> >> >> ?5 helps when the user refreshes the page in his current session. In
> >> >> this case he will see the same content as before the refresh. In 1.4
> >> >> he'd see the initial state of the page and will loose any state that
> >> >> is not persisted so far.
> >> >>
> >> >>
> >> >> >
> >> >> > -igor
> >> >> >
> >> >> > On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak
> >> >> >  wrote:
> >> >> >> It's a problem when users bookmark it. Because ...?5 this session is 
> >> >> >> an
> >> >> >> entirely other page as ...?5 in another session tomorrow.
> >> >> >>
> >> >> >> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
> >> >> >>>
> >> >> >>>
> >> >> >>> On 2012-03-19 02:46, Paolo wrote:
> >> >> >>> > I support you! I implemented class NoVersionMount thanks to 
> >> >> >>> > pointbreak
> 

Re: What real life scenario calls for page ID?

[Pointbreak]

On Tue, Mar 20, 2012, at 10:40, Martin Grigorov wrote:
> On Tue, Mar 20, 2012 at 10:38 AM, Pointbreak
>  wrote:
> > Yes (sort of) except you don't need two users. Just bookmark a page with
> > a version/id e.g. ?5, close the sessions, open a new session, do some
> > interaction so that another version of the page with version/id ?5
> > exists, and use that bookmark. Stuff like that confuses users even if
> > they don't care about "pretty" urls.
> 
> But it is the same in 1.4.
> Do some Ajax interactions to swap panels for example, copy the url,
> then later paste it and you will see the initial version of the page,
> not the one with the swapped panels.
>

Yes this was also the case in 1.4. But in 1.4 with
HybridUrlCodingStrategy you could work around that (sort of).

> >
> > On Tue, Mar 20, 2012, at 10:07, Martin Grigorov wrote:
> >> On Tue, Mar 20, 2012 at 12:55 AM, Igor Vaynberg 
> >> wrote:
> >> > indeed. we should check that the page pointed to by the id maps back
> >> > to the mount, and create a new instance based on the mount if it
> >> > doesnt. jira please.
> >>
> >> This is already the case, no need of a ticket for this. If there is no
> >> ?5 then Wicket creates ?0 and shows it.
> >>
> >> The "problem" Pointbreak actually mean is that userA may have opened
> >> ?5 in his session, copy the url and give it to
> >> userB, but userB also already have its own session and by chance he
> >> also had reached ?5 and these two ?5s are
> >> different because they may have different states for both users.
> >>
> >> The confusing part here is "bookmarkable". Now imagine that there is
> >> no ?pageId in the url. userA clicks several Ajax links to get to
> >> version5 of that page and then copy/paste the url but userB will see
> >> the initial state of the page, not version5 that userA actually meant.
> >> So it seems only ?0 is actually "bookmarkable" for stateful pages.
> >> Only in this case both users will see the same content (if there is no
> >> special logic for user permissions involved).
> >>
> >> If userA wants to fully share his page with userB then he has to share
> >> his session too, i.e. both ?5 and jessionid= has to be in the pasted
> >> url. I don't recomment this!
> >>
> >> ?5 helps when the user refreshes the page in his current session. In
> >> this case he will see the same content as before the refresh. In 1.4
> >> he'd see the initial state of the page and will loose any state that
> >> is not persisted so far.
> >>
> >>
> >> >
> >> > -igor
> >> >
> >> > On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak
> >> >  wrote:
> >> >> It's a problem when users bookmark it. Because ...?5 this session is an
> >> >> entirely other page as ...?5 in another session tomorrow.
> >> >>
> >> >> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
> >> >>>
> >> >>>
> >> >>> On 2012-03-19 02:46, Paolo wrote:
> >> >>> > I support you! I implemented class NoVersionMount thanks to 
> >> >>> > pointbreak
> >> >>> > in my MainApplication. And It will be my template for future app. But
> >> >>> > to do it, I needed to understood the problem, check on google, read a
> >> >>> > lot of pages, without found a solution, so post the question here, 
> >> >>> > and
> >> >>> > after 3 post, got a right reply for me. Why an wicket user have to do
> >> >>> > all this Why not, wicket use the NoVersionMount as default Mount?
> >> >>> > Like in wicket 1.4. And implement an VersionMount as an alternative
> >> >>> > for developer?
> >> >>> I actually like this change so far. I can finally tell, that my page is
> >> >>> stetefull just by looking at the link and ask myself question - if I
> >> >>> really care so much about the clean link for this page, may be it 
> >> >>> should
> >> >>> be stateless in a first place?
> >> >>>
> >> >>> And why is ?0 such a big problem? It does not cause problems sending
> >> >>> links.
> >> >>> Is there any real proof of google indexing problems so far?
> >> >>>
> >> >>>
> >&

Re: What real life scenario calls for page ID?

[Pointbreak]

Yes (sort of) except you don't need two users. Just bookmark a page with
a version/id e.g. ?5, close the sessions, open a new session, do some
interaction so that another version of the page with version/id ?5
exists, and use that bookmark. Stuff like that confuses users even if
they don't care about "pretty" urls.

On Tue, Mar 20, 2012, at 10:07, Martin Grigorov wrote:
> On Tue, Mar 20, 2012 at 12:55 AM, Igor Vaynberg 
> wrote:
> > indeed. we should check that the page pointed to by the id maps back
> > to the mount, and create a new instance based on the mount if it
> > doesnt. jira please.
> 
> This is already the case, no need of a ticket for this. If there is no
> ?5 then Wicket creates ?0 and shows it.
> 
> The "problem" Pointbreak actually mean is that userA may have opened
> ?5 in his session, copy the url and give it to
> userB, but userB also already have its own session and by chance he
> also had reached ?5 and these two ?5s are
> different because they may have different states for both users.
> 
> The confusing part here is "bookmarkable". Now imagine that there is
> no ?pageId in the url. userA clicks several Ajax links to get to
> version5 of that page and then copy/paste the url but userB will see
> the initial state of the page, not version5 that userA actually meant.
> So it seems only ?0 is actually "bookmarkable" for stateful pages.
> Only in this case both users will see the same content (if there is no
> special logic for user permissions involved).
> 
> If userA wants to fully share his page with userB then he has to share
> his session too, i.e. both ?5 and jessionid= has to be in the pasted
> url. I don't recomment this!
> 
> ?5 helps when the user refreshes the page in his current session. In
> this case he will see the same content as before the refresh. In 1.4
> he'd see the initial state of the page and will loose any state that
> is not persisted so far.
> 
> 
> >
> > -igor
> >
> > On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak
> >  wrote:
> >> It's a problem when users bookmark it. Because ...?5 this session is an
> >> entirely other page as ...?5 in another session tomorrow.
> >>
> >> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
> >>>
> >>>
> >>> On 2012-03-19 02:46, Paolo wrote:
> >>> > I support you! I implemented class NoVersionMount thanks to pointbreak
> >>> > in my MainApplication. And It will be my template for future app. But
> >>> > to do it, I needed to understood the problem, check on google, read a
> >>> > lot of pages, without found a solution, so post the question here, and
> >>> > after 3 post, got a right reply for me. Why an wicket user have to do
> >>> > all this Why not, wicket use the NoVersionMount as default Mount?
> >>> > Like in wicket 1.4. And implement an VersionMount as an alternative
> >>> > for developer?
> >>> I actually like this change so far. I can finally tell, that my page is
> >>> stetefull just by looking at the link and ask myself question - if I
> >>> really care so much about the clean link for this page, may be it should
> >>> be stateless in a first place?
> >>>
> >>> And why is ?0 such a big problem? It does not cause problems sending
> >>> links.
> >>> Is there any real proof of google indexing problems so far?
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> 
> 
> 
> -- 
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: What real life scenario calls for page ID?

[Pointbreak]

It's a problem when users bookmark it. Because ...?5 this session is an
entirely other page as ...?5 in another session tomorrow.

On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote:
> 
> 
> On 2012-03-19 02:46, Paolo wrote:
> > I support you! I implemented class NoVersionMount thanks to pointbreak 
> > in my MainApplication. And It will be my template for future app. But 
> > to do it, I needed to understood the problem, check on google, read a 
> > lot of pages, without found a solution, so post the question here, and 
> > after 3 post, got a right reply for me. Why an wicket user have to do 
> > all this Why not, wicket use the NoVersionMount as default Mount? 
> > Like in wicket 1.4. And implement an VersionMount as an alternative 
> > for developer? 
> I actually like this change so far. I can finally tell, that my page is 
> stetefull just by looking at the link and ask myself question - if I 
> really care so much about the clean link for this page, may be it should 
> be stateless in a first place?
> 
> And why is ?0 such a big problem? It does not cause problems sending
> links.
> Is there any real proof of google indexing problems so far?
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: I don't want url page count parameter: localhost:8080/context/?0

[Pointbreak]

Create a class NoVersionMount:

/**
 * Provides a mount strategy that drops the version number from
 * stateful page urls.
 */
public class NoVersionMount extends MountedMapper {
public NoVersionMount(String path, Class pageClass) {
super(path, pageClass, new PageParametersEncoder());
}

@Override protected void encodePageComponentInfo(Url url,
PageComponentInfo info)
{
// do nothing so that component info does not get
// rendered in url
}

@Override public Url mapHandler(IRequestHandler
requestHandler)
{
if (requestHandler instanceof
ListenerInterfaceRequestHandler) {
return null;
} else {
return super.mapHandler(requestHandler);
}
}
}

And mount your pages using that mounted mapper, e.g.:

mount(new NoVersionMount("myPage", MyPage.class));

Cheers, Gerrit


On Sun, Mar 18, 2012, at 02:51, Paolo wrote:
> Hi,
> I read this old post to solve the my same problem:
> 
> ---
> I'm using Wicket 1.5.3, an application with a number of tabbed panels.
> 
> My application's url is, lets say http://localhost:9080/context/
> 
> When I enter this URL, the browse immediately changes this to
> http://localhost:9080/context/?0
> 
> I don't want that!!
> 
> When I enter userdata and switch some tabs, nothing happens, but when I
> hit
> F5 the URL changes to
> http://localhost:9080/context/?9 or another number, depending on my
> activity.
> I don't want that!!
> 
> I read this suggested link:
> http://stackoverflow.com/questions/8081143/components-not-reloading-on-url-change-in-wicket-1-5-2
> http://stackoverflow.com/questions/8135755/wicket-1-5-new-urls/8139152#8139152
> 
> 
> BUT I DON'T UNDERSTAND TO SOLVE THE SIMPLE PROBLEM!
> 
> I tried to change from
> 
> String id = inparams.get("id").toString();
> 
>TO
> 
> RequestCycle requestCycle = RequestCycle.get();
> Request request = requestCycle.getRequest();
> IRequestParameters irp = request.getRequestParameters();
> String id = irp.getParameterValue("id").toString();
> 
> BUT NOTHING CHANGED!
> 
> Please Help me, in this stupid wicket issue.
> 
> Thank you
> 
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket 1.5 rewrites template content - imho should not

[Pointbreak]

See https://issues.apache.org/jira/browse/WICKET-4425

On Tue, Feb 21, 2012, at 14:01, Martin Grigorov wrote:
> Hi,
> 
> Agree. Wicket should not do this in this case.
> File a ticket with a quickstart.
> 
> On Tue, Feb 21, 2012 at 1:42 PM, Pointbreak
>  wrote:
> > I have recently upgraded from Wicket 1.4.14 to 1.5.4. One issue that I
> > encountered is that  tags in panel templates are rewritten by
> > Wicket, even when the <script> tags in question have no wicket handlers
> > attached to them. I.e. the following panel template (notice that there
> > are no wicket:id attributes whatsoever):
> >
> > <wicket:panel>
> >    <script id="template-upload" type="text/x-jquery-tmpl">
> >        <span>${name}</span>
> >    
> > 
> >
> > Would render in the panel as:
> >
> > 
> > /*<![CDATA[*/
> >    <span>${name}</span>
> > /*]]>*/
> > 
> >
> > Imho this is unwanted behavior that is a regression from the behavior in
> > Wicket 1.4.x (or at least 1.4.14). Wicket should not add content to the
> > body of the script tags (or any other tags in a template, unless their
> > content is provided programmatically), as it does not have the knowledge
> > how that affects the functionality of the page. Moreover, the content
> > that Wicket adds to these script tags is only correct for Javascript
> > (hence incorrect for the scripts in the example as they are not
> > javascript). In the above example adding /*, */ and even the CDATA part
> > will change the functionality of the script tag. If the "/*

Re: Updating a component from custom thread or why getRequestCycle returns null

[Pointbreak]

You will still need client initiated requests to get your
"non-stop-updates" from the page/component to the browser. Hence, just
separate the work (which you can do continuously in your thread) from
the page rendering (which will need to be initiated by a browser request
whatever you do). Will make your live so much easier if you cleanly
separate those two tasks...

On Tue, Feb 21, 2012, at 04:48, BayPhilip wrote:
> Actually this is not my problem. You update component just once after
> some
> time while I need non-stop updating. I found a "semi-solution". I am
> using
> ScheduledThreadPoolExecutor.
> 
> final ExecutorService service = new ScheduledThreadPoolExecutor(100) {
> protected void beforeExecute(final Thread t, final Runnable r) {
> Application.set(getApplication());
> }
> protected void afterExecute(final Runnable r, final Throwable t)
> {
> Application.unset();
> }
> };
> service.submit(chat);
> 
> but..the thread is submitted, but it is not executed. I'm debugging
> and.there is nothing that calls my run() method in my thread. So how
> can
> execute this thread which is submited in service.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Wicket 1.5 rewrites template content - imho should not

[Pointbreak]

I have recently upgraded from Wicket 1.4.14 to 1.5.4. One issue that I
encountered is that  tags in panel templates are rewritten by
Wicket, even when the