[RELEASE] Wicket Stuff 6.0.0-beta3

2012-07-26 Thread Martijn Dashorst
This is my first Wicket Stuff release, so I hope I didn't mess up.
Below are the changes since 6.0.0-beta1

The release tag is wicketstuff-core-6.0.0-beta3

Have fun!

Martijn Dashorst

Martin Grigorov (9):
  Merge pull request #122 from JoachimRohde/master
  Merge pull request #124 from td-github/master
  Merge pull request #126 from td-github/master
  Merge pull request #132 from jesselong/master
  Merge pull request #133 from pausb/master
  Merge pull request #137 from minman/fix-130
  Merge pull request #139 from wickeria/master
  Merge pull request #142 from svieujot/master
  Merge pull request #141 from JoachimRohde/master

Martin Tzvetanov Grigorov (6):
  issue 123 - [wicket-html5] AjaxGeoLocationBehaviour does not
work with Wicket 6
  Upgrade versions of Maven plugins and Scala
  Fix compiling of Console project
  Rework the test to test for output instead of returned value
  [inmethod-grid] Upgrade InMethod Grid to Wicket 6.0-SNAPSHOT
  Add parameters to PageParameters.

Jesse Long (5):
  IXmlPullParser no longer throws ResourceStreamNotFoundException
  Latest packaged version of jquery is 1.7.2
  Add missing jquery-1.6.1.js file
  Generify SecureTabbedPanel like regular TabbedPanel
  Update package name for UrlDecoder and UrlEncoder imports

svenmeier (4):
  fixed compile error and got slider running in browser again,
change doesn't trigger the callback though :/
  IErrorMessageSource#substituteVariables() is merged into getMessage()
  make logo path absolute, otherwise it will not be loaded
  fixed resource reference to rpc resource

Georg Buschbeck (4):
  updated jquery dependencies
  added js files fixed version typo in LibraryData
  forgot file in previous commit
  Merge remote branch 'upstream/master'

j.rohde (3):
  Fixed compilation issue
  Make the wicketstuff-twitter module work with Wicket 6.
  [wicketstuff-security-wasp] Fixed compilation error.

Sven Meier (2):
  datatable now generified for sort parameter
  datatable now generified for sort parameter

JoachimRohde (2):
  Fixed compilation issue and a NPE in GMap2. -
wicket.contrib.gmap.api.GClientGeocoder#getCallbackScript could not be
compiled because getCallbackFunction didn't accept strings as
parameters. - In GOverlay a NullPointerException occured when
using the DragEndListener.
  Merge pull request #144 from JoachimRohde/master

Martijn Dashorst (2):
  Wicket 6.0.0-beta3
  Release Wicket Stuff 6.0.0-beta3 with Wicket 6.0.0-beta3

dan (1):
  normal links doesn't work in columns

Sylvain Vieujot (1):
  Create excel cells for the  tags.

jr (1):
  Implemented a callback method for the HTML5 Geolocation API in
case the user denies or ignores/dismisses the request for sharing his
location. Along the way the example code was updated to
demonstrate the new callback method. And since Foursquare (which was
used before in the example) requires authentication now, a reverse
geocoding request to OpenStreetMap is used as an example.

mam (1):
  fix-130 NPE when redirected from ajax

pausb (1):
  Changed Progress.java to support indeterminate progress elements

Emond Papegaaij (1):
  ported GMap2 and openlayers to Wicket 6, I'm not in the position
to test this, so it could still be broken

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



Re: renderHead() / wicket:head page / component order

2012-07-26 Thread Emond Papegaaij
On Thursday 26 July 2012 19:26:36 Pierre Goiffon wrote:
> Le 26/07/2012 10:29, Emond Papegaaij a écrit :
> > Second, I suggest you use Wicket 6, because consistent resource ordering
> > in
> > Wicket 1.5 is nearly impossible.
> 
> Reading this made me smile : we use Wicket for a while now, and
> upgrading major versions was almost always painfull. The most difficult
> time we add was with the migration to 1.5... So I don't think just a few
> week after fixing our first version using Wicket 1.5 and still having to
> deal with bugs related to the migration, my team would agreed to upgrade
> to Wicket 6, that is still in beta stage :)

Wicket 6 final won't take long. As far as I know, no serious issues have been 
reported against beta 3, which makes it the last beta. The next release will 
probably be 6.0.0.

> For now on we dealt with the resource order problem mainly using a
> custom implementation of AbstractResourceDependentResourceReference.
> 
> > HeaderResponseTest in Wicket 6 gives a good demonstration of the order of
> > resources. It shows that normal resources are rendered child-first,
> > starting at the root of the class inheritance hierarchy. If you change
> > nothing, the order will be B, C, A (A is last, because its header
> > contribution is via renderHead). To move A to the front, you wrap it in a
> > PriorityHeaderItem, and you should be done.
> 
> Where can I find this HeaderResponseTest class ? I don't have it in the
> wicket-core 6.0.0-beta3 avalaible via Maven ?
> Is it this one :
> http://svn.apache.org/repos/asf/wicket/trunk/wicket-core/src/test/java/org/a
> pache/wicket/markup/html/internal/HeaderResponseTest.java

Wicket moved to git some time ago. The testcase I was refering to is:
https://github.com/apache/wicket/blob/master/wicket-
core/src/test/java/org/apache/wicket/markup/head/HeaderResponseTest.java
 
> In Wicket 1.5 if I do nothing, resources contributed in renderHead()
> would be rendered in this order : C, B, A.
> I'm surprised the order would be B, C, A in Wicket 6 ? Why so ?

I'm not sure about the Wicket 1.5 ordering, but in Wicket 6, header items are 
rendered child-first in the component hierarchy. For every component, 
 is rendered first, followed by the header contributions in the 
Java code. Within a component's class hierarchy, rendering starts at the base 
class (as long as you put the super call at the top).

> In my exemple I need to define 2 priorities, because the css that was in
> the B page wicket:head needs to be before the one in page C, and the css
> linked in page A must be the first resource to be rendered. Could
> PriorityHeaderItem answer this need ?
> 
> > In Wicket 6, all headers are
> > rendered child-first, except PriorityHeaderItems, which are rendered
> > parent- first.
> 
> I see that in the PriorityHeaderItem Javadoc. Does that means if I add a
> PriorityHeaderItem in page A, and another in page B, the one in page A
> (parent page) will be rendered before page B (child page) ?

You seem to be confusing class inheritance with the component hierarchy. There 
is no component hierarchy between pages, only class inhertance. Header items 
are rendered top-down in the class inheritance chain. The reason that you will 
need PriorityHeaderItem for the resource from page A, is that you contribute 
it from Java, and it will therefore end up after the wicket:head 
contributions.

But all this is not relevant if you are using Wicket 1.5. In Wicket 1.5, there 
are no HeaderItems. Some rendering is done via special markup containers, some 
rendering is done via IHeaderResponse, some directly to the response. This is 
what makes it difficult to get the order of rendered items right. Rendering 
all contributions via IHeaderResponse does make it a lot easier. By default, 
Wicket renders the items in the order they were added to the IHeaderResponse 
(mostly child-first in the component hierarchy, starting at the base class in 
the inheritance chain). It has methods to render inline css. You can also use 
a decorator to collect items and sort them, this is what WiQuery does to get 
javascript files in the right order.


Best regards,
Emond

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



Re: I think it's time for a new book.... Igor and Co ?

2012-07-26 Thread Bertrand Guay-Paquet


writing the book was a very long and a very exhausting effort, much 
much more then i thought it would be. when i was done the book was 
actually twice as long as what was published, but the publisher wanted 
me to trim it down to keep the cost low... they would have to charge 
more if the book had more pages :/ the combination of those two things 
has burned me out somewhat. at least enough to make me want to go play 
with other things for a while. -igor 
Well thanks for your book (and all your other work as well)! I hope you 
have fun with these other things and perhaps someday your interest for 
Wicket will be rekindled! :)


Cheers,
Bertrand

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



Re: I think it's time for a new book.... Igor and Co ?

2012-07-26 Thread Igor Vaynberg
On Fri, Jul 27, 2012 at 12:20 AM, Bertrand Guay-Paquet
 wrote:
>
>> Seeing how the previous book authors became less active after writing
>> a book I think this is not a very good idea... :-/
>
> Is this because the books didn't sell well enough?

i can only speak for myself,

define enough :) i agreed to work on the book knowing full well it was
not going to sell a million copies. i wrote it so the community has an
easily accessible resource.

> I don't know the authors
> personally and I don't know much about the publishing world so it could very
> well be another reason altogether.

writing the book was a very long and a very exhausting effort, much
much more then i thought it would be. when i was done the book was
actually twice as long as what was published, but the publisher wanted
me to trim it down to keep the cost low... they would have to charge
more if the book had more pages :/

the combination of those two things has burned me out somewhat. at
least enough to make me want to go play with other things for a while.

-igor

>
>> Here is what I suggest: create a page in Wiki that lists the more
>> interesting topics. Then we (the people who know more about Wicket
>> internals) will try to fill the gaps by creating a separate Wiki page
>> for each topic, slowly, one at a time, without the pressure of the
>> publishers, etc. This way hopefully the community can help too by
>> keeping them up-to-date.
>
> This seems to me like a good approach. Perhaps a good starting point would
> be the table of contents of Wicket in Action.
>
>
> -
> 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 think it's time for a new book.... Igor and Co ?

