Re: dynamic navigation/side content depending on login status
See the following classes: Implement your AuthenticatedWebApplication to instantiate AuthenticatedWebSession, then use authorization stategies on component initialization: http://wicket.apache.org/apidocs/1.4/org/apache/wicket/authorization/package-summary.html Check the implementation here ( you can ignore the "spring" part ): https://cwiki.apache.org/WICKET/spring-security-and-wicket-auth-roles.html#SpringSecurityandWicket-auth-roles-Wicketsetup Žilvinas Vilutis Mobile: (+370) 652 38353 E-mail: cika...@gmail.com On Mon, Mar 21, 2011 at 3:49 PM, hrbaer wrote: > > Isammoc OFF wrote: >> >> I don't really understand why you have two xxxApplication.java for only >> two >> links. In my mind, I would make only one xxxApplication.java for both >> pages. > > If both links would be on the same page - yes. But if you have several pages > you need a separate xxxApplication.java file anyway (ok - not necessarily > but in most of the cases). > So let's assume there is a page A with a link and a page B with a link and > both need authentication. > > > Isammoc OFF wrote: >> >> This problem is common : Single Sign On (SSO). >> IMHO, you may share cookies and check if the user is connected to the >> other >> application(s) thru web services. > In fact there is only one application so from my point of view there is no > need of implementing a SSO. > The only thing I want to achieve is that a user don't have to login twice if > he click on link A on page A and afterwards on link B on page B (both need > authentication). > > There must be some easy solution for this issue, isn't it? > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/dynamic-navigation-side-content-depending-on-login-status-tp3384641p3395024.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: dynamic navigation/side content depending on login status
After reading your preceding mails again, I think I get the point : You don't need to create two classes that extends WebApplication because you want two pages to allow authentication. Both authentication pages are parts of the same application (read WebApplication). As Michael O'Cleirigh said : http://apache-wicket.1842946.n4.nabble.com/dynamic-navigation-side-content-depending-on-login-status-tp3384641p3384913.html > Look at the wicket-examples source code > for:org.apache.wicket.examples.authentication.MyAuthenticatedWebSession The MySignInPage may be directly mount like any other Page with the path you want. All pages which need authentication will be directly accessible once user is authenticated. -- Isammoc - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: dynamic navigation/side content depending on login status
Isammoc OFF wrote: > > I don't really understand why you have two xxxApplication.java for only > two > links. In my mind, I would make only one xxxApplication.java for both > pages. If both links would be on the same page - yes. But if you have several pages you need a separate xxxApplication.java file anyway (ok - not necessarily but in most of the cases). So let's assume there is a page A with a link and a page B with a link and both need authentication. Isammoc OFF wrote: > > This problem is common : Single Sign On (SSO). > IMHO, you may share cookies and check if the user is connected to the > other > application(s) thru web services. In fact there is only one application so from my point of view there is no need of implementing a SSO. The only thing I want to achieve is that a user don't have to login twice if he click on link A on page A and afterwards on link B on page B (both need authentication). There must be some easy solution for this issue, isn't it? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/dynamic-navigation-side-content-depending-on-login-status-tp3384641p3395024.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: Wicket mentioned at Server Side Symposium
I'm not trying to start a war here and I guess this will be my only contribution to this thread so with the risk of being punished by the wicket community, I guess the speaker said like he said because wicket release numbering doesn't follow "normal" version numbering (with "normal" I mean what most other projects use). If you have x.y.z, then you should change x: if you have API breaks y: if you have new development, internal improvements or non critical bug fixes and there isnt an API break z: if you have to release a hot-fix for due to a serious bug. Releases with this numbering will on the other hand require more maintenance. A z release should be made for all previous releases which contains the bug, provided that the 'old' release is still supported. It could be the last X number of y releases or perhaps all releases made the last number of X months. /J 2011/3/21 Martijn Dashorst > While we strive to keep binary compatibility between minor releases, > i.e. the z releases of an x.y.z release path, sometimes things slip > by. In principle we only allow security or blocker issues to break the > API in a .z release. So we strive to make the upgrade path of 1.4.0 to > 1.4.16 to be just a version number change, with an API surface the > size of Wicket's it is nigh impossible to achieve 100% binary > compatiblity between all minor releases (.z releases). > > If the speaker is talking about the y part, then yes we allow > breakages and possibly even large ones. But those are always fairly > easy to upgrade. > > The upgrade from 1.3 to 1.4 was mainly generics: a painful upgrade, > but worth the effort. It could've been a x release, but we only > modified the type parameter, and the rest of the API was only changed > to support the generification. We voted upon the release number and > with our previous 2.0 fiasco still in memory we decided to up the y > part only. > > With Wicket 1.5 we improved the internals considerably, and improved > the API as well. The upgrade path is detailed in our migration guide > in the wiki. The upgrade from 1.4 to 1.5 should be not too much work. > > I'd rather have a framework that breaks some API in minor ways with > each .y release, than a stagnant framework that is afraid to improve > on its API and internals. > > So while he technically has a point, I think it is a category z point. > Not a major one. > > Martijn > > On Mon, Mar 21, 2011 at 9:22 PM, Clint Checketts > wrote: > > Take the following with a grain of salt since I was told by a friend, of > a > > friend that attended the Server Side Symposium last week. I don't have > any > > of the details either so bear with me. > > > > Apparently in a session related to 'corporations using open source' the > > speaker asked if any companies were using Wicket. He cautioned that > Wicket > > was an example of mis-managing by being known to break it's APIs in minor > > point-releases. > > > > In my experience with the Wicket API, I've only seen major API changes in > > the major releases: 1.3 -> 1.4 and the upcoming 1.5. (In my book API > *additions > > *like adding onConfigure don't count) So of course I stood up for Wicket. > > Even when I've proposed changes myself the core developers have done a > great > > job of not breaking APIs. > > > > So, does anyone else know what this speaker may have been referring to > > regarding API breakages? > > > > -Clint > > > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org >
Re: Wicket mentioned at Server Side Symposium
While we strive to keep binary compatibility between minor releases, i.e. the z releases of an x.y.z release path, sometimes things slip by. In principle we only allow security or blocker issues to break the API in a .z release. So we strive to make the upgrade path of 1.4.0 to 1.4.16 to be just a version number change, with an API surface the size of Wicket's it is nigh impossible to achieve 100% binary compatiblity between all minor releases (.z releases). If the speaker is talking about the y part, then yes we allow breakages and possibly even large ones. But those are always fairly easy to upgrade. The upgrade from 1.3 to 1.4 was mainly generics: a painful upgrade, but worth the effort. It could've been a x release, but we only modified the type parameter, and the rest of the API was only changed to support the generification. We voted upon the release number and with our previous 2.0 fiasco still in memory we decided to up the y part only. With Wicket 1.5 we improved the internals considerably, and improved the API as well. The upgrade path is detailed in our migration guide in the wiki. The upgrade from 1.4 to 1.5 should be not too much work. I'd rather have a framework that breaks some API in minor ways with each .y release, than a stagnant framework that is afraid to improve on its API and internals. So while he technically has a point, I think it is a category z point. Not a major one. Martijn On Mon, Mar 21, 2011 at 9:22 PM, Clint Checketts wrote: > Take the following with a grain of salt since I was told by a friend, of a > friend that attended the Server Side Symposium last week. I don't have any > of the details either so bear with me. > > Apparently in a session related to 'corporations using open source' the > speaker asked if any companies were using Wicket. He cautioned that Wicket > was an example of mis-managing by being known to break it's APIs in minor > point-releases. > > In my experience with the Wicket API, I've only seen major API changes in > the major releases: 1.3 -> 1.4 and the upcoming 1.5. (In my book API > *additions > *like adding onConfigure don't count) So of course I stood up for Wicket. > Even when I've proposed changes myself the core developers have done a great > job of not breaking APIs. > > So, does anyone else know what this speaker may have been referring to > regarding API breakages? > > -Clint > -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling first AJAX request when cookies are disabled
Bernard, I owe you a beer. Calling session.bind() did the trick. Thanks. -Don On Mar 21, 2011, at 12:18 PM, b...@actrix.gen.nz wrote: > Without having tested it, I would try to create a permanent session, > hoping that the framework would do the rest in order to create server > side state for the page: > > session.bind() > > The idea behind this is that Wicket can do AJAX only for stateful > pages. > > Regards, > > Bernard > > > > On Sat, 19 Mar 2011 07:59:46 -0700, you wrote: > >> I'm struggling with a problem that probably has an easy solution. When >> cookies are disabled, if the first action on viewing the site is an AJAX >> request, it fails because the jsessionid hasn't been written into the URL. >> I notice that on other sites (such as wicketstuff), this doesn't happen >> because the first request gets a "302" (Temporarily Moved) to a URL that >> includes the jsessionid. Is this being done by the servlet container (I'm >> using Jetty), or is it handled elsewhere in the stack? >> >> One workaround to this problem is to setGatherExtenededBrowserInfo(true), >> but that results in the temporary display of an error page, which freaked >> out my boss. >> >> Any ideas how to best handle this? Thanks, and sorry if this has been >> discussed before. I searched in vain. >> >> -Don >> >> >> - >> 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
Wicket mentioned at Server Side Symposium
Take the following with a grain of salt since I was told by a friend, of a friend that attended the Server Side Symposium last week. I don't have any of the details either so bear with me. Apparently in a session related to 'corporations using open source' the speaker asked if any companies were using Wicket. He cautioned that Wicket was an example of mis-managing by being known to break it's APIs in minor point-releases. In my experience with the Wicket API, I've only seen major API changes in the major releases: 1.3 -> 1.4 and the upcoming 1.5. (In my book API *additions *like adding onConfigure don't count) So of course I stood up for Wicket. Even when I've proposed changes myself the core developers have done a great job of not breaking APIs. So, does anyone else know what this speaker may have been referring to regarding API breakages? -Clint
Re: Page Expired
Exactly same trouble, is there any solution so far? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Page-Expired-tp1844813p3394560.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: BestPractice - working with Wicket properites outside of Wicket context
sorry a correction , DomainObjectA.class.getName() instead of
canonical name because you can have property files for inner classes
too in that case canonical name will fail..
On Mon, Mar 21, 2011 at 11:52 PM, vineet semwal
wrote:
> simply use resource bundle?
>
> ResourceBundle.getBundle(DomainObjectA.class.getCanonicalName()).getString("key");
>
> On Mon, Mar 21, 2011 at 9:36 PM, Reinhard Vornholt
> wrote:
>> Hello group,
>>
>> can anybody point me in the right direction for the following problem.
>>
>> We are working on a project based on wicket 1.4.x (also hibernate,
>> spring and so on)
>> We are using property files for localized text. Mostly side by side
>> with the domain objects, like so:
>>
>> DomainObjectA.class
>> DomainObjectA.properties
>>
>> inside of DomainObjectA.properties we have
>>
>> attributeName.label=Intelligent Name
>> attributeName.tooltip=some usefull information
>>
>>
>> So far so good, everything works fine. But know we want to produce
>> some PDF documents. We are using iText to generate those documents.
>> The PDF document is a representation of a couple of pages. I would
>> like to use the same labels already stored in the properties files.
>> But I have no idea how to access them from my iText generating
>> classes. I have the domain objects inside the pdf generating context,
>> but no Application or component hierarchy or something like that.
>>
>> Can anyone please point me in a good direction, or (even better)
>> provide me with a working example of a solution?
>>
>> Any help is greatly appreciated.
>>
>> Reinhard.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
>
>
> --
> thank you,
>
> regards,
> Vineet Semwal
>
--
thank you,
regards,
Vineet Semwal
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling first AJAX request when cookies are disabled
Without having tested it, I would try to create a permanent session, hoping that the framework would do the rest in order to create server side state for the page: session.bind() The idea behind this is that Wicket can do AJAX only for stateful pages. Regards, Bernard On Sat, 19 Mar 2011 07:59:46 -0700, you wrote: >I'm struggling with a problem that probably has an easy solution. When >cookies are disabled, if the first action on viewing the site is an AJAX >request, it fails because the jsessionid hasn't been written into the URL. I >notice that on other sites (such as wicketstuff), this doesn't happen because >the first request gets a "302" (Temporarily Moved) to a URL that includes the >jsessionid. Is this being done by the servlet container (I'm using Jetty), or >is it handled elsewhere in the stack? > >One workaround to this problem is to setGatherExtenededBrowserInfo(true), but >that results in the temporary display of an error page, which freaked out my >boss. > >Any ideas how to best handle this? Thanks, and sorry if this has been >discussed before. I searched in vain. > >-Don > > >- >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 way to remove content from a close Modal Window?
Great, thanks Pedro. I'll give that a go. >-Original Message- >From: Pedro Santos [mailto:pedros...@gmail.com] >Sent: Tuesday, 22 March 2011 5:41 AM >To: users@wicket.apache.org >Subject: Re: Best way to remove content from a close Modal Window? > >modalWindow.replace(new WebMarkupContainer(modalWindow.getContentId())); > >On Mon, Mar 21, 2011 at 3:36 PM, Chris Colman >wrote: > >> I open a form in a ModalWindow. Even after the form is closed the >> content seems to remain because the form contents are serialized out >> with the page. >> >> What is the best way to remove the content from the ModalWindow after >> the window is closed? I tried calling setContent(null) but that causes a >> subsequent NPE. >> > > > >-- >Pedro Henrique Oliveira dos Santos - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Best way to remove content from a close Modal Window?
modalWindow.replace(new WebMarkupContainer(modalWindow.getContentId())); On Mon, Mar 21, 2011 at 3:36 PM, Chris Colman wrote: > I open a form in a ModalWindow. Even after the form is closed the > content seems to remain because the form contents are serialized out > with the page. > > What is the best way to remove the content from the ModalWindow after > the window is closed? I tried calling setContent(null) but that causes a > subsequent NPE. > -- Pedro Henrique Oliveira dos Santos
Re: BestPractice - working with Wicket properites outside of Wicket context
simply use resource bundle?
ResourceBundle.getBundle(DomainObjectA.class.getCanonicalName()).getString("key");
On Mon, Mar 21, 2011 at 9:36 PM, Reinhard Vornholt
wrote:
> Hello group,
>
> can anybody point me in the right direction for the following problem.
>
> We are working on a project based on wicket 1.4.x (also hibernate,
> spring and so on)
> We are using property files for localized text. Mostly side by side
> with the domain objects, like so:
>
> DomainObjectA.class
> DomainObjectA.properties
>
> inside of DomainObjectA.properties we have
>
> attributeName.label=Intelligent Name
> attributeName.tooltip=some usefull information
>
>
> So far so good, everything works fine. But know we want to produce
> some PDF documents. We are using iText to generate those documents.
> The PDF document is a representation of a couple of pages. I would
> like to use the same labels already stored in the properties files.
> But I have no idea how to access them from my iText generating
> classes. I have the domain objects inside the pdf generating context,
> but no Application or component hierarchy or something like that.
>
> Can anyone please point me in a good direction, or (even better)
> provide me with a working example of a solution?
>
> Any help is greatly appreciated.
>
> Reinhard.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
--
thank you,
regards,
Vineet Semwal
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: dynamic navigation/side content depending on login status
Hi, I don't really understand why you have two xxxApplication.java for only two links. In my mind, I would make only one xxxApplication.java for both pages. But I assume is for test purpose about sharing connection information between two (or more) distinct applications. This problem is common : Single Sign On (SSO). IMHO, you may share cookies and check if the user is connected to the other application(s) thru web services. Googling for "single sign on wicket" bring me the following link : http://www.jumpingbean.co.za/blogs/mark/wicket-tomcat-form-based-authentication A Struts or an other Wicket application should work in the same way. May anyone confirm this ? Regards, -- Isammoc
Re: dynamic navigation/side content depending on login status
Hi all, any idea how do share sessions? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/dynamic-navigation-side-content-depending-on-login-status-tp3384641p3394125.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
BestPractice - working with Wicket properites outside of Wicket context
Hello group, can anybody point me in the right direction for the following problem. We are working on a project based on wicket 1.4.x (also hibernate, spring and so on) We are using property files for localized text. Mostly side by side with the domain objects, like so: DomainObjectA.class DomainObjectA.properties inside of DomainObjectA.properties we have attributeName.label=Intelligent Name attributeName.tooltip=some usefull information So far so good, everything works fine. But know we want to produce some PDF documents. We are using iText to generate those documents. The PDF document is a representation of a couple of pages. I would like to use the same labels already stored in the properties files. But I have no idea how to access them from my iText generating classes. I have the domain objects inside the pdf generating context, but no Application or component hierarchy or something like that. Can anyone please point me in a good direction, or (even better) provide me with a working example of a solution? Any help is greatly appreciated. Reinhard. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Getting data from dynamically constructed elements
Thank you for your response I got it - Wicket-Java -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Getting-data-from-dynamically-constructed-elements-tp3391580p3393708.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: Ajax modal window does not allow submit form under open browsers
Forget my last comment, your patch maintains the hierarchy, just need to see if it do not implies into style problems. JQuery also move the dialog element to the top. Probably because an element with the css property position=relative in the middle of hierarchy can cause presentation problems. On Mon, Mar 21, 2011 at 10:17 AM, Pedro Santos wrote: > The patch look good, but will force all current nested forms inside some > modal window to override the Form#isRootForm to return true > A possible way of avoid is to flag the mismatch in hierarchy. Join us in > the dev mail list to discuss, there is even a thread already: > > > http://markmail.org/search/?q=wicket#query:wicket%20list%3Aorg.apache.wicket.dev%20date%3A201102%20from%3A%22Pedro%20Santos%22+page:1+mid:lrhm4gcg7cxoskgm+state:results > > > > On Mon, Mar 21, 2011 at 10:01 AM, Sven Meier wrote: > >> Hi Pedro, >> >> modal window renders its content into its own tag's body before moving it >> into new tags on the top level. >> In the proposed patch this intermediate step is skipped, thus keeping the >> markup valid even in case of a form in the dialog's content. >> >> >> Pedro Santos wrote: >> > >> > I don't remember of any change in this. >> > >> >> The patch was not accepted for 1.5. >> >> Best regards >> >> Sven >> >> -- >> View this message in context: >> http://apache-wicket.1842946.n4.nabble.com/Ajax-modal-window-does-not-allow-submit-form-under-open-browsers-tp3390374p3393492.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 >> >> > > > -- > Pedro Henrique Oliveira dos Santos > -- Pedro Henrique Oliveira dos Santos
Re: Ajax modal window does not allow submit form under open browsers
The patch look good, but will force all current nested forms inside some modal window to override the Form#isRootForm to return true A possible way of avoid is to flag the mismatch in hierarchy. Join us in the dev mail list to discuss, there is even a thread already: http://markmail.org/search/?q=wicket#query:wicket%20list%3Aorg.apache.wicket.dev%20date%3A201102%20from%3A%22Pedro%20Santos%22+page:1+mid:lrhm4gcg7cxoskgm+state:results On Mon, Mar 21, 2011 at 10:01 AM, Sven Meier wrote: > Hi Pedro, > > modal window renders its content into its own tag's body before moving it > into new tags on the top level. > In the proposed patch this intermediate step is skipped, thus keeping the > markup valid even in case of a form in the dialog's content. > > > Pedro Santos wrote: > > > > I don't remember of any change in this. > > > > The patch was not accepted for 1.5. > > Best regards > > Sven > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Ajax-modal-window-does-not-allow-submit-form-under-open-browsers-tp3390374p3393492.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 > > -- Pedro Henrique Oliveira dos Santos
Re: Getting data from dynamically constructed elements
The state of the checkboxes is determined by the model. So, just make sure the model doesn't contain those values. Take a look at: http://wicketstuff.org/wicket14/forminput/ for an example. The model isn't completely obvious (which is why I dislike CompoundPropertyModels), but the values that will be checked will be the ones that are contained in the FormInputModel's "numbersCheckGroup" property (which is an ArrayList). So, if a Check's model value is contained in the "numbersCheckGroup" list, then that Check will be selected. On Mon, Mar 21, 2011 at 8:16 AM, tech7 wrote: > I have assigned that groupModels to checkGroup but all checkboxes are coming > checked. > How can I display them as unchecked at first display?? > > > - > Wicket-Java > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Getting-data-from-dynamically-constructed-elements-tp3391580p3393405.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: Ajax modal window does not allow submit form under open browsers
Hi Pedro, modal window renders its content into its own tag's body before moving it into new tags on the top level. In the proposed patch this intermediate step is skipped, thus keeping the markup valid even in case of a form in the dialog's content. Pedro Santos wrote: > > I don't remember of any change in this. > The patch was not accepted for 1.5. Best regards Sven -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Ajax-modal-window-does-not-allow-submit-form-under-open-browsers-tp3390374p3393492.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: Getting data from dynamically constructed elements
I have assigned that groupModels to checkGroup but all checkboxes are coming checked. How can I display them as unchecked at first display?? - Wicket-Java -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Getting-data-from-dynamically-constructed-elements-tp3391580p3393405.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: Ajax modal window does not allow submit form under open browsers
The modal window's content is rendered into a set of new elements into the page body directly, this set include a form tag. If you add a root form inside the modal window content, the HTML for the opened window will be invalid because of nested form tags. I don't remember of any change in this. On Mon, Mar 21, 2011 at 8:15 AM, Sven Meier wrote: > Yes, the extra form in modal window is no longer needed. > > This works because a modal window's content is 'just' rendered into a new > element in the page body directly. > > Sven > > > Brown, Berlin [GCG-PFS] wrote: > > > > OK, so the patch just scraps the form in the modal window. > > > > -Original Message- > > From: Chris Colman [mailto:chr...@stepaheadsoftware.com] > > Sent: Sunday, March 20, 2011 8:36 AM > > To: users@wicket.apache.org > > Subject: RE: Ajax modal window does not allow submit form under open > > browsers > > > > >.. and please vote for WICKET-3404 if you think the need for this > > >additional form is just annoying. > > > > +1 from me! > > > > I find having to wrap a modal in a form quite annoying. > > > > - > > 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 > > > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Ajax-modal-window-does-not-allow-submit-form-under-open-browsers-tp3390374p3393166.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 > > -- Pedro Henrique Oliveira dos Santos
RE: Ajax modal window does not allow submit form under open browsers
Yes, the extra form in modal window is no longer needed. This works because a modal window's content is 'just' rendered into a new element in the page body directly. Sven Brown, Berlin [GCG-PFS] wrote: > > OK, so the patch just scraps the form in the modal window. > > -Original Message- > From: Chris Colman [mailto:chr...@stepaheadsoftware.com] > Sent: Sunday, March 20, 2011 8:36 AM > To: users@wicket.apache.org > Subject: RE: Ajax modal window does not allow submit form under open > browsers > > >.. and please vote for WICKET-3404 if you think the need for this > >additional form is just annoying. > > +1 from me! > > I find having to wrap a modal in a form quite annoying. > > - > 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 > -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Ajax-modal-window-does-not-allow-submit-form-under-open-browsers-tp3390374p3393166.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: Drop Down Choice
> typing "T" would select "Two", but typing "Th" would select "Three". Is > this possible in Wicket? This is the way well-behaved modern browsers already work :) - Tor I. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Getting data from dynamically constructed elements
Any suggestions? - Wicket-Java -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Getting-data-from-dynamically-constructed-elements-tp3391580p3392901.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: Portlet Development with wicket
Thanks. I hope the functionality will remain available somewhere. May be as a separate library. Josh. On Mon, Mar 21, 2011 at 10:52 AM, Wilhelmsen Tor Iver wrote: > > Does wicket support development of portlets ? I cant find much > information > > by googling. > > Wicket 1.4 does (and it works fine at least in our context of using Liferay > as container), apparently in 1.5 they are moving that functionality out from > the main library. > > - Tor Iver > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
RE: Portlet Development with wicket
> Does wicket support development of portlets ? I cant find much information > by googling. Wicket 1.4 does (and it works fine at least in our context of using Liferay as container), apparently in 1.5 they are moving that functionality out from the main library. - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Call urlFor(Class, PageParams) outside of request cycle
> We have a Quartz thread which periodically sends emails with a link to > a Wicket page. Calling RequestCycle.get().urlFor(Class, > PageParameters) doesn't work because the thread is not a part of > Wicket request cycle. Is there a way to ask Wicket to generate the URL > in this case? What you really want is to use a bookmarkable page mounted in the application, and create a URL string with the necessary parameters in the Quartz job. Or create a simple Wicket servlet that generates it for you, which you then call from the job using e.g. a standard URLConnection. - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