2012-07-26 Thread Bertrand Guay-Paquet



Seeing how the previous book authors became less active after writing
a book I think this is not a very good idea... :-/
Is this because the books didn't sell well enough? I don't know the 
authors personally and I don't know much about the publishing world so 
it could very well be another reason altogether.

Here is what I suggest: create a page in Wiki that lists the more
interesting topics. Then we (the people who know more about Wicket
internals) will try to fill the gaps by creating a separate Wiki page
for each topic, slowly, one at a time, without the pressure of the
publishers, etc. This way hopefully the community can help too by
keeping them up-to-date.
This seems to me like a good approach. Perhaps a good starting point 
would be the table of contents of Wicket in Action.


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



Re: Image urls with CryptoMapper

2012-07-26 Thread jchappelle
Thanks Martin! I was hoping there was a static utility to rewrite that url.
I think this will get me what I need.

On Thu, Jul 26, 2012 at 3:50 PM, Martin Grigorov-4 [via Apache Wicket] <
ml-node+s1842946n465081...@n4.nabble.com> wrote:

> Hi,
>
> Either generate absolute urls from the backend service or if you are
> certain that the image url is context relative then pass it first to
> org.apache.wicket.core.util.string.UrlUtils#rewriteToContextRelative()
> before setting it in the model.
>
> On Thu, Jul 26, 2012 at 11:43 PM, jchappelle <[hidden 
> email]>
> wrote:
>
> > Sven,
> >
> > You closed this ticket but let me say this. I'm clearly not perfectly
> > reproducing what I am seeing in my live app. However, what is common is
> > that wicket is finding the hard-coded image on the second page because
> it
> > is rewriting the url of that image and it is not doing that for the
> dynamic
> > image. I believe this is the source of my problem in my live app because
> > when I look at the html the same thing is happening.
> >
> > Is there any advice you have on this issue?
> >
> > Josh
> >
> > On Thu, Jul 26, 2012 at 2:46 PM, Sven Meier [via Apache Wicket] <
> > [hidden email] >
> wrote:
> >
> >> That's hard to say from the snippet you've provided here, especially
> >> since a few markup tags didn't make it through.
> >>
> >> Please create an issue and attach your quickstart to it.
> >>
> >> Sven
> >>
> >> On 07/26/2012 09:31 PM, jchappelle wrote:
> >>
> >> > I'm hitting a problem with images not being found when using
> >> CryptoMapper. I
> >> > have 2 pages listed below. The dynamic image on the second page does
> not
> >> > show but it does on the first page. I get to the second page by
> clicking
> >> the
> >> > "Page 2" link on the first. The code below is from my quickstart I
> have
> >> > created. It is pretty small so I figured why not list it here. Any
> help
> >> is
> >> > appreciated.
> >> >
> >> >
> >> > public class Page1 extends WebPage
> >> > {
> >> > public Page1()
> >> > {
> >> > add(new ImagePanel("panel"));
> >> > add(new AjaxLink("page2Link")
> >> > {
> >> > @Override
> >> > public void onClick(AjaxRequestTarget target)
> >> > {
> >> > setResponsePage(Page2.class);
> >> > }
> >> > });
> >> > }
> >> > }
> >> >
> >> > 
> >> > http://wicket.apache.org";>
> >> > 
> >> > 
> >> > # Page 2
> >> > 
> >> > 
> >> >
> >> >
> >> > public class Page2 extends WebPage
> >> > {
> >> > public Page2()
> >> > {
> >> > add(new ImagePanel("panel"));
> >> > }
> >> > }
> >> >
> >> > 
> >> > http://wicket.apache.org";>
> >> > 
> >> > 
> >> > 
> >> > 
> >> >
> >> >
> >> > public class ImagePanel extends Panel
> >> > {
> >> > public ImagePanel(String id)
> >> > {
> >> > super(id);
> >> >
> >> > add(new Label("dynamicImage", Model.of("Image Here:
> >> > images/arrow-up-green.gif ")).setEscapeModelStrings(false));
> >> > }
> >> > }
> >> >
> >> > 
> >> > http://www.w3.org/1999/xhtml";
> >> > xmlns:wicket="http://wicket.apache.org/";>
> >> > 
> >> > Hard-Coded Image:  images/arrow-up-green.gif 
> >> > Dynamic Image: 
> >> > 
> >> > 
> >> >
> >> > public class WicketApplication extends WebApplication
> >> > {
> >> > @Override
> >> > public Class getHomePage()
> >> > {
> >> > return Page1.class;
> >> > }
> >> > @Override
> >> > public void init()
> >> > {
> >> > super.init();
> >> > setRootRequestMapper(new CryptoMapper(getRootRequestMapper(), this));
> >> > }
> >> > }
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > View this message in context:
> >>
> http://apache-wicket.1842946.n4.nabble.com/Image-urls-with-CryptoMapper-tp4650805.html
> >> > Sent from the Users forum mailing list archive at Nabble.com.
> >> >
> >> > -
> >> > To unsubscribe, e-mail: [hidden email]<
> http://user/SendEmail.jtp?type=node&node=4650806&i=0>
> >> > For additional commands, e-mail: [hidden email]<
> http://user/SendEmail.jtp?type=node&node=4650806&i=1>
> >> >
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: [hidden email]<
> http://user/SendEmail.jtp?type=node&node=4650806&i=2>
> >> For additional commands, e-mail: [hidden email]<
> http://user/SendEmail.jtp?type=node&node=4650806&i=3>
> >>
> >>
> >>
> >> --
> >>  If you reply to this email, your message will be added to the
> discussion
> >> below:
> >>
> >>
>
> >> .
> >> NAML<
> http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
> >>
> >
> >
> >
> >
> > --
> > View this message in context:
> http:

Re: Image urls with CryptoMapper

2012-07-26 Thread Martin Grigorov
Hi,

Either generate absolute urls from the backend service or if you are
certain that the image url is context relative then pass it first to
org.apache.wicket.core.util.string.UrlUtils#rewriteToContextRelative()
before setting it in the model.

On Thu, Jul 26, 2012 at 11:43 PM, jchappelle  wrote:
> Sven,
>
> You closed this ticket but let me say this. I'm clearly not perfectly
> reproducing what I am seeing in my live app. However, what is common is
> that wicket is finding the hard-coded image on the second page because it
> is rewriting the url of that image and it is not doing that for the dynamic
> image. I believe this is the source of my problem in my live app because
> when I look at the html the same thing is happening.
>
> Is there any advice you have on this issue?
>
> Josh
>
> On Thu, Jul 26, 2012 at 2:46 PM, Sven Meier [via Apache Wicket] <
> ml-node+s1842946n4650806...@n4.nabble.com> wrote:
>
>> That's hard to say from the snippet you've provided here, especially
>> since a few markup tags didn't make it through.
>>
>> Please create an issue and attach your quickstart to it.
>>
>> Sven
>>
>> On 07/26/2012 09:31 PM, jchappelle wrote:
>>
>> > I'm hitting a problem with images not being found when using
>> CryptoMapper. I
>> > have 2 pages listed below. The dynamic image on the second page does not
>> > show but it does on the first page. I get to the second page by clicking
>> the
>> > "Page 2" link on the first. The code below is from my quickstart I have
>> > created. It is pretty small so I figured why not list it here. Any help
>> is
>> > appreciated.
>> >
>> >
>> > public class Page1 extends WebPage
>> > {
>> > public Page1()
>> > {
>> > add(new ImagePanel("panel"));
>> > add(new AjaxLink("page2Link")
>> > {
>> > @Override
>> > public void onClick(AjaxRequestTarget target)
>> > {
>> > setResponsePage(Page2.class);
>> > }
>> > });
>> > }
>> > }
>> >
>> > 
>> > http://wicket.apache.org";>
>> > 
>> > 
>> > # Page 2
>> > 
>> > 
>> >
>> >
>> > public class Page2 extends WebPage
>> > {
>> > public Page2()
>> > {
>> > add(new ImagePanel("panel"));
>> > }
>> > }
>> >
>> > 
>> > http://wicket.apache.org";>
>> > 
>> > 
>> > 
>> > 
>> >
>> >
>> > public class ImagePanel extends Panel
>> > {
>> > public ImagePanel(String id)
>> > {
>> > super(id);
>> >
>> > add(new Label("dynamicImage", Model.of("Image Here:
>> > images/arrow-up-green.gif ")).setEscapeModelStrings(false));
>> > }
>> > }
>> >
>> > 
>> > http://www.w3.org/1999/xhtml";
>> > xmlns:wicket="http://wicket.apache.org/";>
>> > 
>> > Hard-Coded Image:  images/arrow-up-green.gif 
>> > Dynamic Image: 
>> > 
>> > 
>> >
>> > public class WicketApplication extends WebApplication
>> > {
>> > @Override
>> > public Class getHomePage()
>> > {
>> > return Page1.class;
>> > }
>> > @Override
>> > public void init()
>> > {
>> > super.init();
>> > setRootRequestMapper(new CryptoMapper(getRootRequestMapper(), this));
>> > }
>> > }
>> >
>> >
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> http://apache-wicket.1842946.n4.nabble.com/Image-urls-with-CryptoMapper-tp4650805.html
>> > Sent from the Users forum mailing list archive at Nabble.com.
>> >
>> > -
>> > To unsubscribe, e-mail: [hidden 
>> > email]
>> > For additional commands, e-mail: [hidden 
>> > email]
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: [hidden 
>> email]
>> For additional commands, e-mail: [hidden 
>> email]
>>
>>
>>
>> --
>>  If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://apache-wicket.1842946.n4.nabble.com/Image-urls-with-CryptoMapper-tp4650805p4650806.html
>>  To unsubscribe from Image urls with CryptoMapper, click 
>> here
>> .
>> NAML
>>
>
>
>
>
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/Image-urls-with-CryptoMapper-tp4650805p4650812.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.

Re: Image urls with CryptoMapper

2012-07-26 Thread Michael Mosmann
Ok.. i think, wicket will parse the markup and rewrites the first img tag... 
Wicket can only do this, because its allready in the markup. Whatever comes out 
of an model will NOT be parsed by wicket, so its plain html (escaping switched 
off). The second image is more like your problem as the first. And AFAIK you 
have to come up with the need of rewriting you image references to absolute 
urls or to build image tags based on your html from your backend. You have to 
parse this html from your backend if you want something which can called a 
solution. Everything else is hope that it will work.

If you want to know, how you can do this, i can help with some examples.
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.



jchappelle  schrieb:

Well, in my actual live application I don't have that option. We are
sending a query to a web service and part of the response from that web
service has these image links embedded in it. So we are using a label to
display them just as I am doing in the quickstart.

As you can see in the quickstart, there is an ImagePanel which has a
hard-coded image, which only lives in html and then a dynamic image, which
is created within a wicket label. That ImagePanel is reused on both pages.
The dynamic image on the second page shows a red x in the browser. In fact
if you look at the src attribute you will see that wicket has modified the
src attribute of the hard-coded img tag to this
"../../../images/arrow-up-green.gif" however it left the other unchanged.

Everything works if the CryptoMapper is not the root mapper.

Josh

On Thu, Jul 26, 2012 at 3:25 PM, michael mosmann [via Apache Wicket] <
ml-node+s1842946n4650810...@n4.nabble.com> wrote:

> I have some questions. How does the first img-tag on the second page
> differ from the first one? Why dont you use a wicket image component?
>
> Mm:)
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
>
>
>
> jchappelle <[hidden 
> email]>
> schrieb:
>
> I went back and edited my post. It might not have come through the mailing
> list but if you look at it from the nabble website it shows up.
>
> Josh
>
> On Thu, Jul 26, 2012 at 2:57 PM, michael mosmann [via Apache Wicket] <
> [hidden email] >
> wrote:
>
> > Are you sure, that your panel markup works? I can not see any wicket Tag
> > in it?
> > --
> > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> > gesendet.
> >
> >
> >
> > jchappelle <[hidden email]<
> http://user/SendEmail.jtp?type=node&node=4650807&i=0>>
> > schrieb:
> >
> > I'm hitting a problem with images not being found when using
> CryptoMapper.
> > I
> > have 2 pages listed below. The dynamic image on the second page does not
> > show but it does on the first page. I get to the second page by clicking
> > the
> > "Page 2" link on the first. The code below is from my quickstart I have
> > created. It is pretty small so I figured why not list it here. Any help
> is
> > appreciated.
> >
> >
> > public class Page1 extends WebPage
> > {
> > public Page1()
> > {
> > add(new ImagePanel("panel"));
> > add(new AjaxLink("page2Link")
> > {
> > @Override
> > public void onClick(AjaxRequestTarget target)
> > {
> > setResponsePage(Page2.class);
> > }
> > });
> > }
> > }
> >
> > 
> > http://wicket.apache.org";>
> > 
> > 
> > # Page 2
> > 
> > 
> >
> >
> > public class Page2 extends WebPage
> > {
> > public Page2()
> > {
> > add(new ImagePanel("panel"));
> > }
> > }
> >
> > 
> > http://wicket.apache.org";>
> > 
> > 
> > 
> > 
> >
> >
> > public class ImagePanel extends Panel
> > {
> > public ImagePanel(String id)
> > {
> > super(id);
> >
> > add(new Label("dynamicImage", Model.of("Image Here:
> > images/arrow-up-green.gif ")).setEscapeModelStrings(false));
> > }
> > }
> >
> > 
> > http://www.w3.org/1999/xhtml";
> > xmlns:wicket="http://wicket.apache.org/";>
> > 
> > Hard-Coded Image: images/arrow-up-green.gif 
> > Dynamic Image: 
> > 
> > 
> >
> > public class WicketApplication extends WebApplication
> > {
> > @Override
> > public Class getHomePage()
> > {
> > return Page1.class;
> > }
> > @Override
> > public void init()
> > {
> > super.init();
> > setRootRequestMapper(new
> > CryptoMapper(getRootRequestMapper(), this));
> > }
> > }
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> >
>



Re: Image urls with CryptoMapper

2012-07-26 Thread jchappelle
Sven,

You closed this ticket but let me say this. I'm clearly not perfectly
reproducing what I am seeing in my live app. However, what is common is
that wicket is finding the hard-coded image on the second page because it
is rewriting the url of that image and it is not doing that for the dynamic
image. I believe this is the source of my problem in my live app because
when I look at the html the same thing is happening.

Is there any advice you have on this issue?

Josh

On Thu, Jul 26, 2012 at 2:46 PM, Sven Meier [via Apache Wicket] <
ml-node+s1842946n4650806...@n4.nabble.com> wrote:

> That's hard to say from the snippet you've provided here, especially
> since a few markup tags didn't make it through.
>
> Please create an issue and attach your quickstart to it.
>
> Sven
>
> On 07/26/2012 09:31 PM, jchappelle wrote:
>
> > I'm hitting a problem with images not being found when using
> CryptoMapper. I
> > have 2 pages listed below. The dynamic image on the second page does not
> > show but it does on the first page. I get to the second page by clicking
> the
> > "Page 2" link on the first. The code below is from my quickstart I have
> > created. It is pretty small so I figured why not list it here. Any help
> is
> > appreciated.
> >
> >
> > public class Page1 extends WebPage
> > {
> > public Page1()
> > {
> > add(new ImagePanel("panel"));
> > add(new AjaxLink("page2Link")
> > {
> > @Override
> > public void onClick(AjaxRequestTarget target)
> > {
> > setResponsePage(Page2.class);
> > }
> > });
> > }
> > }
> >
> > 
> > http://wicket.apache.org";>
> > 
> > 
> > # Page 2
> > 
> > 
> >
> >
> > public class Page2 extends WebPage
> > {
> > public Page2()
> > {
> > add(new ImagePanel("panel"));
> > }
> > }
> >
> > 
> > http://wicket.apache.org";>
> > 
> > 
> > 
> > 
> >
> >
> > public class ImagePanel extends Panel
> > {
> > public ImagePanel(String id)
> > {
> > super(id);
> >
> > add(new Label("dynamicImage", Model.of("Image Here:
> > images/arrow-up-green.gif ")).setEscapeModelStrings(false));
> > }
> > }
> >
> > 
> > http://www.w3.org/1999/xhtml";
> > xmlns:wicket="http://wicket.apache.org/";>
> > 
> > Hard-Coded Image:  images/arrow-up-green.gif 
> > Dynamic Image: 
> > 
> > 
> >
> > public class WicketApplication extends WebApplication
> > {
> > @Override
> > public Class getHomePage()
> > {
> > return Page1.class;
> > }
> > @Override
> > public void init()
> > {
> > super.init();
> > setRootRequestMapper(new CryptoMapper(getRootRequestMapper(), this));
> > }
> > }
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Image-urls-with-CryptoMapper-tp4650805.html
> > Sent from the Users forum mailing list archive at Nabble.com.
> >
> > -
> > To unsubscribe, e-mail: [hidden 
> > email]
> > For additional commands, e-mail: [hidden 
> > email]
> >
>
>
> -
> To unsubscribe, e-mail: [hidden 
> email]
> For additional commands, e-mail: [hidden 
> email]
>
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://apache-wicket.1842946.n4.nabble.com/Image-urls-with-CryptoMapper-tp4650805p4650806.html
>  To unsubscribe from Image urls with CryptoMapper, click 
> here
> .
> NAML
>




--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Image-urls-with-CryptoMapper-tp4650805p4650812.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



Re: Image urls with CryptoMapper

2012-07-26 Thread jchappelle
Well, in my actual live application I don't have that option. We are
sending a query to a web service and part of the response from that web
service has these image links embedded in it. So we are using a label to
display them just as I am doing in the quickstart.

As you can see in the quickstart, there is an ImagePanel which has a
hard-coded image, which only lives in html and then a dynamic image, which
is created within a wicket label. That ImagePanel is reused on both pages.
The dynamic image on the second page shows a red x in the browser. In fact
if you look at the src attribute you will see that wicket has modified the
src attribute of the hard-coded img tag to this
"../../../images/arrow-up-green.gif" however it left the other unchanged.

Everything works if the CryptoMapper is not the root mapper.

Josh

On Thu, Jul 26, 2012 at 3:25 PM, michael mosmann [via Apache Wicket] <
ml-node+s1842946n4650810...@n4.nabble.com> wrote:

> I have some questions. How does the first img-tag on the second page
> differ from the first one? Why dont you use a wicket image component?
>
> Mm:)
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
>
>
>
> jchappelle <[hidden 
> email]>
> schrieb:
>
> I went back and edited my post. It might not have come through the mailing
> list but if you look at it from the nabble website it shows up.
>
> Josh
>
> On Thu, Jul 26, 2012 at 2:57 PM, michael mosmann [via Apache Wicket] <
> [hidden email] >
> wrote:
>
> > Are you sure, that your panel markup works? I can not see any wicket Tag
> > in it?
> > --
> > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> > gesendet.
> >
> >
> >
> > jchappelle <[hidden email]<
> http://user/SendEmail.jtp?type=node&node=4650807&i=0>>
> > schrieb:
> >
> > I'm hitting a problem with images not being found when using
> CryptoMapper.
> > I
> > have 2 pages listed below. The dynamic image on the second page does not
> > show but it does on the first page. I get to the second page by clicking
> > the
> > "Page 2" link on the first. The code below is from my quickstart I have
> > created. It is pretty small so I figured why not list it here. Any help
> is
> > appreciated.
> >
> >
> > public class Page1 extends WebPage
> > {
> > public Page1()
> > {
> > add(new ImagePanel("panel"));
> > add(new AjaxLink("page2Link")
> > {
> > @Override
> > public void onClick(AjaxRequestTarget target)
> > {
> > setResponsePage(Page2.class);
> > }
> > });
> > }
> > }
> >
> > 
> > http://wicket.apache.org";>
> > 
> > 
> > # Page 2
> > 
> > 
> >
> >
> > public class Page2 extends WebPage
> > {
> > public Page2()
> > {
> > add(new ImagePanel("panel"));
> > }
> > }
> >
> > 
> > http://wicket.apache.org";>
> > 
> > 
> > 
> > 
> >
> >
> > public class ImagePanel extends Panel
> > {
> > public ImagePanel(String id)
> > {
> > super(id);
> >
> > add(new Label("dynamicImage", Model.of("Image Here:
> > images/arrow-up-green.gif ")).setEscapeModelStrings(false));
> > }
> > }
> >
> > 
> > http://www.w3.org/1999/xhtml";
> > xmlns:wicket="http://wicket.apache.org/";>
> > 
> > Hard-Coded Image: images/arrow-up-green.gif 
> > Dynamic Image: 
> > 
> > 
> >
> > public class WicketApplication extends WebApplication
> > {
> > @Override
> > public Class getHomePage()
> > {
> > return Page1.class;
> > }
> > @Override
> > public void init()
> > {
> > super.init();
> > setRootRequestMapper(new
> > CryptoMapper(getRootRequestMapper(), this));
> > }
> > }
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://apache-wicket.1842946.n4.nabble.com/Image-urls-with-CryptoMapper-tp4650805.html
> > Sent from the Users forum mailing list archive at Nabble.com.
> >
> >_
>
> >
> > To unsubscribe, e-mail: [hidden email]<
> http://user/SendEmail.jtp?type=node&node=4650807&i=1>
> > For additional commands, e-mail: [hidden email]<
> http://user/SendEmail.jtp?type=node&node=4650807&i=2>
> >
> >
> >
> >_
>
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> >
>
> > .
> > NAML<
> http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespa
>
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://apache-wicket.1842946.n4.nabble.com/Image-urls-with-CryptoMapper-tp4650805p4650810.html
>  To unsubscribe from Image urls with CryptoMapper, click 
> here
> .
> NAML

Re: Image urls with CryptoMapper

2012-07-26 Thread Michael Mosmann
I have some questions. How does the first img-tag on the second page differ 
from the first one? Why dont you use a wicket image component?

Mm:)
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.



jchappelle  schrieb:

I went back and edited my post. It might not have come through the mailing
list but if you look at it from the nabble website it shows up.

Josh

On Thu, Jul 26, 2012 at 2:57 PM, michael mosmann [via Apache Wicket] <
ml-node+s1842946n4650807...@n4.nabble.com> wrote:

> Are you sure, that your panel markup works? I can not see any wicket Tag
> in it?
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
>
>
>
> jchappelle <[hidden 
> email]>
> schrieb:
>
> I'm hitting a problem with images not being found when using CryptoMapper.
> I
> have 2 pages listed below. The dynamic image on the second page does not
> show but it does on the first page. I get to the second page by clicking
> the
> "Page 2" link on the first. The code below is from my quickstart I have
> created. It is pretty small so I figured why not list it here. Any help is
> appreciated.
>
>
> public class Page1 extends WebPage
> {
> public Page1()
> {
> add(new ImagePanel("panel"));
> add(new AjaxLink("page2Link")
> {
> @Override
> public void onClick(AjaxRequestTarget target)
> {
> setResponsePage(Page2.class);
> }
> });
> }
> }
>
> 
> http://wicket.apache.org";>
> 
> 
> # Page 2
> 
> 
>
>
> public class Page2 extends WebPage
> {
> public Page2()
> {
> add(new ImagePanel("panel"));
> }
> }
>
> 
> http://wicket.apache.org";>
> 
> 
> 
> 
>
>
> public class ImagePanel extends Panel
> {
> public ImagePanel(String id)
> {
> super(id);
>
> add(new Label("dynamicImage", Model.of("Image Here:
> images/arrow-up-green.gif ")).setEscapeModelStrings(false));
> }
> }
>
> 
> http://www.w3.org/1999/xhtml";
> xmlns:wicket="http://wicket.apache.org/";>
> 
> Hard-Coded Image: images/arrow-up-green.gif 
> Dynamic Image: 
> 
> 
>
> public class WicketApplication extends WebApplication
> {
> @Override
> public Class getHomePage()
> {
> return Page1.class;
> }
> @Override
> public void init()
> {
> super.init();
> setRootRequestMapper(new
> CryptoMapper(getRootRequestMapper(), this));
> }
> }
>
>
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Image-urls-with-CryptoMapper-tp4650805.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
>_

>
> To unsubscribe, e-mail: [hidden 
> email]
> For additional commands, e-mail: [hidden 
> email]
>
>
>
>_

> If you reply to this email, your message will be added to the discussion
> below:
>
> http://apache-wicket.1842946.n4.nabble.com/Image-urls-with-CryptoMapper-tp4650805p4650807.html
> To unsubscribe from Image urls with CryptoMapper, click 
> here;
> .
> NAML

Re: Image urls with CryptoMapper

2012-07-26 Thread jchappelle
Issue created.

https://issues.apache.org/jira/browse/WICKET-4678
https://issues.apache.org/jira/browse/WICKET-4678 



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Image-urls-with-CryptoMapper-tp4650805p4650809.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



Re: Image urls with CryptoMapper

2012-07-26 Thread jchappelle
I went back and edited my post. It might not have come through the mailing
list but if you look at it from the nabble website it shows up.

Josh

On Thu, Jul 26, 2012 at 2:57 PM, michael mosmann [via Apache Wicket] <
ml-node+s1842946n4650807...@n4.nabble.com> wrote:

> Are you sure, that your panel markup works? I can not see any wicket Tag
> in it?
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
>
>
>
> jchappelle <[hidden 
> email]>
> schrieb:
>
> I'm hitting a problem with images not being found when using CryptoMapper.
> I
> have 2 pages listed below. The dynamic image on the second page does not
> show but it does on the first page. I get to the second page by clicking
> the
> "Page 2" link on the first. The code below is from my quickstart I have
> created. It is pretty small so I figured why not list it here. Any help is
> appreciated.
>
>
> public class Page1 extends WebPage
> {
> public Page1()
> {
> add(new ImagePanel("panel"));
> add(new AjaxLink("page2Link")
> {
> @Override
> public void onClick(AjaxRequestTarget target)
> {
> setResponsePage(Page2.class);
> }
> });
> }
> }
>
> 
> http://wicket.apache.org";>
> 
> 
>  # Page 2
> 
> 
>
>
> public class Page2 extends WebPage
> {
> public Page2()
> {
> add(new ImagePanel("panel"));
> }
> }
>
> 
> http://wicket.apache.org";>
> 
> 
> 
> 
>
>
> public class ImagePanel extends Panel
> {
> public ImagePanel(String id)
> {
> super(id);
>
> add(new Label("dynamicImage", Model.of("Image Here:
> images/arrow-up-green.gif ")).setEscapeModelStrings(false));
> }
> }
>
> 
> http://www.w3.org/1999/xhtml";
> xmlns:wicket="http://wicket.apache.org/";>
> 
> Hard-Coded Image: images/arrow-up-green.gif 
> Dynamic Image: 
> 
> 
>
> public class WicketApplication extends WebApplication
> {
> @Override
> public Class getHomePage()
> {
> return Page1.class;
> }
> @Override
> public void init()
> {
> super.init();
> setRootRequestMapper(new
> CryptoMapper(getRootRequestMapper(), this));
> }
> }
>
>
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Image-urls-with-CryptoMapper-tp4650805.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> _
>
> To unsubscribe, e-mail: [hidden 
> email]
> For additional commands, e-mail: [hidden 
> email]
>
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://apache-wicket.1842946.n4.nabble.com/Image-urls-with-CryptoMapper-tp4650805p4650807.html
>  To unsubscribe from Image urls with CryptoMapper, click 
> here
> .
> NAML
>




--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Image-urls-with-CryptoMapper-tp4650805p4650808.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



Re: Image urls with CryptoMapper

2012-07-26 Thread Sven Meier
That's hard to say from the snippet you've provided here, especially 
since a few markup tags didn't make it through.


Please create an issue and attach your quickstart to it.

Sven

On 07/26/2012 09:31 PM, jchappelle wrote:

I'm hitting a problem with images not being found when using CryptoMapper. I
have 2 pages listed below. The dynamic image on the second page does not
show but it does on the first page. I get to the second page by clicking the
"Page 2" link on the first. The code below is from my quickstart I have
created. It is pretty small so I figured why not list it here. Any help is
appreciated.


public class Page1 extends WebPage
{
public Page1()
{
add(new ImagePanel("panel"));
add(new AjaxLink("page2Link")
{
@Override
public void onClick(AjaxRequestTarget target)
{
setResponsePage(Page2.class);
}
});
}
}


http://wicket.apache.org";>


 # Page 2




public class Page2 extends WebPage
{
public Page2()
{
add(new ImagePanel("panel"));
}
}


http://wicket.apache.org";>






public class ImagePanel extends Panel
{
public ImagePanel(String id)
{
super(id);

add(new Label("dynamicImage", Model.of("Image Here:
images/arrow-up-green.gif ")).setEscapeModelStrings(false));
}
}


http://www.w3.org/1999/xhtml";
xmlns:wicket="http://wicket.apache.org/";>

Hard-Coded Image:  images/arrow-up-green.gif 
Dynamic Image: 



public class WicketApplication extends WebApplication
{   
@Override
public Class getHomePage()
{
return Page1.class;
}
@Override
public void init()
{
super.init();
setRootRequestMapper(new CryptoMapper(getRootRequestMapper(), 
this));
}
}





--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Image-urls-with-CryptoMapper-tp4650805.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: renderHead() / wicket:head page / component order

2012-07-26 Thread Martin Grigorov
On Thu, Jul 26, 2012 at 8:26 PM, Pierre Goiffon
 wrote:
> Le 26/07/2012 10:29, Emond Papegaaij a écrit :
>> Hi Pierre,
>
> Hi Edmond, thanks for your answer !
>
>> First of all, I strongly recommend you do not use a different
>> HeaderRenderStrategy.
>
> Yes, Martin made it very clear that ParentFirstHeaderRenderStrategy is
> deprecated.
>
>> Second, I suggest you use Wicket 6, because consistent resource ordering in
>> Wicket 1.5 is nearly impossible.
>
> Reading this made me smile : we use Wicket for a while now, and
> upgrading major versions was almost always painfull. The most difficult
> time we add was with the migration to 1.5... So I don't think just a few
> week after fixing our first version using Wicket 1.5 and still having to
> deal with bugs related to the migration, my team would agreed to upgrade
> to Wicket 6, that is still in beta stage :)
>
> For now on we dealt with the resource order problem mainly using a
> custom implementation of AbstractResourceDependentResourceReference.
>
>> HeaderResponseTest in Wicket 6 gives a good demonstration of the order of
>> resources. It shows that normal resources are rendered child-first, starting
>> at the root of the class inheritance hierarchy. If you change nothing, the
>> order will be B, C, A (A is last, because its header contribution is via
>> renderHead). To move A to the front, you wrap it in a PriorityHeaderItem, and
>> you should be done.
>
> Where can I find this HeaderResponseTest class ? I don't have it in the
> wicket-core 6.0.0-beta3 avalaible via Maven ?
> Is it this one :
> http://svn.apache.org/repos/asf/wicket/trunk/wicket-core/src/test/java/org/apache/wicket/markup/html/internal/HeaderResponseTest.java
>
> In Wicket 1.5 if I do nothing, resources contributed in renderHead()
> would be rendered in this order : C, B, A.
> I'm surprised the order would be B, C, A in Wicket 6 ? Why so ?
>
> In my exemple I need to define 2 priorities, because the css that was in
> the B page wicket:head needs to be before the one in page C, and the css
> linked in page A must be the first resource to be rendered. Could
> PriorityHeaderItem answer this need ?
>
>> In Wicket 6, all headers are
>> rendered child-first, except PriorityHeaderItems, which are rendered parent-
>> first.
>
> I see that in the PriorityHeaderItem Javadoc. Does that means if I add a
> PriorityHeaderItem in page A, and another in page B, the one in page A
> (parent page) will be rendered before page B (child page) ?
>
>
> Another question : can you confirm me there are no equivalent in Wicket
> 1.5 for the Wicket 6 CssContentHeaderItem ? Said otherwise, in Wicket
> 1.5 can I serve content in java directly in the head ? I don't want
> every css contributions to be added with link tags and makes the
> browsers do one more download...

https://github.com/apache/wicket/blob/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/markup/html/internal/HeaderResponse.java#L59

> -
> 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



Re: renderHead() / wicket:head page / component order

2012-07-26 Thread Pierre Goiffon
Le 26/07/2012 10:29, Emond Papegaaij a écrit :
> Hi Pierre,

Hi Edmond, thanks for your answer !

> First of all, I strongly recommend you do not use a different
> HeaderRenderStrategy.

Yes, Martin made it very clear that ParentFirstHeaderRenderStrategy is 
deprecated.

> Second, I suggest you use Wicket 6, because consistent resource ordering in
> Wicket 1.5 is nearly impossible.

Reading this made me smile : we use Wicket for a while now, and 
upgrading major versions was almost always painfull. The most difficult 
time we add was with the migration to 1.5... So I don't think just a few 
week after fixing our first version using Wicket 1.5 and still having to 
deal with bugs related to the migration, my team would agreed to upgrade 
to Wicket 6, that is still in beta stage :)

For now on we dealt with the resource order problem mainly using a 
custom implementation of AbstractResourceDependentResourceReference.

> HeaderResponseTest in Wicket 6 gives a good demonstration of the order of
> resources. It shows that normal resources are rendered child-first, starting
> at the root of the class inheritance hierarchy. If you change nothing, the
> order will be B, C, A (A is last, because its header contribution is via
> renderHead). To move A to the front, you wrap it in a PriorityHeaderItem, and
> you should be done.

Where can I find this HeaderResponseTest class ? I don't have it in the 
wicket-core 6.0.0-beta3 avalaible via Maven ?
Is it this one :
http://svn.apache.org/repos/asf/wicket/trunk/wicket-core/src/test/java/org/apache/wicket/markup/html/internal/HeaderResponseTest.java

In Wicket 1.5 if I do nothing, resources contributed in renderHead() 
would be rendered in this order : C, B, A.
I'm surprised the order would be B, C, A in Wicket 6 ? Why so ?

In my exemple I need to define 2 priorities, because the css that was in 
the B page wicket:head needs to be before the one in page C, and the css 
linked in page A must be the first resource to be rendered. Could 
PriorityHeaderItem answer this need ?

> In Wicket 6, all headers are
> rendered child-first, except PriorityHeaderItems, which are rendered parent-
> first.

I see that in the PriorityHeaderItem Javadoc. Does that means if I add a 
PriorityHeaderItem in page A, and another in page B, the one in page A 
(parent page) will be rendered before page B (child page) ?


Another question : can you confirm me there are no equivalent in Wicket 
1.5 for the Wicket 6 CssContentHeaderItem ? Said otherwise, in Wicket 
1.5 can I serve content in java directly in the head ? I don't want 
every css contributions to be added with link tags and makes the 
browsers do one more download...
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Ajax Timeouts

2012-07-26 Thread Richard W. Adams
Great! That means I don't have to waste time tracking down non-existent 
timeouts & can focus elsewhere. Thanks for the quick feedback.



From:   Martin Grigorov 
To: users@wicket.apache.org
Date:   07/26/2012 09:56 AM
Subject:Re: Ajax Timeouts



On Thu, Jul 26, 2012 at 5:50 PM, Richard W. Adams  wrote:
> Yes, it is my code. My server code will eventually reply.  What I can't
> control is how long a database operation will take. Typically the 
database
> work finishes  under 10 seconds, but sometimes can run up to a minute or
> longer.
>
> If I understand you correctly, even if takes 5 minutes (an extreme
> example), the client will still patiently wait until it gest the reply,
> correct? To say it another way: As long as the server code eventually
> replies (in less than the session timeout, which is currently 60 
minutes,
> I think), the client will still get the reply. Is that accurate?  If so,
> then my problem is probably something other than an Ajax timeout.

Yes, the Ajax call will wait. In that timeframe no other request can
access the same page instance too.

Wicket 6 supports Ajax call timeout by
org.apache.wicket.ajax.attributes.AjaxRequestAttributes#setRequestTimeout().
It just delegates to jQuery#ajax()'s timeout mechanism. I haven't
tried it with your use case though.

>
>
>
>
> From:   Martin Grigorov 
> To: users@wicket.apache.org
> Date:   07/26/2012 09:41 AM
> Subject:Re: Ajax Timeouts
>
>
>
> On Thu, Jul 26, 2012 at 5:35 PM, Richard W. Adams  
wrote:
>> So once the client request gets access to the page instance, it will
> wait
>> forever for a reply?
>
> this is your code, no ?
>
> once the Ajax call gets access to the page Wicket executes
> onEvent(AjaxRequestTarget). Here it is your job to not block forever
>
>>
>>
>>
>>
>> From:   Martin Grigorov 
>> To: users@wicket.apache.org
>> Date:   07/26/2012 09:27 AM
>> Subject:Re: Ajax Timeouts
>>
>>
>>
>> Hi,
>>
>> The timeout is to get access to the page instance. It is for both Ajax
>> and normal requests.
>> See org.apache.wicket.settings.IRequestCycleSettings#getTimeout
>>
>> You must have some exceptions in the logs if this is the reason.
>>
>> But even if Ajax request fails to get access to the page then it will
>> end by calling its failure handler.
>>
>> On Wed, Jul 25, 2012 at 7:50 PM, Richard W. Adams 
> wrote:
>>> My Wicket app occasionally "freezes" on making an Ajax submit that
>> invokes
>>> a potentially lengthy database operation. My theory is that the
> database
>>> work is taking longer than Wicket allows, & the Ajax call times out.
> I'm
>>> guessing that the browser does not detect this timeout, so my "Please
>>> Wait" message continues to be displayed, making the user think he will
>>> eventually get an answer from the server. However, in these cases, no
>>> matter long he waits (up to many minutes), no reply is ever
> forthcoming.
>>>
>>> Before I invest a lot of time trying to FIX this problem, is there a
> way
>>> to determine that an Ajax timeout actually IS the problem? Also, does
>>> anyone know what Wicket's default Ajax timeout interval is?
>>>
>>> I looked over the Javadocs for the various Wicket Ajax classes, but
> none
>>> of them seemed to address this particular issue. Any advice or 
pointers
>>> would be greatly appreciated!
>>>
>>>
>>>
>>>
>>>
>>> **
>>>
>>> This email and any attachments may contain information that is
>> confidential and/or privileged for the sole use of the intended
> recipient.
>>  Any use, review, disclosure, copying, distribution or reliance by
> others,
>> and any forwarding of this email or its contents, without the express
>> permission of the sender is strictly prohibited by law.  If you are not
>> the intended recipient, please contact the sender immediately, delete
> the
>> e-mail and destroy all copies.
>>> **
>>
>>
>>
>> --
>> 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
>>
>>
>>
>>
>> **
>>
>> This email and any attachments may contain information that is
> confidential and/or privileged for the sole use of the intended 
recipient.
>  Any use, review, disclosure, copying, distribution or reliance by 
others,
> and any forwarding of this email or its contents, without the express
> permission of the sender is strictly prohibited by law.  If you are not
> the intended recipient, please contact the sender immediately, delete 
the
> e-mail and destroy all copies.
>> **
>
>
>
> --
> 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
>
>
>
>
> **
>
> This email and any a

Re: Ajax Timeouts

2012-07-26 Thread Martin Grigorov
On Thu, Jul 26, 2012 at 5:50 PM, Richard W. Adams  wrote:
> Yes, it is my code. My server code will eventually reply.  What I can't
> control is how long a database operation will take. Typically the database
> work finishes  under 10 seconds, but sometimes can run up to a minute or
> longer.
>
> If I understand you correctly, even if takes 5 minutes (an extreme
> example), the client will still patiently wait until it gest the reply,
> correct? To say it another way: As long as the server code eventually
> replies (in less than the session timeout, which is currently 60 minutes,
> I think), the client will still get the reply. Is that accurate?  If so,
> then my problem is probably something other than an Ajax timeout.

Yes, the Ajax call will wait. In that timeframe no other request can
access the same page instance too.

Wicket 6 supports Ajax call timeout by
org.apache.wicket.ajax.attributes.AjaxRequestAttributes#setRequestTimeout().
It just delegates to jQuery#ajax()'s timeout mechanism. I haven't
tried it with your use case though.

>
>
>
>
> From:   Martin Grigorov 
> To: users@wicket.apache.org
> Date:   07/26/2012 09:41 AM
> Subject:Re: Ajax Timeouts
>
>
>
> On Thu, Jul 26, 2012 at 5:35 PM, Richard W. Adams  wrote:
>> So once the client request gets access to the page instance, it will
> wait
>> forever for a reply?
>
> this is your code, no ?
>
> once the Ajax call gets access to the page Wicket executes
> onEvent(AjaxRequestTarget). Here it is your job to not block forever
>
>>
>>
>>
>>
>> From:   Martin Grigorov 
>> To: users@wicket.apache.org
>> Date:   07/26/2012 09:27 AM
>> Subject:Re: Ajax Timeouts
>>
>>
>>
>> Hi,
>>
>> The timeout is to get access to the page instance. It is for both Ajax
>> and normal requests.
>> See org.apache.wicket.settings.IRequestCycleSettings#getTimeout
>>
>> You must have some exceptions in the logs if this is the reason.
>>
>> But even if Ajax request fails to get access to the page then it will
>> end by calling its failure handler.
>>
>> On Wed, Jul 25, 2012 at 7:50 PM, Richard W. Adams 
> wrote:
>>> My Wicket app occasionally "freezes" on making an Ajax submit that
>> invokes
>>> a potentially lengthy database operation. My theory is that the
> database
>>> work is taking longer than Wicket allows, & the Ajax call times out.
> I'm
>>> guessing that the browser does not detect this timeout, so my "Please
>>> Wait" message continues to be displayed, making the user think he will
>>> eventually get an answer from the server. However, in these cases, no
>>> matter long he waits (up to many minutes), no reply is ever
> forthcoming.
>>>
>>> Before I invest a lot of time trying to FIX this problem, is there a
> way
>>> to determine that an Ajax timeout actually IS the problem? Also, does
>>> anyone know what Wicket's default Ajax timeout interval is?
>>>
>>> I looked over the Javadocs for the various Wicket Ajax classes, but
> none
>>> of them seemed to address this particular issue. Any advice or pointers
>>> would be greatly appreciated!
>>>
>>>
>>>
>>>
>>>
>>> **
>>>
>>> This email and any attachments may contain information that is
>> confidential and/or privileged for the sole use of the intended
> recipient.
>>  Any use, review, disclosure, copying, distribution or reliance by
> others,
>> and any forwarding of this email or its contents, without the express
>> permission of the sender is strictly prohibited by law.  If you are not
>> the intended recipient, please contact the sender immediately, delete
> the
>> e-mail and destroy all copies.
>>> **
>>
>>
>>
>> --
>> 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
>>
>>
>>
>>
>> **
>>
>> This email and any attachments may contain information that is
> confidential and/or privileged for the sole use of the intended recipient.
>  Any use, review, disclosure, copying, distribution or reliance by others,
> and any forwarding of this email or its contents, without the express
> permission of the sender is strictly prohibited by law.  If you are not
> the intended recipient, please contact the sender immediately, delete the
> e-mail and destroy all copies.
>> **
>
>
>
> --
> 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
>
>
>
>
> **
>
> This email and any attachments may contain information that is confidential 
> and/or privileged for the sole use of the intended recipient.  Any use, 
> review, disclosure, copying, distribution or reliance by others, and any 
> forwarding of this email or its contents, without the expr

Re: Ajax Timeouts

2012-07-26 Thread Richard W. Adams
Yes, it is my code. My server code will eventually reply.  What I can't 
control is how long a database operation will take. Typically the database 
work finishes  under 10 seconds, but sometimes can run up to a minute or 
longer. 

If I understand you correctly, even if takes 5 minutes (an extreme 
example), the client will still patiently wait until it gest the reply, 
correct? To say it another way: As long as the server code eventually 
replies (in less than the session timeout, which is currently 60 minutes, 
I think), the client will still get the reply. Is that accurate?  If so, 
then my problem is probably something other than an Ajax timeout.




From:   Martin Grigorov 
To: users@wicket.apache.org
Date:   07/26/2012 09:41 AM
Subject:Re: Ajax Timeouts



On Thu, Jul 26, 2012 at 5:35 PM, Richard W. Adams  wrote:
> So once the client request gets access to the page instance, it will 
wait
> forever for a reply?

this is your code, no ?

once the Ajax call gets access to the page Wicket executes
onEvent(AjaxRequestTarget). Here it is your job to not block forever

>
>
>
>
> From:   Martin Grigorov 
> To: users@wicket.apache.org
> Date:   07/26/2012 09:27 AM
> Subject:Re: Ajax Timeouts
>
>
>
> Hi,
>
> The timeout is to get access to the page instance. It is for both Ajax
> and normal requests.
> See org.apache.wicket.settings.IRequestCycleSettings#getTimeout
>
> You must have some exceptions in the logs if this is the reason.
>
> But even if Ajax request fails to get access to the page then it will
> end by calling its failure handler.
>
> On Wed, Jul 25, 2012 at 7:50 PM, Richard W. Adams  
wrote:
>> My Wicket app occasionally "freezes" on making an Ajax submit that
> invokes
>> a potentially lengthy database operation. My theory is that the 
database
>> work is taking longer than Wicket allows, & the Ajax call times out. 
I'm
>> guessing that the browser does not detect this timeout, so my "Please
>> Wait" message continues to be displayed, making the user think he will
>> eventually get an answer from the server. However, in these cases, no
>> matter long he waits (up to many minutes), no reply is ever 
forthcoming.
>>
>> Before I invest a lot of time trying to FIX this problem, is there a 
way
>> to determine that an Ajax timeout actually IS the problem? Also, does
>> anyone know what Wicket's default Ajax timeout interval is?
>>
>> I looked over the Javadocs for the various Wicket Ajax classes, but 
none
>> of them seemed to address this particular issue. Any advice or pointers
>> would be greatly appreciated!
>>
>>
>>
>>
>>
>> **
>>
>> This email and any attachments may contain information that is
> confidential and/or privileged for the sole use of the intended 
recipient.
>  Any use, review, disclosure, copying, distribution or reliance by 
others,
> and any forwarding of this email or its contents, without the express
> permission of the sender is strictly prohibited by law.  If you are not
> the intended recipient, please contact the sender immediately, delete 
the
> e-mail and destroy all copies.
>> **
>
>
>
> --
> 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
>
>
>
>
> **
>
> This email and any attachments may contain information that is 
confidential and/or privileged for the sole use of the intended recipient. 
 Any use, review, disclosure, copying, distribution or reliance by others, 
and any forwarding of this email or its contents, without the express 
permission of the sender is strictly prohibited by law.  If you are not 
the intended recipient, please contact the sender immediately, delete the 
e-mail and destroy all copies.
> **



-- 
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




**

This email and any attachments may contain information that is confidential 
and/or privileged for the sole use of the intended recipient.  Any use, review, 
disclosure, copying, distribution or reliance by others, and any forwarding of 
this email or its contents, without the express permission of the sender is 
strictly prohibited by law.  If you are not the intended recipient, please 
contact the sender immediately, delete the e-mail and destroy all copies.
**


Re: Ajax Timeouts

2012-07-26 Thread Martin Grigorov
On Thu, Jul 26, 2012 at 5:35 PM, Richard W. Adams  wrote:
> So once the client request gets access to the page instance, it will wait
> forever for a reply?

this is your code, no ?

once the Ajax call gets access to the page Wicket executes
onEvent(AjaxRequestTarget). Here it is your job to not block forever

>
>
>
>
> From:   Martin Grigorov 
> To: users@wicket.apache.org
> Date:   07/26/2012 09:27 AM
> Subject:Re: Ajax Timeouts
>
>
>
> Hi,
>
> The timeout is to get access to the page instance. It is for both Ajax
> and normal requests.
> See org.apache.wicket.settings.IRequestCycleSettings#getTimeout
>
> You must have some exceptions in the logs if this is the reason.
>
> But even if Ajax request fails to get access to the page then it will
> end by calling its failure handler.
>
> On Wed, Jul 25, 2012 at 7:50 PM, Richard W. Adams  wrote:
>> My Wicket app occasionally "freezes" on making an Ajax submit that
> invokes
>> a potentially lengthy database operation. My theory is that the database
>> work is taking longer than Wicket allows, & the Ajax call times out. I'm
>> guessing that the browser does not detect this timeout, so my "Please
>> Wait" message continues to be displayed, making the user think he will
>> eventually get an answer from the server. However, in these cases, no
>> matter long he waits (up to many minutes), no reply is ever forthcoming.
>>
>> Before I invest a lot of time trying to FIX this problem, is there a way
>> to determine that an Ajax timeout actually IS the problem? Also, does
>> anyone know what Wicket's default Ajax timeout interval is?
>>
>> I looked over the Javadocs for the various Wicket Ajax classes, but none
>> of them seemed to address this particular issue. Any advice or pointers
>> would be greatly appreciated!
>>
>>
>>
>>
>>
>> **
>>
>> This email and any attachments may contain information that is
> confidential and/or privileged for the sole use of the intended recipient.
>  Any use, review, disclosure, copying, distribution or reliance by others,
> and any forwarding of this email or its contents, without the express
> permission of the sender is strictly prohibited by law.  If you are not
> the intended recipient, please contact the sender immediately, delete the
> e-mail and destroy all copies.
>> **
>
>
>
> --
> 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
>
>
>
>
> **
>
> This email and any attachments may contain information that is confidential 
> and/or privileged for the sole use of the intended recipient.  Any use, 
> review, disclosure, copying, distribution or reliance by others, and any 
> forwarding of this email or its contents, without the express permission of 
> the sender is strictly prohibited by law.  If you are not the intended 
> recipient, please contact the sender immediately, delete the e-mail and 
> destroy all copies.
> **



-- 
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



Re: Ajax Timeouts

2012-07-26 Thread Richard W. Adams
So once the client request gets access to the page instance, it will wait 
forever for a reply?




From:   Martin Grigorov 
To: users@wicket.apache.org
Date:   07/26/2012 09:27 AM
Subject:Re: Ajax Timeouts



Hi,

The timeout is to get access to the page instance. It is for both Ajax
and normal requests.
See org.apache.wicket.settings.IRequestCycleSettings#getTimeout

You must have some exceptions in the logs if this is the reason.

But even if Ajax request fails to get access to the page then it will
end by calling its failure handler.

On Wed, Jul 25, 2012 at 7:50 PM, Richard W. Adams  wrote:
> My Wicket app occasionally "freezes" on making an Ajax submit that 
invokes
> a potentially lengthy database operation. My theory is that the database
> work is taking longer than Wicket allows, & the Ajax call times out. I'm
> guessing that the browser does not detect this timeout, so my "Please
> Wait" message continues to be displayed, making the user think he will
> eventually get an answer from the server. However, in these cases, no
> matter long he waits (up to many minutes), no reply is ever forthcoming.
>
> Before I invest a lot of time trying to FIX this problem, is there a way
> to determine that an Ajax timeout actually IS the problem? Also, does
> anyone know what Wicket's default Ajax timeout interval is?
>
> I looked over the Javadocs for the various Wicket Ajax classes, but none
> of them seemed to address this particular issue. Any advice or pointers
> would be greatly appreciated!
>
>
>
>
>
> **
>
> This email and any attachments may contain information that is 
confidential and/or privileged for the sole use of the intended recipient. 
 Any use, review, disclosure, copying, distribution or reliance by others, 
and any forwarding of this email or its contents, without the express 
permission of the sender is strictly prohibited by law.  If you are not 
the intended recipient, please contact the sender immediately, delete the 
e-mail and destroy all copies.
> **



-- 
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




**

This email and any attachments may contain information that is confidential 
and/or privileged for the sole use of the intended recipient.  Any use, review, 
disclosure, copying, distribution or reliance by others, and any forwarding of 
this email or its contents, without the express permission of the sender is 
strictly prohibited by law.  If you are not the intended recipient, please 
contact the sender immediately, delete the e-mail and destroy all copies.
**


Re: Ajax Timeouts

2012-07-26 Thread Martin Grigorov
Hi,

The timeout is to get access to the page instance. It is for both Ajax
and normal requests.
See org.apache.wicket.settings.IRequestCycleSettings#getTimeout

You must have some exceptions in the logs if this is the reason.

But even if Ajax request fails to get access to the page then it will
end by calling its failure handler.

On Wed, Jul 25, 2012 at 7:50 PM, Richard W. Adams  wrote:
> My Wicket app occasionally "freezes" on making an Ajax submit that invokes
> a potentially lengthy database operation. My theory is that the database
> work is taking longer than Wicket allows, & the Ajax call times out. I'm
> guessing that the browser does not detect this timeout, so my "Please
> Wait" message continues to be displayed, making the user think he will
> eventually get an answer from the server. However, in these cases, no
> matter long he waits (up to many minutes), no reply is ever forthcoming.
>
> Before I invest a lot of time trying to FIX this problem, is there a way
> to determine that an Ajax timeout actually IS the problem? Also, does
> anyone know what Wicket's default Ajax timeout interval is?
>
> I looked over the Javadocs for the various Wicket Ajax classes, but none
> of them seemed to address this particular issue. Any advice or pointers
> would be greatly appreciated!
>
>
>
>
>
> **
>
> This email and any attachments may contain information that is confidential 
> and/or privileged for the sole use of the intended recipient.  Any use, 
> review, disclosure, copying, distribution or reliance by others, and any 
> forwarding of this email or its contents, without the express permission of 
> the sender is strictly prohibited by law.  If you are not the intended 
> recipient, please contact the sender immediately, delete the e-mail and 
> destroy all copies.
> **



-- 
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



Re: I think it's time for a new book.... Igor and Co ?

2012-07-26 Thread Martin Grigorov
On Thu, Jul 26, 2012 at 10:08 AM, mlabs  wrote:
> I'm all for improving the javadocs... oh yes... but in my experience with
> javadocs, the context is too limited.. to the class or interface in
> question.. there is rarely the more important 'bigger picture' information
> that you need as a developer diving into something new...
> Wicket is a fantastic framework .. it encapsulates so much ... but in doing
> that, it hides so much...
> I have been using tit for a couple of years now...
> The initial learning path is easy .. (by design)
> But we eventually need to step outside of the box... and that's where the
> encapsulation bites most of us...
> Ajax... jQuery... Response cycles, page caching.
> We need to know how it all works and yes we have the source code... but...
> Back to my initial request...
>
> Wicket Internals... 
>
> :)

Seeing how the previous book authors became less active after writing
a book I think this is not a very good idea... :-/

Here is what I suggest: create a page in Wiki that lists the more
interesting topics. Then we (the people who know more about Wicket
internals) will try to fill the gaps by creating a separate Wiki page
for each topic, slowly, one at a time, without the pressure of the
publishers, etc. This way hopefully the community can help too by
keeping them up-to-date.

P.S. I still wait for your javadoc Pull Requests.

>
>
>
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/I-think-it-s-time-for-a-new-book-Igor-and-Co-tp4650687p4650787.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
>



-- 
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



Re: renderHead() / wicket:head page / component order

2012-07-26 Thread Emond Papegaaij
Hi Pierre,

First of all, I strongly recommend you do not use a different 
HeaderRenderStrategy. It is likely to get removed in future versions of Wicket 
and might break libraries that depend on the normal HeaderRenderStrategy. 
Second, I suggest you use Wicket 6, because consistent resource ordering in 
Wicket 1.5 is nearly impossible.

HeaderResponseTest in Wicket 6 gives a good demonstration of the order of 
resources. It shows that normal resources are rendered child-first, starting 
at the root of the class inheritance hierarchy. If you change nothing, the 
order will be B, C, A (A is last, because its header contribution is via 
renderHead). To move A to the front, you wrap it in a PriorityHeaderItem, and 
you should be done.

On Tuesday 24 July 2012 16:24:59 Pierre Goiffon wrote:
> > The order is now consistent - no matter if you contribute the CSS via
> > markup ( or ) or via code (in .java).
> 
> I didn't understand your statement ? Particularly "the order is now
> consistent".
> 
> My problem was originally about the delivery order of wicket:head
> contributions that was changed in wicket 1.5.
> Reading your statement I understand wicket:head do still render parent
> first in Wicket 1.5 but in Wicket 6 renders child first, like the other
> Java way (renderHead() right ?), so I guess I don't understand well what
> you wrote ?

In Wicket 1.5, different contributions to the header render in different ways 
and the order may not be what you'd expect it to be. The intention was to 
render child-first, but that proved difficult to implement, therefore header 
rendering has undergone major refactoring in 6. In Wicket 6, all headers are 
rendered child-first, except PriorityHeaderItems, which are rendered parent-
first.

> > Wicket defines two simple rules:
> > 1) component-first contribution - if you use a library that provides
> > Wicket components (e.g. WiQuery) then the components will contribute
> > first and then your page. This way you have the last word what CSS
> > rules to apply. I.e. you can override WiQuery's default CSS rules.
> > 2) child-component contributes after its parent - when you use
> > #renderHead(IHeaderResponse) you are in control to call
> > super.renderHead() at the top  of the method body or at the bottom.
> > Most of the time developers put it at the top. You don't have the
> > control for that for  though. Here Wicket contributes
> > first the parent's markup and then the child's one.

I'm not sure how this is in Wicket 1.5, but for Wicket 6, the second point is 
not correct. Moving the call to super.renderHead to the end of the method only 
changes the order between super- and subclass header items (the items for the 
superclass are inserted at the location of the super call).  is 
rendered child-first (not parent first), just as all other header items.

Best regards,
Emond

Resent my mail, because the first one seem to have gotten lost somewhere.

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



how to get dropdownlist selected value

2012-07-26 Thread lxw_first
http://apache-wicket.1842946.n4.nabble.com/file/n4650788/aaa.bmp 

html:





code
final ListView trView=new ListView("tritems", new PropertyModel(this,
"attrBizRoles")) {
private IBizRole attrvalueBizRole=new BizRole();

@Override
protected void populateItem(ListItem item) {
attrBizRole = (IBizRole) item.getModelObject();
item.add(new Label("lblattr", attrBizRole.getName()));
// this list can get from attr
attrvalueBizRoles = (List) 
attrBizRole.getChildBizRole();
if (attrvalueBizRoles.size()>0) {
attrvalueBizRole=attrvalueBizRoles.get(0);
}
DropDownChoice attrvalueChoice = new 
DropDownChoice("attrvalue",new
PropertyModel(this, "attrvalueBizRole"), attrvalueBizRoles,new
IChoiceRenderer() {

@Override
public Object getDisplayValue(Object object) {
attrvalueBizRole = (IBizRole) object;
return attrvalueBizRole.getName();
}

@Override
public String getIdValue(Object object, int index) {
attrvalueBizRole = (IBizRole) object;
return String.valueOf(attrvalueBizRole.getId());
}
});
item.add(attrvalueChoice);
}
};

i want to get the dropdownlist selected value.how to get value?
Can anyone tell me how to achieve this. 
Thanks



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/how-to-get-dropdownlist-selected-value-tp4650788.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



RE: I think it's time for a new book.... Igor and Co ?

2012-07-26 Thread mlabs
I'm all for improving the javadocs... oh yes... but in my experience with
javadocs, the context is too limited.. to the class or interface in
question.. there is rarely the more important 'bigger picture' information
that you need as a developer diving into something new... 
Wicket is a fantastic framework .. it encapsulates so much ... but in doing
that, it hides so much... 
I have been using tit for a couple of years now...
The initial learning path is easy .. (by design)
But we eventually need to step outside of the box... and that's where the
encapsulation bites most of us...
Ajax... jQuery... Response cycles, page caching.
We need to know how it all works and yes we have the source code... but... 
Back to my initial request...

Wicket Internals... 

:)



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/I-think-it-s-time-for-a-new-book-Igor-and-Co-tp4650687p4650787.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



Re: getChoices from ListMultipleChoice

2012-07-26 Thread cosmindumy
Thanks
It helped me. But just another problem. 
I have a customized multiple choice with 2 multiple ListMultipleChoice
inside. and movieng selected choices from each other. 

I have problems with safe cast. 

Here is my class definition: 
public class CusomizedMultipleChoice extends Panel 

Here are the two method I used.

Collection leftChoices = leftChoice.getChoices();
Collection selectedLeftChoices = leftChoice.getModelObject();

The compiler complains at first method. getChoices. Shouldn't return return
a collection of T.  compiler ask me to cast at Collection. Is it safe to
do this?
I checked the wicket sources but couldn't find the cause. 
Is anything wrong?
Thanks. 




--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/getChoices-from-ListMultipleChoice-tp4650725p4650789.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



Re: renderHead() / wicket:head page / component order

2012-07-26 Thread Emond Papegaaij
Hi Pierre,

First of all, I strongly recommend you do not use a different 
HeaderRenderStrategy. It is likely to get removed in future versions of Wicket 
and might break libraries that depend on the normal HeaderRenderStrategy. 
Second, I suggest you use Wicket 6, because consistent resource ordering in 
Wicket 1.5 is nearly impossible.

HeaderResponseTest in Wicket 6 gives a good demonstration of the order of 
resources. It shows that normal resources are rendered child-first, starting 
at the root of the class inheritance hierarchy. If you change nothing, the 
order will be B, C, A (A is last, because its header contribution is via 
renderHead). To move A to the front, you wrap it in a PriorityHeaderItem, and 
you should be done.

On Tuesday 24 July 2012 16:24:59 Pierre Goiffon wrote:
> > The order is now consistent - no matter if you contribute the CSS via
> > markup ( or ) or via code (in .java).
> 
> I didn't understand your statement ? Particularly "the order is now
> consistent".
> 
> My problem was originally about the delivery order of wicket:head
> contributions that was changed in wicket 1.5.
> Reading your statement I understand wicket:head do still render parent
> first in Wicket 1.5 but in Wicket 6 renders child first, like the other
> Java way (renderHead() right ?), so I guess I don't understand well what
> you wrote ?

In Wicket 1.5, different contributions to the header render in different ways 
and the order may not be what you'd expect it to be. The intention was to 
render child-first, but that proved difficult to implement, therefore header 
rendering has undergone major refactoring in 6. In Wicket 6, all headers are 
rendered child-first, except PriorityHeaderItems, which are rendered parent-
first.

> > Wicket defines two simple rules:
> > 1) component-first contribution - if you use a library that provides
> > Wicket components (e.g. WiQuery) then the components will contribute
> > first and then your page. This way you have the last word what CSS
> > rules to apply. I.e. you can override WiQuery's default CSS rules.
> > 2) child-component contributes after its parent - when you use
> > #renderHead(IHeaderResponse) you are in control to call
> > super.renderHead() at the top  of the method body or at the bottom.
> > Most of the time developers put it at the top. You don't have the
> > control for that for  though. Here Wicket contributes
> > first the parent's markup and then the child's one.

I'm not sure how this is in Wicket 1.5, but for Wicket 6, the second point is 
not correct. Moving the call to super.renderHead to the end of the method only 
changes the order between super- and subclass header items (the items for the 
superclass are inserted at the location of the super call).  is 
rendered child-first (not parent first), just as all other header items.

Best regards,
Emond

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



Re: getChoices from ListMultipleChoice

2012-07-26 Thread cosmindumy
Thanks
It helped me. But just another problem.
I have a customized multiple choice with 2 multiple ListMultipleChoice
inside. and movieng selected choices from each other. 
I have problems with safe cast.

Here is my class definition:
public class CusomizedMultipleChoice extends Panel

Here are the two method I used.

Collection leftChoices = leftChoice.getChoices();
Collection selectedLeftChoices = leftChoice.getModelObject();

The compiler complains at first method. getChoices. Shouldn't return return
a collection of T.  compiler ask me to cast at Collection. Is it safe to
do this?
I checked the wicket sources but couldn't find the cause.
Is anything wrong?
Thanks. 



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/getChoices-from-ListMultipleChoice-tp4650725p4650790.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