Re: component not visible exception
One other thing to check is, do you have a custom isVisible() override in the container or do you explicitly set it to visible/invisible using setVisible()? If the former, this logic will usually be re-evaluated upon form submission and if that logic depends on some state which might change upon submission, you might get exactly that error. Matt On 2010-11-29 20:21, Igor Vaynberg wrote: another possibility, if this page is using hybrid url coding strategy, is that the session expires and the form is submitted against a new instance of the page - where the button is not visible. -igor On Mon, Nov 29, 2010 at 11:05 AM, Douglas Ferguson wrote: The problem is that I can't recreate this error, but I see it in production alot. So I have no way of looking at the action url. D/ On Nov 29, 2010, at 12:59 PM, Igor Vaynberg wrote: easy. the form's action url points to a version of the page where the button is not visible. so when the button is clicked and the form is submitted wicket rolls back the version of the page to one where button is not visible and you get the error. not sure that is what is happening in your app, but its one possible explanation. look at form's url and make sure none of your ajax actions are changing the page version. -igor On Mon, Nov 29, 2010 at 10:41 AM, Douglas Ferguson wrote: We do toggle the visibility of the web markup container that contains the button. Here's how it works. 1) Page loads and the container is hidden 2) An ajax timer is used to watch for state to change 3) When state changes we make the container visible (which then makes the submit button visible) How could they user manage to click on the save button when is it not visible? The only thing I can think of is that this could be some back button issue. But then again, I'm not sure how that would manifest... D/ On Nov 29, 2010, at 11:25 AM, Igor Vaynberg wrote: in order for component to be visible all of its parents have to be visible from the page down to the component. same for the enabled state. -igor On Mon, Nov 29, 2010 at 9:21 AM, Douglas Ferguson wrote: Hmm... even if we aren't changing the visibility of the button? On Nov 29, 2010, at 10:42 AM, Marco Mancini wrote: try to set mybutton.setOutputMarkupPlaceholderTag(true); bye marco 2010/11/29 Martin Grigorov On Mon, Nov 29, 2010 at 4:46 PM, Douglas Ferguson< doug...@douglasferguson.us> wrote: We have not overridden isVisible, nor have we do we have a popup modal. That's why I was asking if this could be a back button issue. The only thing we do is set the button enabled. Could this be the problem even thought he message it talking about visibility? No. There is a separate check for enabled state. It is definitely for visibility. D/ On Nov 29, 2010, at 3:15 AM, Martin Grigorov wrote: Here is another scenario: Ajax request sets the visibility of the submit button (or its parent) to false but forgets to repaint the button so it is still visible for the user. Then the user clicks on this button, it fires and then the backend shows this message - the button is invisible so it cannot be clicked. On Mon, Nov 29, 2010 at 9:04 AM, Chris Colman wrote: A back button where? The form is on a page and has a submit button only. If there is an error a ModalWindow pops up - it only has an OK button which is meant to make the ModalWindow simply disappear and thus re-enable the page beneath - the one with the form on it. Chris -Original Message- From: Douglas Ferguson [mailto:doug...@douglasferguson.us] Sent: Monday, 29 November 2010 6:53 PM To: users@wicket.apache.org Subject: Re: component not visible exception Could this be happening because of the back button? D/ On Nov 28, 2010, at 4:54 AM, Chris Colman wrote: I had a similar problem. In my scenario it occurred when a ModalWindow was brought up when a form failed validation. When they clicked ok to close the ModalWindow and then clicked Submit on the form again I got a similar message saying that the Submit button was no longer visible. It doesn't happen if I use the normal validation 'feedback' panel to display the validation error messages. Chris -Original Message- From: Douglas Ferguson [mailto:doug...@douglasferguson.us] Sent: Saturday, 27 November 2010 3:13 AM To: Wicket Mailing List List Subject: component not visible exception I have an error I've been seeing in the production logs for awhile now and haven't been able to to figure it out. My thought is that it is due to a stale page or the back button, but it seems to me that it is happening alot, so I thought I might inquire. Any thoughts on what might be causing this and how to avoid it? 2010-11-26 08:36:36,676 ERROR [TP-Processor34] wicket.RequestCycle - Submit Button add (path=dataPanel:contentCenterBox:addUserForm:add) is not visible org.apache.wicket.WicketRuntimeException: Submit Button add (path=dataPanel:contentCenterBox:addUserForm:add) is
SV: PageableListView to work with Set
> I guess it expects only a List type object. I can work around this by > converting the Set into a List and then provide it but felt somehow this is > a limitation. How can I work with generic collections? > Any thoughts much appreciated No, because ordering requires the indexing a List has. In theory, you could make an IteratorView which uses the Iterator from a generic collection, but you would abandon things like paging, sorting etc. which rely on indexability. - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
PageableListView to work with Set
Hi
I have a question related to using a collection (Set) within a
PageableListView. At runtime I get an exception
java.lang.ClassCastException: org.hibernate.collection.PersistentSet cannot
be cast to java.util.List
at org.apache.wicket.markup.html.list.ListView.getList(ListView.java:177)
The entity structure is like this
public class Subject{
String firstName;
Set phones;
}
I guess it expects only a List type object. I can work around this by
converting the Set into a List and then provide it but felt somehow this is
a limitation. How can I work with generic collections?
Any thoughts much appreciated
thank you
Regards
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/PageableListView-to-work-with-Set-tp3064909p3064909.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
Set with PageableListView
Hi
I have a question related to using a collection (Set) within a
PageableListView. At runtime I get an exception
java.lang.ClassCastException: org.hibernate.collection.PersistentSet cannot
be cast to java.util.List
at org.apache.wicket.markup.html.list.ListView.getList(ListView.java:177)
The entity structure is like this
public class Subject{
String firstName;
Set phones;
}
I guess it expects only a List type object. I can work around this by
converting the Set into a List and then provide it but felt somehow this is
a limitation. How can I work with generic collections?
Any thoughts much appreciated
thank you
Regards
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Set-Object-with-PageableListView-tp3064906p3064906.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: visural-wicket 0.6.5 released!
Hi Marc, Yes I will intend to improve the Maven support for the next release. For now I have updated the wiki on Maven support to include the required references to the visural-common library. http://code.google.com/p/visural-wicket/wiki/MavenSupport cheers, Richard. On Fri, Nov 26, 2010 at 9:45 PM, Marc Ende wrote: > May be you should mention the need for visural-common in the basic-usage. > When using the InputHintBehavior I got an ClassNotFound exception. > > anyway: a visural-wicket is a great collection of components. ;) > > marc > > 2010/11/25 Richard Nichols > > > What error are you getting? > > > > It may be related to my separating the visural-common dependency from the > > main visural-wicket JAR. > > > > On Fri, Nov 26, 2010 at 8:56 AM, Paul Szulc > wrote: > > > > > maven repo is not working > > > > > > On Thu, Nov 25, 2010 at 9:19 PM, Richard Nichols > wrote: > > > > > > > Thanks for all the positive comments :) > > > > > > > > If anyone has any suggestions / ideas for the next release (0.7) then > > let > > > > me > > > > know. > > > > > > > > Currently the only things on the RoadMap, are Wicket 1.5 support and > > some > > > > refactoring on the DropDown control (which has become a bit of a > > > > maintenance > > > > time-sink). > > > > > > > > cheers, > > > > RIch > > > > > > > > On Fri, Nov 26, 2010 at 6:19 AM, Mark Doyle < > > > markjohndo...@googlemail.com > > > > >wrote: > > > > > > > > > Great library. I always expected more of these since component > > > creation > > > > > and > > > > > reuse is one of Wickets a key strengths. > > > > > > > > > > What I like about this lib is it's clean and finished. There is no > > > > feeling > > > > > of immaturity or of a project that has died off. > > > > > > > > > > > > > > > On Thu, Nov 25, 2010 at 2:02 PM, alex shubert < > > alex.shub...@gmail.com > > > > > >wrote: > > > > > > > > > > > I must ask it: why did you make such fat header at your page? Did > > you > > > > > > every try to take a look at this in 1600*900 notebook screen? > > > > > > All you writings begins in bottom second part of the screen. It > is > > > not > > > > > > my busenees of course, but why dont you kill that nice picture > and > > > > > > resize header to just contain "pragmatic" without strong empty > > white > > > > > > line? > > > > > > > > > > > > Ah, forget it. At least you did not add banner on the top of all > of > > > > that > > > > > > :) > > > > > > > > > > > > -- > > > > > > Best regards > > > > > > Alex > > > > > > > > > > > > > > - > > > > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > > > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Richard Nichols > > > > http://www.richardnichols.net/ :: http://onmydoorstep.com.au/ > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Paul Szulc > > > > > > http://www.paulszulc.com > > > > > > > > > > > -- > > Richard Nichols > > http://www.richardnichols.net/ :: http://onmydoorstep.com.au/ > > > -- Richard Nichols http://www.richardnichols.net/ :: http://onmydoorstep.com.au/
Re: Dynamically loading image
there is a wiki page that explains how to serve images...search for it, i think its called "uploade/download" or something like that. -igor On Mon, Nov 29, 2010 at 7:11 PM, Matthew Goodson wrote: > > Hi all, > I'm needing to generate the url to an image dynamically on the client. > i.e. I want to be able to chuck a generated url (e.g > localhost:8080/images?imageId=blah) into the src of an img which would then > go off and hit a wicket page which returns the binary data for the image. > I'm not really getting anywhere by myself. > Does anyone have any pointers?! > Hope that makes sense. > Thanks! > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Dynamically-loading-image-tp3064795p3064795.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
WICKET-962 and AbstractRepeater's warning about child ID's
Hi, could any wicket gurus explain in more details about ajax updates and AbstractRepeater's limitation to child ids ? I found in mentioned in the subject issue, but still did not get the limitation. Is this limitation actual for wicket 1.4.x and wicket-1.5 ? In my project I use repeating view massively for forms, so I need to use my own IDs for each form field (CompoundPropertyModel). Thanks. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/WICKET-962-and-AbstractRepeater-s-warning-about-child-ID-s-tp3064797p3064797.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
Dynamically loading image
Hi all, I'm needing to generate the url to an image dynamically on the client. i.e. I want to be able to chuck a generated url (e.g localhost:8080/images?imageId=blah) into the src of an img which would then go off and hit a wicket page which returns the binary data for the image. I'm not really getting anywhere by myself. Does anyone have any pointers?! Hope that makes sense. Thanks! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Dynamically-loading-image-tp3064795p3064795.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: UploadProgressBar on nested forms
your quickstart was missing the UploadWebRequest. see progress bar's javadoc.
-igor
On Mon, Nov 29, 2010 at 5:23 PM, Alec Swan wrote:
> Right, that works. However, the progress bar shows up but doesn't show any
> progress. It basically sits there without updating and then disappears. Am I
> missing some customization steps?
>
> What I am trying to do is to have the progress bar to be a sort of modal
> dialog expanding over the outer form preventing the user from entering or
> clicking nested form elements. Is this possible?
>
> Thanks,
>
> Alec
>
>
> On Mon, Nov 29, 2010 at 9:56 AM, Igor Vaynberg wrote:
>
>> yeah, just add it to the outer form :)
>>
>> -igor
>>
>> On Mon, Nov 29, 2010 at 8:52 AM, Alec Swan wrote:
>> > Igor, thanks for fixing JIRA 3191. Based on your comment the progress bar
>> > will show up in all nested file upload forms when a single form is
>> > submitted.
>> >
>> > Is there a way to make the progress bar a child component of the outer
>> form
>> > and display the bar on submission of any (or all) nested forms?
>> >
>> > Thanks,
>> >
>> > Alec
>> >
>> > On Wed, Nov 24, 2010 at 10:29 AM, Alec Swan wrote:
>> >
>> >> Done. JIRA 3191.
>> >>
>> >> Thanks
>> >>
>> >> On Tue, Nov 23, 2010 at 10:39 PM, Igor Vaynberg <
>> igor.vaynb...@gmail.com>
>> >> wrote:
>> >> > file another issue with a new quickstart.
>> >> >
>> >> > -igor
>> >> >
>> >> > On Tue, Nov 23, 2010 at 8:45 PM, Alec Swan
>> wrote:
>> >> >> Hello,
>> >> >>
>> >> >> Thank you for promptly fixing the problem with the upload progress
>> bar
>> >> in
>> >> >> nested forms. I applied the fix by merging SVN changes into 1.4.13
>> >> branch
>> >> >> and rebuilding the JAR files.
>> >> >>
>> >> >> I verified that the original problem was fixed with the patched jars.
>> >> >> However, here is a new problem. If I have two upload forms, then
>> upload
>> >> >> initiated in the first form shows progress bar in the second form.
>> So,
>> >> if
>> >> >> the second form happens to be hidden (setVisible(false)), then the
>> >> upload
>> >> >> progress bar does not show up at all.
>> >> >>
>> >> >> Should I file another JIRA issue, add to the existing 3181 issue or
>> >> change
>> >> >> my code?
>> >> >>
>> >> >> Thanks
>> >> >>
>> >> >>
>> >> >> On Sat, Nov 20, 2010 at 5:59 PM, Alec Swan
>> wrote:
>> >> >>
>> >> >>> I opened JIRA issue 3181:
>> >> >>> https://issues.apache.org/jira/browse/WICKET-3181. I attached a ZIP
>> >> >>> file with complete source to reproduce the issue and instructions on
>> >> >>> how to run it (I am sure you didn't need them).
>> >> >>>
>> >> >>> Please let me know if you can think of any other solutions for
>> >> >>> displaying a modal window from nested upload form.
>> >> >>>
>> >> >>> Thanks,
>> >> >>>
>> >> >>> Alec
>> >> >>>
>> >> >>> On Sat, Nov 20, 2010 at 1:35 PM, Igor Vaynberg <
>> >> igor.vaynb...@gmail.com>
>> >> >>> wrote:
>> >> >>> > not sure yet :) but a quickstart will give me a playground to
>> explore
>> >> >>> > the options.
>> >> >>> >
>> >> >>> > -igor
>> >> >>> >
>> >> >>> > On Sat, Nov 20, 2010 at 12:20 PM, Alec Swan
>> >> wrote:
>> >> >>> >> I can file a bug, but I am curious how you are planning to fix
>> this?
>> >> >>> >>
>> >> >>> >> I tried passing the OUTER form to UploadProgressBar, i.e.
>> >> >>> >> nestedForm.add(new UploadProgressBar("progress", outerForm)), but
>> >> that
>> >> >>> >> caused the following error to be logged in Firebug:
>> >> >>> >>
>> >> >>> >> Wicket.WUPB.get(def.statusid) is null
>> >> >>> >> [Break on this error]
>> >> Wicket.WUPB.get(def.statusid).innerHTML='Upload
>> >> >>> >> starting...';
>> >> >>> >> progressbar.js (line 41
>> >> >>> >>
>> >> >>> >> While I am filing a bug and waiting for a fix, are there any
>> >> >>> >> suggestions on how to show a modal window during files upload
>> >> >>> >> initiated from a nested form?
>> >> >>> >>
>> >> >>> >> Thanks
>> >> >>> >>
>> >> >>> >> On Sat, Nov 20, 2010 at 1:05 PM, Igor Vaynberg <
>> >> igor.vaynb...@gmail.com>
>> >> >>> wrote:
>> >> >>> >>> sounds like a bug. open a jira ticket, attach a quickstart.
>> >> >>> >>>
>> >> >>> >>> -igor
>> >> >>> >>>
>> >> >>> >>> On Sat, Nov 20, 2010 at 11:22 AM, Alec Swan > >
>> >> >>> wrote:
>> >> >>> Hello,
>> >> >>>
>> >> >>> I have a page which contains a form around a table. Each row in
>> >> the
>> >> >>> table contains a nested form which allows user to upload a file
>> >> for
>> >> >>> the row. I added an UploadProgressBar to the upload form in
>> each
>> >> row.
>> >> >>> However, the upload progress bars are never shown.
>> >> >>>
>> >> >>> I understand that Wicket replaces a nested with
>> and
>> >> adds
>> >> >>> onsubmit event handler to display UploadProgressBar. However,
>> >> since
>> >> >>> the was replaced with onsubmit handler never
>> fires.
>> >> >>>
>> >> >>> How can I display a progress bar or at least a modal window
>> during
>> >> a
>> >> >>> file upload from a nested form?
>> >
Re: UploadProgressBar on nested forms
Right, that works. However, the progress bar shows up but doesn't show any
progress. It basically sits there without updating and then disappears. Am I
missing some customization steps?
What I am trying to do is to have the progress bar to be a sort of modal
dialog expanding over the outer form preventing the user from entering or
clicking nested form elements. Is this possible?
Thanks,
Alec
On Mon, Nov 29, 2010 at 9:56 AM, Igor Vaynberg wrote:
> yeah, just add it to the outer form :)
>
> -igor
>
> On Mon, Nov 29, 2010 at 8:52 AM, Alec Swan wrote:
> > Igor, thanks for fixing JIRA 3191. Based on your comment the progress bar
> > will show up in all nested file upload forms when a single form is
> > submitted.
> >
> > Is there a way to make the progress bar a child component of the outer
> form
> > and display the bar on submission of any (or all) nested forms?
> >
> > Thanks,
> >
> > Alec
> >
> > On Wed, Nov 24, 2010 at 10:29 AM, Alec Swan wrote:
> >
> >> Done. JIRA 3191.
> >>
> >> Thanks
> >>
> >> On Tue, Nov 23, 2010 at 10:39 PM, Igor Vaynberg <
> igor.vaynb...@gmail.com>
> >> wrote:
> >> > file another issue with a new quickstart.
> >> >
> >> > -igor
> >> >
> >> > On Tue, Nov 23, 2010 at 8:45 PM, Alec Swan
> wrote:
> >> >> Hello,
> >> >>
> >> >> Thank you for promptly fixing the problem with the upload progress
> bar
> >> in
> >> >> nested forms. I applied the fix by merging SVN changes into 1.4.13
> >> branch
> >> >> and rebuilding the JAR files.
> >> >>
> >> >> I verified that the original problem was fixed with the patched jars.
> >> >> However, here is a new problem. If I have two upload forms, then
> upload
> >> >> initiated in the first form shows progress bar in the second form.
> So,
> >> if
> >> >> the second form happens to be hidden (setVisible(false)), then the
> >> upload
> >> >> progress bar does not show up at all.
> >> >>
> >> >> Should I file another JIRA issue, add to the existing 3181 issue or
> >> change
> >> >> my code?
> >> >>
> >> >> Thanks
> >> >>
> >> >>
> >> >> On Sat, Nov 20, 2010 at 5:59 PM, Alec Swan
> wrote:
> >> >>
> >> >>> I opened JIRA issue 3181:
> >> >>> https://issues.apache.org/jira/browse/WICKET-3181. I attached a ZIP
> >> >>> file with complete source to reproduce the issue and instructions on
> >> >>> how to run it (I am sure you didn't need them).
> >> >>>
> >> >>> Please let me know if you can think of any other solutions for
> >> >>> displaying a modal window from nested upload form.
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> Alec
> >> >>>
> >> >>> On Sat, Nov 20, 2010 at 1:35 PM, Igor Vaynberg <
> >> igor.vaynb...@gmail.com>
> >> >>> wrote:
> >> >>> > not sure yet :) but a quickstart will give me a playground to
> explore
> >> >>> > the options.
> >> >>> >
> >> >>> > -igor
> >> >>> >
> >> >>> > On Sat, Nov 20, 2010 at 12:20 PM, Alec Swan
> >> wrote:
> >> >>> >> I can file a bug, but I am curious how you are planning to fix
> this?
> >> >>> >>
> >> >>> >> I tried passing the OUTER form to UploadProgressBar, i.e.
> >> >>> >> nestedForm.add(new UploadProgressBar("progress", outerForm)), but
> >> that
> >> >>> >> caused the following error to be logged in Firebug:
> >> >>> >>
> >> >>> >> Wicket.WUPB.get(def.statusid) is null
> >> >>> >> [Break on this error]
> >> Wicket.WUPB.get(def.statusid).innerHTML='Upload
> >> >>> >> starting...';
> >> >>> >> progressbar.js (line 41
> >> >>> >>
> >> >>> >> While I am filing a bug and waiting for a fix, are there any
> >> >>> >> suggestions on how to show a modal window during files upload
> >> >>> >> initiated from a nested form?
> >> >>> >>
> >> >>> >> Thanks
> >> >>> >>
> >> >>> >> On Sat, Nov 20, 2010 at 1:05 PM, Igor Vaynberg <
> >> igor.vaynb...@gmail.com>
> >> >>> wrote:
> >> >>> >>> sounds like a bug. open a jira ticket, attach a quickstart.
> >> >>> >>>
> >> >>> >>> -igor
> >> >>> >>>
> >> >>> >>> On Sat, Nov 20, 2010 at 11:22 AM, Alec Swan >
> >> >>> wrote:
> >> >>> Hello,
> >> >>>
> >> >>> I have a page which contains a form around a table. Each row in
> >> the
> >> >>> table contains a nested form which allows user to upload a file
> >> for
> >> >>> the row. I added an UploadProgressBar to the upload form in
> each
> >> row.
> >> >>> However, the upload progress bars are never shown.
> >> >>>
> >> >>> I understand that Wicket replaces a nested with
> and
> >> adds
> >> >>> onsubmit event handler to display UploadProgressBar. However,
> >> since
> >> >>> the was replaced with onsubmit handler never
> fires.
> >> >>>
> >> >>> How can I display a progress bar or at least a modal window
> during
> >> a
> >> >>> file upload from a nested form?
> >> >>>
> >> >>> Thanks!
> >> >>>
> >> >>>
> >> -
> >> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> >>> For additional commands, e-mail: users-h...@wicket.apache.org
> >> >>>
Re: component not visible exception
this is a shortcoming of the hybrid coding strategy. you can try tweaking it so that if it detects a url with page id but page id is not found in session it can throw a stale page exception. submit a patch and we can role it into core. -igor On Mon, Nov 29, 2010 at 2:31 PM, Douglas Ferguson wrote: > That seems more likely to me. > > Is there anything I could do to prevent this? > > D/ > > On Nov 29, 2010, at 1:21 PM, Igor Vaynberg wrote: > >> another possibility, if this page is using hybrid url coding strategy, >> is that the session expires and the form is submitted against a new >> instance of the page - where the button is not visible. > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4.14 and WiQuery Tabs
Sadly, none of my wiquery components seem to work under 1.1.1. Previously, I
had to disable auto-import of jquery resources because I was having
conflicts with other jquery-based components (jgrowl, custom stuff). Maybe
that's why. I assume 1.1.1 is backwards compatible and setup is the same?
Anyway, tabs do work in *certain* places using 1.03. A panel with a broken
tab will work if placed on a different page/panel. (In other words, if I use
the app's cms interface to position the panel somewhere else). Once tabs
start working, they work everywhere in the application until logout. I can't
figure out what's different between the working and non-working instances of
the same panel. It's odd. I suppose I need to debug into wiquery and/or
wicket.
If I switch to 1.4.12, no problems at all.
-Original Message-
From: Brian Topping
Sent: Monday, November 29, 2010 3:48 PM
To: users@wicket.apache.org
Subject: Re: Wicket 1.4.14 and WiQuery Tabs
Ah, great point. I am already using 1.1.1!
On Nov 29, 2010, at 4:34 PM, julien roche AKA indiana_jules wrote:
Hi all,
Can you try tabs with the last release of wiquery ? (the 1.1.1). A lot of
changes and refactoring were don into the core. Maybe that will solved
your
problems.
Can you give me your feedbacks please .
Thank you
Regards
Julien Roche
On Mon, Nov 29, 2010 at 9:33 PM, Brad Grier
wrote:
Okay, well...it's more than a contribution problem. It looks like the
tab's
associated div, ul and li tags do not get modified by wiquery in 1.4.14.
WiQuery assigns classes to these tags (ui-tabs, ui-tabs-nav,
ui-state-default, etc). Those are all missing when I run in Wicket
1.4.14.
Since it works fine for you, I'm not sure where to look.
-Original Message- From: Brian Topping
Sent: Monday, November 29, 2010 2:04 PM
To: users@wicket.apache.org
Subject: Re: Wicket 1.4.14 and WiQuery Tabs
On Nov 29, 2010, at 3:02 PM, Brian Topping wrote:
On Nov 29, 2010, at 2:39 PM, Brad Grier wrote:
My tabs are on panels that get swapped in and out via ajax. Are you
using
this approach?
They are ajax, but I haven't bothered looking at how it works. Here's
what I use in populateItem():
mainContentPanel =
cp.loadComponentInstance("mainContentPanel");
mainContentPanel.setOutputMarkupId(true);
AdminPage.this.replace(mainContentPanel);
target.addComponent(mainContentPanel);
Erm, that should have been "what I use in my onClick()"...
-
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: component not visible exception
That seems more likely to me. Is there anything I could do to prevent this? D/ On Nov 29, 2010, at 1:21 PM, Igor Vaynberg wrote: > another possibility, if this page is using hybrid url coding strategy, > is that the session expires and the form is submitted against a new > instance of the page - where the button is not visible. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4.14 and WiQuery Tabs
Ah, great point. I am already using 1.1.1!
On Nov 29, 2010, at 4:34 PM, julien roche AKA indiana_jules wrote:
> Hi all,
>
> Can you try tabs with the last release of wiquery ? (the 1.1.1). A lot of
> changes and refactoring were don into the core. Maybe that will solved your
> problems.
>
> Can you give me your feedbacks please .
>
> Thank you
>
> Regards
>
> Julien Roche
>
> On Mon, Nov 29, 2010 at 9:33 PM, Brad Grier wrote:
>
>> Okay, well...it's more than a contribution problem. It looks like the tab's
>> associated div, ul and li tags do not get modified by wiquery in 1.4.14.
>> WiQuery assigns classes to these tags (ui-tabs, ui-tabs-nav,
>> ui-state-default, etc). Those are all missing when I run in Wicket 1.4.14.
>>
>> Since it works fine for you, I'm not sure where to look.
>>
>>
>>
>> -Original Message- From: Brian Topping
>> Sent: Monday, November 29, 2010 2:04 PM
>>
>> To: users@wicket.apache.org
>> Subject: Re: Wicket 1.4.14 and WiQuery Tabs
>>
>>
>> On Nov 29, 2010, at 3:02 PM, Brian Topping wrote:
>>
>>
>>> On Nov 29, 2010, at 2:39 PM, Brad Grier wrote:
>>>
>>> My tabs are on panels that get swapped in and out via ajax. Are you using
this approach?
>>>
>>> They are ajax, but I haven't bothered looking at how it works. Here's
>>> what I use in populateItem():
>>>
>>> mainContentPanel =
cp.loadComponentInstance("mainContentPanel");
mainContentPanel.setOutputMarkupId(true);
AdminPage.this.replace(mainContentPanel);
target.addComponent(mainContentPanel);
>>>
>> Erm, that should have been "what I use in my onClick()"...
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4.14 and WiQuery Tabs
Hi all,
Can you try tabs with the last release of wiquery ? (the 1.1.1). A lot of
changes and refactoring were don into the core. Maybe that will solved your
problems.
Can you give me your feedbacks please .
Thank you
Regards
Julien Roche
On Mon, Nov 29, 2010 at 9:33 PM, Brad Grier wrote:
> Okay, well...it's more than a contribution problem. It looks like the tab's
> associated div, ul and li tags do not get modified by wiquery in 1.4.14.
> WiQuery assigns classes to these tags (ui-tabs, ui-tabs-nav,
> ui-state-default, etc). Those are all missing when I run in Wicket 1.4.14.
>
> Since it works fine for you, I'm not sure where to look.
>
>
>
> -Original Message- From: Brian Topping
> Sent: Monday, November 29, 2010 2:04 PM
>
> To: users@wicket.apache.org
> Subject: Re: Wicket 1.4.14 and WiQuery Tabs
>
>
> On Nov 29, 2010, at 3:02 PM, Brian Topping wrote:
>
>
>> On Nov 29, 2010, at 2:39 PM, Brad Grier wrote:
>>
>> My tabs are on panels that get swapped in and out via ajax. Are you using
>>> this approach?
>>>
>>
>> They are ajax, but I haven't bothered looking at how it works. Here's
>> what I use in populateItem():
>>
>>mainContentPanel =
>>> cp.loadComponentInstance("mainContentPanel");
>>> mainContentPanel.setOutputMarkupId(true);
>>> AdminPage.this.replace(mainContentPanel);
>>> target.addComponent(mainContentPanel);
>>>
>>
> Erm, that should have been "what I use in my onClick()"...
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: Wicket 1.4.14 and WiQuery Tabs
Okay, well...it's more than a contribution problem. It looks like the tab's
associated div, ul and li tags do not get modified by wiquery in 1.4.14.
WiQuery assigns classes to these tags (ui-tabs, ui-tabs-nav,
ui-state-default, etc). Those are all missing when I run in Wicket 1.4.14.
Since it works fine for you, I'm not sure where to look.
-Original Message-
From: Brian Topping
Sent: Monday, November 29, 2010 2:04 PM
To: users@wicket.apache.org
Subject: Re: Wicket 1.4.14 and WiQuery Tabs
On Nov 29, 2010, at 3:02 PM, Brian Topping wrote:
On Nov 29, 2010, at 2:39 PM, Brad Grier wrote:
My tabs are on panels that get swapped in and out via ajax. Are you using
this approach?
They are ajax, but I haven't bothered looking at how it works. Here's
what I use in populateItem():
mainContentPanel =
cp.loadComponentInstance("mainContentPanel");
mainContentPanel.setOutputMarkupId(true);
AdminPage.this.replace(mainContentPanel);
target.addComponent(mainContentPanel);
Erm, that should have been "what I use in my onClick()"...
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4.14 and WiQuery Tabs
On Nov 29, 2010, at 3:02 PM, Brian Topping wrote:
>
> On Nov 29, 2010, at 2:39 PM, Brad Grier wrote:
>
>> My tabs are on panels that get swapped in and out via ajax. Are you using
>> this approach?
>
> They are ajax, but I haven't bothered looking at how it works. Here's what I
> use in populateItem():
>
>>mainContentPanel =
>> cp.loadComponentInstance("mainContentPanel");
>>mainContentPanel.setOutputMarkupId(true);
>>AdminPage.this.replace(mainContentPanel);
>>target.addComponent(mainContentPanel);
Erm, that should have been "what I use in my onClick()"...
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4.14 and WiQuery Tabs
On Nov 29, 2010, at 2:39 PM, Brad Grier wrote:
> My tabs are on panels that get swapped in and out via ajax. Are you using
> this approach?
They are ajax, but I haven't bothered looking at how it works. Here's what I
use in populateItem():
> mainContentPanel =
> cp.loadComponentInstance("mainContentPanel");
> mainContentPanel.setOutputMarkupId(true);
> AdminPage.this.replace(mainContentPanel);
> target.addComponent(mainContentPanel);
Hopefully that's relatively future-proof...
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4.14 and WiQuery Tabs
Hey thanks for trying it. My tabs are on panels that get swapped in and out via ajax. Are you using this approach? Since our app creates these tabs dynamically via ListViews, I thought maybe it was my implementation. As a test I took the most basic tab example from the wiQuery site and put it on a panel displayed via ajax when a link is clicked. It's not working either. If I go back to 1.4.12, it works fine. I'll poke around a little with Firebug but I'm guessing the css and perhaps javascript aren't being contributed in my scenario. -Original Message- From: Brian Topping Sent: Monday, November 29, 2010 12:27 PM To: users@wicket.apache.org Subject: Re: Wicket 1.4.14 and WiQuery Tabs On Nov 29, 2010, at 12:04 PM, Brad Grier wrote: After 1.4.14 wiquery tab components no longer render in my application. These tabs are sitting on panels displayed via ajax so perhaps it’s something to do with the css/javascript contribution. Interestingly the wiquery accordions still work fine. Since I was due to upgrade this as well and am using both wiquery accordions and tabs, I thought I would give it a try. My tabs are on panels that are triggered by selections in the accordions (hey, are we working on the same source tree? ;-)). But I'm unable to replicate this, everything is rendering fine. If I can assist by checking any specific rendering or you want a snippet of the HTML that's being generated on my end to help you debug, feel free to contact me off-list. - 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: component not visible exception
another possibility, if this page is using hybrid url coding strategy, is that the session expires and the form is submitted against a new instance of the page - where the button is not visible. -igor On Mon, Nov 29, 2010 at 11:05 AM, Douglas Ferguson wrote: > The problem is that I can't recreate this error, but I see it in production > alot. > > So I have no way of looking at the action url. > > D/ > > > On Nov 29, 2010, at 12:59 PM, Igor Vaynberg wrote: > >> easy. >> >> the form's action url points to a version of the page where the button >> is not visible. so when the button is clicked and the form is >> submitted wicket rolls back the version of the page to one where >> button is not visible and you get the error. not sure that is what is >> happening in your app, but its one possible explanation. look at >> form's url and make sure none of your ajax actions are changing the >> page version. >> >> -igor >> >> On Mon, Nov 29, 2010 at 10:41 AM, Douglas Ferguson >> wrote: >>> We do toggle the visibility of the web markup container that contains the >>> button. >>> >>> Here's how it works. >>> >>> 1) Page loads and the container is hidden >>> 2) An ajax timer is used to watch for state to change >>> 3) When state changes we make the container visible (which then makes the >>> submit button visible) >>> >>> How could they user manage to click on the save button when is it not >>> visible? >>> >>> The only thing I can think of is that this could be some back button issue. >>> But then again, I'm not sure how that would manifest... >>> >>> D/ >>> >>> On Nov 29, 2010, at 11:25 AM, Igor Vaynberg wrote: >>> in order for component to be visible all of its parents have to be visible from the page down to the component. same for the enabled state. -igor On Mon, Nov 29, 2010 at 9:21 AM, Douglas Ferguson wrote: > Hmm... even if we aren't changing the visibility of the button? > > On Nov 29, 2010, at 10:42 AM, Marco Mancini wrote: > >> try to set >> >> mybutton.setOutputMarkupPlaceholderTag(true); >> >> bye >> marco >> >> 2010/11/29 Martin Grigorov >> >>> On Mon, Nov 29, 2010 at 4:46 PM, Douglas Ferguson < >>> doug...@douglasferguson.us> wrote: >>> We have not overridden isVisible, nor have we do we have a popup modal. That's why I was asking if this could be a back button issue. The only thing we do is set the button enabled. Could this be the problem even thought he message it talking about visibility? >>> No. There is a separate check for enabled state. It is definitely for >>> visibility. >>> D/ On Nov 29, 2010, at 3:15 AM, Martin Grigorov wrote: > Here is another scenario: > > Ajax request sets the visibility of the submit button (or its parent) >>> to > false but forgets to repaint the button so it is still visible for the user. > Then the user clicks on this button, it fires and then the backend >>> shows > this message - the button is invisible so it cannot be clicked. > > On Mon, Nov 29, 2010 at 9:04 AM, Chris Colman > wrote: > >> A back button where? >> >> The form is on a page and has a submit button only. If there is an >>> error >> a ModalWindow pops up - it only has an OK button which is meant to >>> make >> the ModalWindow simply disappear and thus re-enable the page beneath >> - >> the one with the form on it. >> >> Chris >>> -Original Message- >>> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >>> Sent: Monday, 29 November 2010 6:53 PM >>> To: users@wicket.apache.org >>> Subject: Re: component not visible exception >>> >>> Could this be happening because of the back button? >>> >>> D/ >>> >>> On Nov 28, 2010, at 4:54 AM, Chris Colman wrote: >>> I had a similar problem. In my scenario it occurred when a >> ModalWindow was brought up when a form failed validation. When they clicked ok >>> to close the ModalWindow and then clicked Submit on the form again I >>> got >> a similar message saying that the Submit button was no longer visible. It doesn't happen if I use the normal validation 'feedback' panel to display the validation error messages. Chris > -Original Message- > From: Douglas Ferguson [mailto:doug...@douglasferguson.us] > Sent: Saturday, 27 November 2010 3:13 AM > To: Wicket Mailing List List > Subject: component not visible exce
Re: component not visible exception
The problem is that I can't recreate this error, but I see it in production alot. So I have no way of looking at the action url. D/ On Nov 29, 2010, at 12:59 PM, Igor Vaynberg wrote: > easy. > > the form's action url points to a version of the page where the button > is not visible. so when the button is clicked and the form is > submitted wicket rolls back the version of the page to one where > button is not visible and you get the error. not sure that is what is > happening in your app, but its one possible explanation. look at > form's url and make sure none of your ajax actions are changing the > page version. > > -igor > > On Mon, Nov 29, 2010 at 10:41 AM, Douglas Ferguson > wrote: >> We do toggle the visibility of the web markup container that contains the >> button. >> >> Here's how it works. >> >> 1) Page loads and the container is hidden >> 2) An ajax timer is used to watch for state to change >> 3) When state changes we make the container visible (which then makes the >> submit button visible) >> >> How could they user manage to click on the save button when is it not >> visible? >> >> The only thing I can think of is that this could be some back button issue. >> But then again, I'm not sure how that would manifest... >> >> D/ >> >> On Nov 29, 2010, at 11:25 AM, Igor Vaynberg wrote: >> >>> in order for component to be visible all of its parents have to be >>> visible from the page down to the component. same for the enabled >>> state. >>> >>> -igor >>> >>> On Mon, Nov 29, 2010 at 9:21 AM, Douglas Ferguson >>> wrote: Hmm... even if we aren't changing the visibility of the button? On Nov 29, 2010, at 10:42 AM, Marco Mancini wrote: > try to set > > mybutton.setOutputMarkupPlaceholderTag(true); > > bye > marco > > 2010/11/29 Martin Grigorov > >> On Mon, Nov 29, 2010 at 4:46 PM, Douglas Ferguson < >> doug...@douglasferguson.us> wrote: >> >>> We have not overridden isVisible, nor have we do we have a popup modal. >>> That's why I was asking if this could be a back button issue. >>> >>> The only thing we do is set the button enabled. Could this be the >>> problem >>> even thought he message it talking about visibility? >>> >> No. There is a separate check for enabled state. It is definitely for >> visibility. >> >>> >>> D/ >>> >>> On Nov 29, 2010, at 3:15 AM, Martin Grigorov wrote: >>> Here is another scenario: Ajax request sets the visibility of the submit button (or its parent) >> to false but forgets to repaint the button so it is still visible for the >>> user. Then the user clicks on this button, it fires and then the backend >> shows this message - the button is invisible so it cannot be clicked. On Mon, Nov 29, 2010 at 9:04 AM, Chris Colman wrote: > A back button where? > > The form is on a page and has a submit button only. If there is an >> error > a ModalWindow pops up - it only has an OK button which is meant to >> make > the ModalWindow simply disappear and thus re-enable the page beneath - > the one with the form on it. > > Chris >> -Original Message- >> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >> Sent: Monday, 29 November 2010 6:53 PM >> To: users@wicket.apache.org >> Subject: Re: component not visible exception >> >> Could this be happening because of the back button? >> >> D/ >> >> On Nov 28, 2010, at 4:54 AM, Chris Colman wrote: >> >>> I had a similar problem. In my scenario it occurred when a > ModalWindow >>> was brought up when a form failed validation. When they clicked ok >> to >>> close the ModalWindow and then clicked Submit on the form again I >> got > a >>> similar message saying that the Submit button was no longer visible. >>> >>> It doesn't happen if I use the normal validation 'feedback' panel to >>> display the validation error messages. >>> >>> Chris >>> -Original Message- From: Douglas Ferguson [mailto:doug...@douglasferguson.us] Sent: Saturday, 27 November 2010 3:13 AM To: Wicket Mailing List List Subject: component not visible exception I have an error I've been seeing in the production logs for awhile > now >>> and haven't been able to to figure it out. My thought is that it is due to a stale page or the back button, >> but > it seems to me that it is happening alot, so I thought I might >> inquire. >>
Re: component not visible exception
easy. the form's action url points to a version of the page where the button is not visible. so when the button is clicked and the form is submitted wicket rolls back the version of the page to one where button is not visible and you get the error. not sure that is what is happening in your app, but its one possible explanation. look at form's url and make sure none of your ajax actions are changing the page version. -igor On Mon, Nov 29, 2010 at 10:41 AM, Douglas Ferguson wrote: > We do toggle the visibility of the web markup container that contains the > button. > > Here's how it works. > > 1) Page loads and the container is hidden > 2) An ajax timer is used to watch for state to change > 3) When state changes we make the container visible (which then makes the > submit button visible) > > How could they user manage to click on the save button when is it not visible? > > The only thing I can think of is that this could be some back button issue. > But then again, I'm not sure how that would manifest... > > D/ > > On Nov 29, 2010, at 11:25 AM, Igor Vaynberg wrote: > >> in order for component to be visible all of its parents have to be >> visible from the page down to the component. same for the enabled >> state. >> >> -igor >> >> On Mon, Nov 29, 2010 at 9:21 AM, Douglas Ferguson >> wrote: >>> Hmm... even if we aren't changing the visibility of the button? >>> >>> On Nov 29, 2010, at 10:42 AM, Marco Mancini wrote: >>> try to set mybutton.setOutputMarkupPlaceholderTag(true); bye marco 2010/11/29 Martin Grigorov > On Mon, Nov 29, 2010 at 4:46 PM, Douglas Ferguson < > doug...@douglasferguson.us> wrote: > >> We have not overridden isVisible, nor have we do we have a popup modal. >> That's why I was asking if this could be a back button issue. >> >> The only thing we do is set the button enabled. Could this be the problem >> even thought he message it talking about visibility? >> > No. There is a separate check for enabled state. It is definitely for > visibility. > >> >> D/ >> >> On Nov 29, 2010, at 3:15 AM, Martin Grigorov wrote: >> >>> Here is another scenario: >>> >>> Ajax request sets the visibility of the submit button (or its parent) > to >>> false but forgets to repaint the button so it is still visible for the >> user. >>> Then the user clicks on this button, it fires and then the backend > shows >>> this message - the button is invisible so it cannot be clicked. >>> >>> On Mon, Nov 29, 2010 at 9:04 AM, Chris Colman >>> wrote: >>> A back button where? The form is on a page and has a submit button only. If there is an > error a ModalWindow pops up - it only has an OK button which is meant to > make the ModalWindow simply disappear and thus re-enable the page beneath - the one with the form on it. Chris > -Original Message- > From: Douglas Ferguson [mailto:doug...@douglasferguson.us] > Sent: Monday, 29 November 2010 6:53 PM > To: users@wicket.apache.org > Subject: Re: component not visible exception > > Could this be happening because of the back button? > > D/ > > On Nov 28, 2010, at 4:54 AM, Chris Colman wrote: > >> I had a similar problem. In my scenario it occurred when a ModalWindow >> was brought up when a form failed validation. When they clicked ok > to >> close the ModalWindow and then clicked Submit on the form again I > got a >> similar message saying that the Submit button was no longer visible. >> >> It doesn't happen if I use the normal validation 'feedback' panel to >> display the validation error messages. >> >> Chris >> >>> -Original Message- >>> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >>> Sent: Saturday, 27 November 2010 3:13 AM >>> To: Wicket Mailing List List >>> Subject: component not visible exception >>> >>> I have an error I've been seeing in the production logs for awhile now >> and >>> haven't been able to to figure it out. >>> >>> My thought is that it is due to a stale page or the back button, > but it >>> seems to me that it is happening alot, so I thought I might > inquire. >>> >>> Any thoughts on what might be causing this and how to avoid it? >>> >>> 2010-11-26 08:36:36,676 ERROR [TP-Processor34] wicket.RequestCycle > - >> Submit >>> Button add (path=dataPanel:contentCenterBox:addUserForm:add) is not >> visible >>> org.apache.wicket.WicketRuntimeException: Submit Button add >>> (path=dataPanel:cont
Re: component not visible exception
We do toggle the visibility of the web markup container that contains the button. Here's how it works. 1) Page loads and the container is hidden 2) An ajax timer is used to watch for state to change 3) When state changes we make the container visible (which then makes the submit button visible) How could they user manage to click on the save button when is it not visible? The only thing I can think of is that this could be some back button issue. But then again, I'm not sure how that would manifest... D/ On Nov 29, 2010, at 11:25 AM, Igor Vaynberg wrote: > in order for component to be visible all of its parents have to be > visible from the page down to the component. same for the enabled > state. > > -igor > > On Mon, Nov 29, 2010 at 9:21 AM, Douglas Ferguson > wrote: >> Hmm... even if we aren't changing the visibility of the button? >> >> On Nov 29, 2010, at 10:42 AM, Marco Mancini wrote: >> >>> try to set >>> >>> mybutton.setOutputMarkupPlaceholderTag(true); >>> >>> bye >>> marco >>> >>> 2010/11/29 Martin Grigorov >>> On Mon, Nov 29, 2010 at 4:46 PM, Douglas Ferguson < doug...@douglasferguson.us> wrote: > We have not overridden isVisible, nor have we do we have a popup modal. > That's why I was asking if this could be a back button issue. > > The only thing we do is set the button enabled. Could this be the problem > even thought he message it talking about visibility? > No. There is a separate check for enabled state. It is definitely for visibility. > > D/ > > On Nov 29, 2010, at 3:15 AM, Martin Grigorov wrote: > >> Here is another scenario: >> >> Ajax request sets the visibility of the submit button (or its parent) to >> false but forgets to repaint the button so it is still visible for the > user. >> Then the user clicks on this button, it fires and then the backend shows >> this message - the button is invisible so it cannot be clicked. >> >> On Mon, Nov 29, 2010 at 9:04 AM, Chris Colman >> wrote: >> >>> A back button where? >>> >>> The form is on a page and has a submit button only. If there is an error >>> a ModalWindow pops up - it only has an OK button which is meant to make >>> the ModalWindow simply disappear and thus re-enable the page beneath - >>> the one with the form on it. >>> >>> Chris -Original Message- From: Douglas Ferguson [mailto:doug...@douglasferguson.us] Sent: Monday, 29 November 2010 6:53 PM To: users@wicket.apache.org Subject: Re: component not visible exception Could this be happening because of the back button? D/ On Nov 28, 2010, at 4:54 AM, Chris Colman wrote: > I had a similar problem. In my scenario it occurred when a >>> ModalWindow > was brought up when a form failed validation. When they clicked ok to > close the ModalWindow and then clicked Submit on the form again I got >>> a > similar message saying that the Submit button was no longer visible. > > It doesn't happen if I use the normal validation 'feedback' panel to > display the validation error messages. > > Chris > >> -Original Message- >> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >> Sent: Saturday, 27 November 2010 3:13 AM >> To: Wicket Mailing List List >> Subject: component not visible exception >> >> I have an error I've been seeing in the production logs for awhile >>> now > and >> haven't been able to to figure it out. >> >> My thought is that it is due to a stale page or the back button, but >>> it >> seems to me that it is happening alot, so I thought I might inquire. >> >> Any thoughts on what might be causing this and how to avoid it? >> >> 2010-11-26 08:36:36,676 ERROR [TP-Processor34] wicket.RequestCycle - > Submit >> Button add (path=dataPanel:contentCenterBox:addUserForm:add) is not > visible >> org.apache.wicket.WicketRuntimeException: Submit Button add >> (path=dataPanel:contentCenterBox:addUserForm:add) is not visible >> at > org.apache.wicket.markup.html.form.Form$2.component(Form.java:622) >> at >> >>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:89 > 9) >> at >> >>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 > 4) >> at >> >>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 > 4) >> at >> >>> org.apache.wicket.MarkupContainer.visitC
Re: Wicket 1.4.14 and WiQuery Tabs
On Nov 29, 2010, at 12:04 PM, Brad Grier wrote: > After 1.4.14 wiquery tab components no longer render in my application. These > tabs are sitting on panels displayed via ajax so perhaps it’s something to do > with the css/javascript contribution. Interestingly the wiquery accordions > still work fine. Since I was due to upgrade this as well and am using both wiquery accordions and tabs, I thought I would give it a try. My tabs are on panels that are triggered by selections in the accordions (hey, are we working on the same source tree? ;-)). But I'm unable to replicate this, everything is rendering fine. If I can assist by checking any specific rendering or you want a snippet of the HTML that's being generated on my end to help you debug, feel free to contact me off-list. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: DatePicker to pick a year
That works, thanks. I just wonder how users will be able to figure it out.
On Mon, Nov 29, 2010 at 11:56 AM, Marco Mancini wrote:
> in this page the problem is dateformat... but he can switch year
> https://issues.apache.org/jira/browse/WICKET-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846200#action_12846200
>
>
>
> try to click on month name for change year!
>
>
>
> 2010/11/29 Anna Simbirtsev
>
>> It does not work, only can switch between month, not year.
>>
>> On Mon, Nov 29, 2010 at 11:33 AM, Marco Mancini
>> wrote:
>> > try this code:
>> >
>> > DatePicker mydp= new DatePicker(){
>> > private static final long serialVersionUID = 1L;
>> >
>> > �...@override
>> > protected boolean enableMonthYearSelection() {
>> > return true;
>> > }
>> > };
>> >
>> > 2010/11/29 Anna Simbirtsev
>> >
>> >> Hi,
>> >>
>> >> Is it possible to get datapicker to switch between year, currently
>> >> there are arrows to only switch between month?
>> >>
>> >> Thanks,
>> >> Anna
>> >>
>> >> -
>> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> >> For additional commands, e-mail: users-h...@wicket.apache.org
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Anna Simbirtsev
>> (416) 729-7331
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
--
Anna Simbirtsev
(416) 729-7331
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Preventing user input script-injection attacks
Igor I was unaware of the class org.apache.wicket.util.string.Strings, let alone that package. The Strings.escapeMarkup(...) method you mentioned fits my needs exactly. Thank you. Michał -- Thank you also for your tip. I shall be using the Wicket method that Igor mentioned. I shall also be having a play with that package to see what else is there! Regards, Ian -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Preventing-user-input-script-injection-attacks-tp3059119p3064004.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: component not visible exception
in order for component to be visible all of its parents have to be visible from the page down to the component. same for the enabled state. -igor On Mon, Nov 29, 2010 at 9:21 AM, Douglas Ferguson wrote: > Hmm... even if we aren't changing the visibility of the button? > > On Nov 29, 2010, at 10:42 AM, Marco Mancini wrote: > >> try to set >> >> mybutton.setOutputMarkupPlaceholderTag(true); >> >> bye >> marco >> >> 2010/11/29 Martin Grigorov >> >>> On Mon, Nov 29, 2010 at 4:46 PM, Douglas Ferguson < >>> doug...@douglasferguson.us> wrote: >>> We have not overridden isVisible, nor have we do we have a popup modal. That's why I was asking if this could be a back button issue. The only thing we do is set the button enabled. Could this be the problem even thought he message it talking about visibility? >>> No. There is a separate check for enabled state. It is definitely for >>> visibility. >>> D/ On Nov 29, 2010, at 3:15 AM, Martin Grigorov wrote: > Here is another scenario: > > Ajax request sets the visibility of the submit button (or its parent) >>> to > false but forgets to repaint the button so it is still visible for the user. > Then the user clicks on this button, it fires and then the backend >>> shows > this message - the button is invisible so it cannot be clicked. > > On Mon, Nov 29, 2010 at 9:04 AM, Chris Colman > wrote: > >> A back button where? >> >> The form is on a page and has a submit button only. If there is an >>> error >> a ModalWindow pops up - it only has an OK button which is meant to >>> make >> the ModalWindow simply disappear and thus re-enable the page beneath - >> the one with the form on it. >> >> Chris >>> -Original Message- >>> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >>> Sent: Monday, 29 November 2010 6:53 PM >>> To: users@wicket.apache.org >>> Subject: Re: component not visible exception >>> >>> Could this be happening because of the back button? >>> >>> D/ >>> >>> On Nov 28, 2010, at 4:54 AM, Chris Colman wrote: >>> I had a similar problem. In my scenario it occurred when a >> ModalWindow was brought up when a form failed validation. When they clicked ok >>> to close the ModalWindow and then clicked Submit on the form again I >>> got >> a similar message saying that the Submit button was no longer visible. It doesn't happen if I use the normal validation 'feedback' panel to display the validation error messages. Chris > -Original Message- > From: Douglas Ferguson [mailto:doug...@douglasferguson.us] > Sent: Saturday, 27 November 2010 3:13 AM > To: Wicket Mailing List List > Subject: component not visible exception > > I have an error I've been seeing in the production logs for awhile >> now and > haven't been able to to figure it out. > > My thought is that it is due to a stale page or the back button, >>> but >> it > seems to me that it is happening alot, so I thought I might >>> inquire. > > Any thoughts on what might be causing this and how to avoid it? > > 2010-11-26 08:36:36,676 ERROR [TP-Processor34] wicket.RequestCycle >>> - Submit > Button add (path=dataPanel:contentCenterBox:addUserForm:add) is not visible > org.apache.wicket.WicketRuntimeException: Submit Button add > (path=dataPanel:contentCenterBox:addUserForm:add) is not visible > at org.apache.wicket.markup.html.form.Form$2.component(Form.java:622) > at > >> >>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:89 9) > at > >> >>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 4) > at > >> >>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 4) > at > >> >>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 4) > at > >> >>> org.apache.wicket.markup.html.form.Form.findSubmittingButton(Form.java: 604) > at > >> org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:899) > at > >> >>> org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubm itBe > havior.java:135) > at > >> >>> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java :177 > ) > at > >> >>> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDe faul > tAjaxBehavior.java:300) > at > >> >>> org.ap
Re: component not visible exception
Hmm... even if we aren't changing the visibility of the button? On Nov 29, 2010, at 10:42 AM, Marco Mancini wrote: > try to set > > mybutton.setOutputMarkupPlaceholderTag(true); > > bye > marco > > 2010/11/29 Martin Grigorov > >> On Mon, Nov 29, 2010 at 4:46 PM, Douglas Ferguson < >> doug...@douglasferguson.us> wrote: >> >>> We have not overridden isVisible, nor have we do we have a popup modal. >>> That's why I was asking if this could be a back button issue. >>> >>> The only thing we do is set the button enabled. Could this be the problem >>> even thought he message it talking about visibility? >>> >> No. There is a separate check for enabled state. It is definitely for >> visibility. >> >>> >>> D/ >>> >>> On Nov 29, 2010, at 3:15 AM, Martin Grigorov wrote: >>> Here is another scenario: Ajax request sets the visibility of the submit button (or its parent) >> to false but forgets to repaint the button so it is still visible for the >>> user. Then the user clicks on this button, it fires and then the backend >> shows this message - the button is invisible so it cannot be clicked. On Mon, Nov 29, 2010 at 9:04 AM, Chris Colman wrote: > A back button where? > > The form is on a page and has a submit button only. If there is an >> error > a ModalWindow pops up - it only has an OK button which is meant to >> make > the ModalWindow simply disappear and thus re-enable the page beneath - > the one with the form on it. > > Chris >> -Original Message- >> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >> Sent: Monday, 29 November 2010 6:53 PM >> To: users@wicket.apache.org >> Subject: Re: component not visible exception >> >> Could this be happening because of the back button? >> >> D/ >> >> On Nov 28, 2010, at 4:54 AM, Chris Colman wrote: >> >>> I had a similar problem. In my scenario it occurred when a > ModalWindow >>> was brought up when a form failed validation. When they clicked ok >> to >>> close the ModalWindow and then clicked Submit on the form again I >> got > a >>> similar message saying that the Submit button was no longer visible. >>> >>> It doesn't happen if I use the normal validation 'feedback' panel to >>> display the validation error messages. >>> >>> Chris >>> -Original Message- From: Douglas Ferguson [mailto:doug...@douglasferguson.us] Sent: Saturday, 27 November 2010 3:13 AM To: Wicket Mailing List List Subject: component not visible exception I have an error I've been seeing in the production logs for awhile > now >>> and haven't been able to to figure it out. My thought is that it is due to a stale page or the back button, >> but > it seems to me that it is happening alot, so I thought I might >> inquire. Any thoughts on what might be causing this and how to avoid it? 2010-11-26 08:36:36,676 ERROR [TP-Processor34] wicket.RequestCycle >> - >>> Submit Button add (path=dataPanel:contentCenterBox:addUserForm:add) is not >>> visible org.apache.wicket.WicketRuntimeException: Submit Button add (path=dataPanel:contentCenterBox:addUserForm:add) is not visible at >>> org.apache.wicket.markup.html.form.Form$2.component(Form.java:622) at > >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:89 >>> 9) at > >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 >>> 4) at > >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 >>> 4) at > >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 >>> 4) at > >> org.apache.wicket.markup.html.form.Form.findSubmittingButton(Form.java: >>> 604) at > org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:899) at > >> org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubm >>> itBe havior.java:135) at > >> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java >>> :177 ) at > >> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDe >>> faul tAjaxBehavior.java:300) at > >> org.apache.wicket.request.target.component.listener.BehaviorRequestTarg >>> et.p rocessEvents(BehaviorRequestTarget.java:119) at > >> org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(A >>> bstr actRequestCycleProcessor.java:92) at
Re: component not visible exception
That is wierd.. the component is a field and is private. We don't set visible nor do we override isVisible(). Could this have to do with the parent container? We do set that visible... On Nov 29, 2010, at 9:58 AM, Martin Grigorov wrote: > On Mon, Nov 29, 2010 at 4:46 PM, Douglas Ferguson < > doug...@douglasferguson.us> wrote: > >> We have not overridden isVisible, nor have we do we have a popup modal. >> That's why I was asking if this could be a back button issue. >> >> The only thing we do is set the button enabled. Could this be the problem >> even thought he message it talking about visibility? >> > No. There is a separate check for enabled state. It is definitely for > visibility. > >> >> D/ >> >> On Nov 29, 2010, at 3:15 AM, Martin Grigorov wrote: >> >>> Here is another scenario: >>> >>> Ajax request sets the visibility of the submit button (or its parent) to >>> false but forgets to repaint the button so it is still visible for the >> user. >>> Then the user clicks on this button, it fires and then the backend shows >>> this message - the button is invisible so it cannot be clicked. >>> >>> On Mon, Nov 29, 2010 at 9:04 AM, Chris Colman >>> wrote: >>> A back button where? The form is on a page and has a submit button only. If there is an error a ModalWindow pops up - it only has an OK button which is meant to make the ModalWindow simply disappear and thus re-enable the page beneath - the one with the form on it. Chris > -Original Message- > From: Douglas Ferguson [mailto:doug...@douglasferguson.us] > Sent: Monday, 29 November 2010 6:53 PM > To: users@wicket.apache.org > Subject: Re: component not visible exception > > Could this be happening because of the back button? > > D/ > > On Nov 28, 2010, at 4:54 AM, Chris Colman wrote: > >> I had a similar problem. In my scenario it occurred when a ModalWindow >> was brought up when a form failed validation. When they clicked ok to >> close the ModalWindow and then clicked Submit on the form again I got a >> similar message saying that the Submit button was no longer visible. >> >> It doesn't happen if I use the normal validation 'feedback' panel to >> display the validation error messages. >> >> Chris >> >>> -Original Message- >>> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >>> Sent: Saturday, 27 November 2010 3:13 AM >>> To: Wicket Mailing List List >>> Subject: component not visible exception >>> >>> I have an error I've been seeing in the production logs for awhile now >> and >>> haven't been able to to figure it out. >>> >>> My thought is that it is due to a stale page or the back button, but it >>> seems to me that it is happening alot, so I thought I might inquire. >>> >>> Any thoughts on what might be causing this and how to avoid it? >>> >>> 2010-11-26 08:36:36,676 ERROR [TP-Processor34] wicket.RequestCycle - >> Submit >>> Button add (path=dataPanel:contentCenterBox:addUserForm:add) is not >> visible >>> org.apache.wicket.WicketRuntimeException: Submit Button add >>> (path=dataPanel:contentCenterBox:addUserForm:add) is not visible >>> at >> org.apache.wicket.markup.html.form.Form$2.component(Form.java:622) >>> at >>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:89 >> 9) >>> at >>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 >> 4) >>> at >>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 >> 4) >>> at >>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 >> 4) >>> at >>> org.apache.wicket.markup.html.form.Form.findSubmittingButton(Form.java: >> 604) >>> at >>> org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:899) >>> at >>> org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubm >> itBe >>> havior.java:135) >>> at >>> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java >> :177 >>> ) >>> at >>> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDe >> faul >>> tAjaxBehavior.java:300) >>> at >>> org.apache.wicket.request.target.component.listener.BehaviorRequestTarg >> et.p >>> rocessEvents(BehaviorRequestTarget.java:119) >>> at >>> org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(A >> bstr >>> actRequestCycleProcessor.java:92) >>> at >>> org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.jav >> a:12 >>> 50) >>> at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329) >>> at org.apac
SV: Painting a ListView in Ajax via a transparent container fails
> So this special component is designed to be aware of children components > only at the rendering time ( working with the markupStream ) and not at the > pre-rendering. As the ListView depends on pre-rendering logic, add an > transparent resolved component in ajax request target has no effect because > no children pre-rendering method will be invoked. Ah, that explains it! In this particular case the number of "real" top-level components is low enough that adding them explicitly is no big deal, so I now have an approach that seems to work. - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket 1.4.14 and WiQuery Tabs
After 1.4.14 wiquery tab components no longer render in my application. These tabs are sitting on panels displayed via ajax so perhaps it’s something to do with the css/javascript contribution. Interestingly the wiquery accordions still work fine.
Re: Wicket 1.4.14 > Bug with panels updated by Ajax rendering a CSS
Since upgrading the tabs from wiQuery 1.02 no longer work in my application. Could be related as the CSS isn't being picked up at all. These are tabs on panels displayed via ajax. -Original Message- From: Antoine Angenieux Sent: Monday, November 29, 2010 8:42 AM To: users@wicket.apache.org Subject: Wicket 1.4.14 > Bug with panels updated by Ajax rendering a CSS Hi all, I have just upgraded my dev environment from Wicket 1.4.13 to 1.4.14 this morning and discovered a bug related to CSS. On a page, I have a panel containing a listview, itself populated with panels that have in their constructor: add(CSSPackageResource.getHeaderContribution(CSS)); When browsing to this page, the listview is initially empty. When the panel is updated by an Ajax Link making the listview model list not empty, the list view contents are rendered, but the CSS is not (and the reference to the css script does not appear in the Wicket Ajax Debug Window), and thus the presentation is all messed up. I just downgraded back to Wicket 1.4.13, and all is fine. I don't have time to prepare a Quickstart yet, but if anyone who has been fixing bugs on Wicket 1.4.14 has a brilliant intuition on what can cause this regression, it would be great ;) Otherwise, I'll try to find sometime later this week to file a JIRA issue with a Quickstart. Cheers, Antoine. -- Antoine Angénieux Associé Clinigrid 5, avenue Mozart 75016 Paris, France +336 60 21 09 18 aangeni...@clinigrid.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: UploadProgressBar on nested forms
yeah, just add it to the outer form :)
-igor
On Mon, Nov 29, 2010 at 8:52 AM, Alec Swan wrote:
> Igor, thanks for fixing JIRA 3191. Based on your comment the progress bar
> will show up in all nested file upload forms when a single form is
> submitted.
>
> Is there a way to make the progress bar a child component of the outer form
> and display the bar on submission of any (or all) nested forms?
>
> Thanks,
>
> Alec
>
> On Wed, Nov 24, 2010 at 10:29 AM, Alec Swan wrote:
>
>> Done. JIRA 3191.
>>
>> Thanks
>>
>> On Tue, Nov 23, 2010 at 10:39 PM, Igor Vaynberg
>> wrote:
>> > file another issue with a new quickstart.
>> >
>> > -igor
>> >
>> > On Tue, Nov 23, 2010 at 8:45 PM, Alec Swan wrote:
>> >> Hello,
>> >>
>> >> Thank you for promptly fixing the problem with the upload progress bar
>> in
>> >> nested forms. I applied the fix by merging SVN changes into 1.4.13
>> branch
>> >> and rebuilding the JAR files.
>> >>
>> >> I verified that the original problem was fixed with the patched jars.
>> >> However, here is a new problem. If I have two upload forms, then upload
>> >> initiated in the first form shows progress bar in the second form. So,
>> if
>> >> the second form happens to be hidden (setVisible(false)), then the
>> upload
>> >> progress bar does not show up at all.
>> >>
>> >> Should I file another JIRA issue, add to the existing 3181 issue or
>> change
>> >> my code?
>> >>
>> >> Thanks
>> >>
>> >>
>> >> On Sat, Nov 20, 2010 at 5:59 PM, Alec Swan wrote:
>> >>
>> >>> I opened JIRA issue 3181:
>> >>> https://issues.apache.org/jira/browse/WICKET-3181. I attached a ZIP
>> >>> file with complete source to reproduce the issue and instructions on
>> >>> how to run it (I am sure you didn't need them).
>> >>>
>> >>> Please let me know if you can think of any other solutions for
>> >>> displaying a modal window from nested upload form.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Alec
>> >>>
>> >>> On Sat, Nov 20, 2010 at 1:35 PM, Igor Vaynberg <
>> igor.vaynb...@gmail.com>
>> >>> wrote:
>> >>> > not sure yet :) but a quickstart will give me a playground to explore
>> >>> > the options.
>> >>> >
>> >>> > -igor
>> >>> >
>> >>> > On Sat, Nov 20, 2010 at 12:20 PM, Alec Swan
>> wrote:
>> >>> >> I can file a bug, but I am curious how you are planning to fix this?
>> >>> >>
>> >>> >> I tried passing the OUTER form to UploadProgressBar, i.e.
>> >>> >> nestedForm.add(new UploadProgressBar("progress", outerForm)), but
>> that
>> >>> >> caused the following error to be logged in Firebug:
>> >>> >>
>> >>> >> Wicket.WUPB.get(def.statusid) is null
>> >>> >> [Break on this error]
>> Wicket.WUPB.get(def.statusid).innerHTML='Upload
>> >>> >> starting...';
>> >>> >> progressbar.js (line 41
>> >>> >>
>> >>> >> While I am filing a bug and waiting for a fix, are there any
>> >>> >> suggestions on how to show a modal window during files upload
>> >>> >> initiated from a nested form?
>> >>> >>
>> >>> >> Thanks
>> >>> >>
>> >>> >> On Sat, Nov 20, 2010 at 1:05 PM, Igor Vaynberg <
>> igor.vaynb...@gmail.com>
>> >>> wrote:
>> >>> >>> sounds like a bug. open a jira ticket, attach a quickstart.
>> >>> >>>
>> >>> >>> -igor
>> >>> >>>
>> >>> >>> On Sat, Nov 20, 2010 at 11:22 AM, Alec Swan
>> >>> wrote:
>> >>> Hello,
>> >>>
>> >>> I have a page which contains a form around a table. Each row in
>> the
>> >>> table contains a nested form which allows user to upload a file
>> for
>> >>> the row. I added an UploadProgressBar to the upload form in each
>> row.
>> >>> However, the upload progress bars are never shown.
>> >>>
>> >>> I understand that Wicket replaces a nested with and
>> adds
>> >>> onsubmit event handler to display UploadProgressBar. However,
>> since
>> >>> the was replaced with onsubmit handler never fires.
>> >>>
>> >>> How can I display a progress bar or at least a modal window during
>> a
>> >>> file upload from a nested form?
>> >>>
>> >>> Thanks!
>> >>>
>> >>>
>> -
>> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> >>> For additional commands, e-mail: users-h...@wicket.apache.org
>> >>>
>> >>>
>> >>> >>>
>> >>> >>>
>> -
>> >>> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> >>> >>> For additional commands, e-mail: users-h...@wicket.apache.org
>> >>> >>>
>> >>> >>>
>> >>> >>
>> >>> >>
>> -
>> >>> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> >>> >> For additional commands, e-mail: users-h...@wicket.apache.org
>> >>> >>
>> >>> >>
>> >>> >
>> >>> > -
>> >>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> >>> > For additional commands, e-mail: users-h...@wicket.apache.org
>> >>> >
>>
Re: DatePicker to pick a year
in this page the problem is dateformat... but he can switch year
https://issues.apache.org/jira/browse/WICKET-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846200#action_12846200
try to click on month name for change year!
2010/11/29 Anna Simbirtsev
> It does not work, only can switch between month, not year.
>
> On Mon, Nov 29, 2010 at 11:33 AM, Marco Mancini
> wrote:
> > try this code:
> >
> > DatePicker mydp= new DatePicker(){
> >private static final long serialVersionUID = 1L;
> >
> >@Override
> >protected boolean enableMonthYearSelection() {
> >return true;
> >}
> >};
> >
> > 2010/11/29 Anna Simbirtsev
> >
> >> Hi,
> >>
> >> Is it possible to get datapicker to switch between year, currently
> >> there are arrows to only switch between month?
> >>
> >> Thanks,
> >> Anna
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >>
> >
>
>
>
> --
> Anna Simbirtsev
> (416) 729-7331
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: WebMarkupContainer issue
That was a just typo in the question It is Do you have any other ideas ? Thank you very much ! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/WebMarkupContainer-issue-tp3063886p3063922.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: UploadProgressBar on nested forms
Igor, thanks for fixing JIRA 3191. Based on your comment the progress bar
will show up in all nested file upload forms when a single form is
submitted.
Is there a way to make the progress bar a child component of the outer form
and display the bar on submission of any (or all) nested forms?
Thanks,
Alec
On Wed, Nov 24, 2010 at 10:29 AM, Alec Swan wrote:
> Done. JIRA 3191.
>
> Thanks
>
> On Tue, Nov 23, 2010 at 10:39 PM, Igor Vaynberg
> wrote:
> > file another issue with a new quickstart.
> >
> > -igor
> >
> > On Tue, Nov 23, 2010 at 8:45 PM, Alec Swan wrote:
> >> Hello,
> >>
> >> Thank you for promptly fixing the problem with the upload progress bar
> in
> >> nested forms. I applied the fix by merging SVN changes into 1.4.13
> branch
> >> and rebuilding the JAR files.
> >>
> >> I verified that the original problem was fixed with the patched jars.
> >> However, here is a new problem. If I have two upload forms, then upload
> >> initiated in the first form shows progress bar in the second form. So,
> if
> >> the second form happens to be hidden (setVisible(false)), then the
> upload
> >> progress bar does not show up at all.
> >>
> >> Should I file another JIRA issue, add to the existing 3181 issue or
> change
> >> my code?
> >>
> >> Thanks
> >>
> >>
> >> On Sat, Nov 20, 2010 at 5:59 PM, Alec Swan wrote:
> >>
> >>> I opened JIRA issue 3181:
> >>> https://issues.apache.org/jira/browse/WICKET-3181. I attached a ZIP
> >>> file with complete source to reproduce the issue and instructions on
> >>> how to run it (I am sure you didn't need them).
> >>>
> >>> Please let me know if you can think of any other solutions for
> >>> displaying a modal window from nested upload form.
> >>>
> >>> Thanks,
> >>>
> >>> Alec
> >>>
> >>> On Sat, Nov 20, 2010 at 1:35 PM, Igor Vaynberg <
> igor.vaynb...@gmail.com>
> >>> wrote:
> >>> > not sure yet :) but a quickstart will give me a playground to explore
> >>> > the options.
> >>> >
> >>> > -igor
> >>> >
> >>> > On Sat, Nov 20, 2010 at 12:20 PM, Alec Swan
> wrote:
> >>> >> I can file a bug, but I am curious how you are planning to fix this?
> >>> >>
> >>> >> I tried passing the OUTER form to UploadProgressBar, i.e.
> >>> >> nestedForm.add(new UploadProgressBar("progress", outerForm)), but
> that
> >>> >> caused the following error to be logged in Firebug:
> >>> >>
> >>> >> Wicket.WUPB.get(def.statusid) is null
> >>> >> [Break on this error]
> Wicket.WUPB.get(def.statusid).innerHTML='Upload
> >>> >> starting...';
> >>> >> progressbar.js (line 41
> >>> >>
> >>> >> While I am filing a bug and waiting for a fix, are there any
> >>> >> suggestions on how to show a modal window during files upload
> >>> >> initiated from a nested form?
> >>> >>
> >>> >> Thanks
> >>> >>
> >>> >> On Sat, Nov 20, 2010 at 1:05 PM, Igor Vaynberg <
> igor.vaynb...@gmail.com>
> >>> wrote:
> >>> >>> sounds like a bug. open a jira ticket, attach a quickstart.
> >>> >>>
> >>> >>> -igor
> >>> >>>
> >>> >>> On Sat, Nov 20, 2010 at 11:22 AM, Alec Swan
> >>> wrote:
> >>> Hello,
> >>>
> >>> I have a page which contains a form around a table. Each row in
> the
> >>> table contains a nested form which allows user to upload a file
> for
> >>> the row. I added an UploadProgressBar to the upload form in each
> row.
> >>> However, the upload progress bars are never shown.
> >>>
> >>> I understand that Wicket replaces a nested with and
> adds
> >>> onsubmit event handler to display UploadProgressBar. However,
> since
> >>> the was replaced with onsubmit handler never fires.
> >>>
> >>> How can I display a progress bar or at least a modal window during
> a
> >>> file upload from a nested form?
> >>>
> >>> Thanks!
> >>>
> >>>
> -
> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>
> >>>
> >>> >>>
> >>> >>>
> -
> >>> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>> >>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>> >>>
> >>> >>>
> >>> >>
> >>> >>
> -
> >>> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>> >>
> >>> >>
> >>> >
> >>> > -
> >>> > 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: WebMarkupContainer issue
wicket:id=pageContainer" <-your wicket:id="pageContainer"> sorry - can you point out exactly the difference in the html ? > It's not clear to me. > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/WebMarkupContainer-issue-tp3063886p3063905.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: DatePicker to pick a year
It does not work, only can switch between month, not year.
On Mon, Nov 29, 2010 at 11:33 AM, Marco Mancini wrote:
> try this code:
>
> DatePicker mydp= new DatePicker(){
> private static final long serialVersionUID = 1L;
>
> �...@override
> protected boolean enableMonthYearSelection() {
> return true;
> }
> };
>
> 2010/11/29 Anna Simbirtsev
>
>> Hi,
>>
>> Is it possible to get datapicker to switch between year, currently
>> there are arrows to only switch between month?
>>
>> Thanks,
>> Anna
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
--
Anna Simbirtsev
(416) 729-7331
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: component not visible exception
try to set mybutton.setOutputMarkupPlaceholderTag(true); bye marco 2010/11/29 Martin Grigorov > On Mon, Nov 29, 2010 at 4:46 PM, Douglas Ferguson < > doug...@douglasferguson.us> wrote: > > > We have not overridden isVisible, nor have we do we have a popup modal. > > That's why I was asking if this could be a back button issue. > > > > The only thing we do is set the button enabled. Could this be the problem > > even thought he message it talking about visibility? > > > No. There is a separate check for enabled state. It is definitely for > visibility. > > > > > D/ > > > > On Nov 29, 2010, at 3:15 AM, Martin Grigorov wrote: > > > > > Here is another scenario: > > > > > > Ajax request sets the visibility of the submit button (or its parent) > to > > > false but forgets to repaint the button so it is still visible for the > > user. > > > Then the user clicks on this button, it fires and then the backend > shows > > > this message - the button is invisible so it cannot be clicked. > > > > > > On Mon, Nov 29, 2010 at 9:04 AM, Chris Colman > > > wrote: > > > > > >> A back button where? > > >> > > >> The form is on a page and has a submit button only. If there is an > error > > >> a ModalWindow pops up - it only has an OK button which is meant to > make > > >> the ModalWindow simply disappear and thus re-enable the page beneath - > > >> the one with the form on it. > > >> > > >> Chris > > >>> -Original Message- > > >>> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] > > >>> Sent: Monday, 29 November 2010 6:53 PM > > >>> To: users@wicket.apache.org > > >>> Subject: Re: component not visible exception > > >>> > > >>> Could this be happening because of the back button? > > >>> > > >>> D/ > > >>> > > >>> On Nov 28, 2010, at 4:54 AM, Chris Colman wrote: > > >>> > > I had a similar problem. In my scenario it occurred when a > > >> ModalWindow > > was brought up when a form failed validation. When they clicked ok > to > > close the ModalWindow and then clicked Submit on the form again I > got > > >> a > > similar message saying that the Submit button was no longer visible. > > > > It doesn't happen if I use the normal validation 'feedback' panel to > > display the validation error messages. > > > > Chris > > > > > -Original Message- > > > From: Douglas Ferguson [mailto:doug...@douglasferguson.us] > > > Sent: Saturday, 27 November 2010 3:13 AM > > > To: Wicket Mailing List List > > > Subject: component not visible exception > > > > > > I have an error I've been seeing in the production logs for awhile > > >> now > > and > > > haven't been able to to figure it out. > > > > > > My thought is that it is due to a stale page or the back button, > but > > >> it > > > seems to me that it is happening alot, so I thought I might > inquire. > > > > > > Any thoughts on what might be causing this and how to avoid it? > > > > > > 2010-11-26 08:36:36,676 ERROR [TP-Processor34] wicket.RequestCycle > - > > Submit > > > Button add (path=dataPanel:contentCenterBox:addUserForm:add) is not > > visible > > > org.apache.wicket.WicketRuntimeException: Submit Button add > > > (path=dataPanel:contentCenterBox:addUserForm:add) is not visible > > >at > > org.apache.wicket.markup.html.form.Form$2.component(Form.java:622) > > >at > > > > > >> > org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:89 > > 9) > > >at > > > > > >> > org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 > > 4) > > >at > > > > > >> > org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 > > 4) > > >at > > > > > >> > org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 > > 4) > > >at > > > > > >> > org.apache.wicket.markup.html.form.Form.findSubmittingButton(Form.java: > > 604) > > >at > > > > > >> org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:899) > > >at > > > > > >> > org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubm > > itBe > > > havior.java:135) > > >at > > > > > >> > org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java > > :177 > > > ) > > >at > > > > > >> > org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDe > > faul > > > tAjaxBehavior.java:300) > > >at > > > > > >> > org.apache.wicket.request.target.component.listener.BehaviorRequestTarg > > et.p > > > rocessEvents(BehaviorRequestTarget.java:119) > > >at > > > > > >> > org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(A > > bstr > > > actRequestCycleProcessor.java:92) > > >at > > > > > >> > org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCyc
Re: WebMarkupContainer issue
sorry - can you point out exactly the difference in the html ? It's not clear to me. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/WebMarkupContainer-issue-tp3063886p3063905.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: WebMarkupContainer issue
mm
replace whit
need one " :-D
2010/11/29 drf
>
> I wonder if someone can help. In my code, I have a java class which extends
> Panel and associated html.
> This contains, among other things, a Panel object "mainPanel".
> Everything works fine. I now want to enclose the mainPanel object in a
> WebMarkupContainer.
> To do so, I declare an instance variable
> protected WebMarkupContainer mainPageContainer;
> and in the constructor:
>
> mainPageContainer = new WebMarkupContainer("pageContainer");
> add(mainPageContainer);
> mainPageContainer.add(mainPage);
>
> In the html page, the line:
>
> is replaced with:
> wicket:id="mainPage">
>
> Wicket throws the following error:
> WicketMessage: The component(s) below failed to render: A common problem is
> that you have added a component in code but forgot to reference it in the
> markup (thus the component will never be rendered).
> 1. [MarkupContainer[Component id= mainPage]]
> 2. [MarkupContainer[Component id= pageTitle]]
>
> I cannot see an obvious error and would really appreciate help!
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/WebMarkupContainer-issue-tp3063886p3063886.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: DatePicker to pick a year
try this code:
DatePicker mydp= new DatePicker(){
private static final long serialVersionUID = 1L;
@Override
protected boolean enableMonthYearSelection() {
return true;
}
};
2010/11/29 Anna Simbirtsev
> Hi,
>
> Is it possible to get datapicker to switch between year, currently
> there are arrows to only switch between month?
>
> Thanks,
> Anna
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
WebMarkupContainer issue
I wonder if someone can help. In my code, I have a java class which extends
Panel and associated html.
This contains, among other things, a Panel object "mainPanel".
Everything works fine. I now want to enclose the mainPanel object in a
WebMarkupContainer.
To do so, I declare an instance variable
protected WebMarkupContainer mainPageContainer;
and in the constructor:
mainPageContainer = new WebMarkupContainer("pageContainer");
add(mainPageContainer);
mainPageContainer.add(mainPage);
In the html page, the line:
is replaced with:
Wicket throws the following error:
WicketMessage: The component(s) below failed to render: A common problem is
that you have added a component in code but forgot to reference it in the
markup (thus the component will never be rendered).
1. [MarkupContainer[Component id= mainPage]]
2. [MarkupContainer[Component id= pageTitle]]
I cannot see an obvious error and would really appreciate help!
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/WebMarkupContainer-issue-tp3063886p3063886.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
DatePicker to pick a year
Hi, Is it possible to get datapicker to switch between year, currently there are arrows to only switch between month? Thanks, Anna - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: PropertyModel expression for collection object
Hello. See this link for property expression language: https://cwiki.apache.org/WICKET/property-expression-language.html >> "property.index": If the property is a List or Array then the second >> property can be used as a index on that list/array >> like this: 'mylist.0'. Best regards, Alexander. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: onSubmit not getting invoked using AjaxButton
Hey, in development mode you can check ajax debug panel. So, you can see all ajax request. If it doesn't help could you, please, provide sample source? Best regards, Alexander. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: component not visible exception
On Mon, Nov 29, 2010 at 4:46 PM, Douglas Ferguson < doug...@douglasferguson.us> wrote: > We have not overridden isVisible, nor have we do we have a popup modal. > That's why I was asking if this could be a back button issue. > > The only thing we do is set the button enabled. Could this be the problem > even thought he message it talking about visibility? > No. There is a separate check for enabled state. It is definitely for visibility. > > D/ > > On Nov 29, 2010, at 3:15 AM, Martin Grigorov wrote: > > > Here is another scenario: > > > > Ajax request sets the visibility of the submit button (or its parent) to > > false but forgets to repaint the button so it is still visible for the > user. > > Then the user clicks on this button, it fires and then the backend shows > > this message - the button is invisible so it cannot be clicked. > > > > On Mon, Nov 29, 2010 at 9:04 AM, Chris Colman > > wrote: > > > >> A back button where? > >> > >> The form is on a page and has a submit button only. If there is an error > >> a ModalWindow pops up - it only has an OK button which is meant to make > >> the ModalWindow simply disappear and thus re-enable the page beneath - > >> the one with the form on it. > >> > >> Chris > >>> -Original Message- > >>> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] > >>> Sent: Monday, 29 November 2010 6:53 PM > >>> To: users@wicket.apache.org > >>> Subject: Re: component not visible exception > >>> > >>> Could this be happening because of the back button? > >>> > >>> D/ > >>> > >>> On Nov 28, 2010, at 4:54 AM, Chris Colman wrote: > >>> > I had a similar problem. In my scenario it occurred when a > >> ModalWindow > was brought up when a form failed validation. When they clicked ok to > close the ModalWindow and then clicked Submit on the form again I got > >> a > similar message saying that the Submit button was no longer visible. > > It doesn't happen if I use the normal validation 'feedback' panel to > display the validation error messages. > > Chris > > > -Original Message- > > From: Douglas Ferguson [mailto:doug...@douglasferguson.us] > > Sent: Saturday, 27 November 2010 3:13 AM > > To: Wicket Mailing List List > > Subject: component not visible exception > > > > I have an error I've been seeing in the production logs for awhile > >> now > and > > haven't been able to to figure it out. > > > > My thought is that it is due to a stale page or the back button, but > >> it > > seems to me that it is happening alot, so I thought I might inquire. > > > > Any thoughts on what might be causing this and how to avoid it? > > > > 2010-11-26 08:36:36,676 ERROR [TP-Processor34] wicket.RequestCycle - > Submit > > Button add (path=dataPanel:contentCenterBox:addUserForm:add) is not > visible > > org.apache.wicket.WicketRuntimeException: Submit Button add > > (path=dataPanel:contentCenterBox:addUserForm:add) is not visible > >at > org.apache.wicket.markup.html.form.Form$2.component(Form.java:622) > >at > > > >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:89 > 9) > >at > > > >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 > 4) > >at > > > >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 > 4) > >at > > > >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 > 4) > >at > > > >> org.apache.wicket.markup.html.form.Form.findSubmittingButton(Form.java: > 604) > >at > > > >> org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:899) > >at > > > >> org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubm > itBe > > havior.java:135) > >at > > > >> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java > :177 > > ) > >at > > > >> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDe > faul > > tAjaxBehavior.java:300) > >at > > > >> org.apache.wicket.request.target.component.listener.BehaviorRequestTarg > et.p > > rocessEvents(BehaviorRequestTarget.java:119) > >at > > > >> org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(A > bstr > > actRequestCycleProcessor.java:92) > >at > > > >> org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.jav > a:12 > > 50) > >at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329) > >at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436) > >at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) > >at > > > >> org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:48 > 4) > >at > > > >> org.apache.wicket.
Re: component not visible exception
We have not overridden isVisible, nor have we do we have a popup modal. That's why I was asking if this could be a back button issue. The only thing we do is set the button enabled. Could this be the problem even thought he message it talking about visibility? D/ On Nov 29, 2010, at 3:15 AM, Martin Grigorov wrote: > Here is another scenario: > > Ajax request sets the visibility of the submit button (or its parent) to > false but forgets to repaint the button so it is still visible for the user. > Then the user clicks on this button, it fires and then the backend shows > this message - the button is invisible so it cannot be clicked. > > On Mon, Nov 29, 2010 at 9:04 AM, Chris Colman > wrote: > >> A back button where? >> >> The form is on a page and has a submit button only. If there is an error >> a ModalWindow pops up - it only has an OK button which is meant to make >> the ModalWindow simply disappear and thus re-enable the page beneath - >> the one with the form on it. >> >> Chris >>> -Original Message- >>> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >>> Sent: Monday, 29 November 2010 6:53 PM >>> To: users@wicket.apache.org >>> Subject: Re: component not visible exception >>> >>> Could this be happening because of the back button? >>> >>> D/ >>> >>> On Nov 28, 2010, at 4:54 AM, Chris Colman wrote: >>> I had a similar problem. In my scenario it occurred when a >> ModalWindow was brought up when a form failed validation. When they clicked ok to close the ModalWindow and then clicked Submit on the form again I got >> a similar message saying that the Submit button was no longer visible. It doesn't happen if I use the normal validation 'feedback' panel to display the validation error messages. Chris > -Original Message- > From: Douglas Ferguson [mailto:doug...@douglasferguson.us] > Sent: Saturday, 27 November 2010 3:13 AM > To: Wicket Mailing List List > Subject: component not visible exception > > I have an error I've been seeing in the production logs for awhile >> now and > haven't been able to to figure it out. > > My thought is that it is due to a stale page or the back button, but >> it > seems to me that it is happening alot, so I thought I might inquire. > > Any thoughts on what might be causing this and how to avoid it? > > 2010-11-26 08:36:36,676 ERROR [TP-Processor34] wicket.RequestCycle - Submit > Button add (path=dataPanel:contentCenterBox:addUserForm:add) is not visible > org.apache.wicket.WicketRuntimeException: Submit Button add > (path=dataPanel:contentCenterBox:addUserForm:add) is not visible >at org.apache.wicket.markup.html.form.Form$2.component(Form.java:622) >at > >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:89 9) >at > >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 4) >at > >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 4) >at > >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 4) >at > >> org.apache.wicket.markup.html.form.Form.findSubmittingButton(Form.java: 604) >at > >> org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:899) >at > >> org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubm itBe > havior.java:135) >at > >> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java :177 > ) >at > >> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDe faul > tAjaxBehavior.java:300) >at > >> org.apache.wicket.request.target.component.listener.BehaviorRequestTarg et.p > rocessEvents(BehaviorRequestTarget.java:119) >at > >> org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(A bstr > actRequestCycleProcessor.java:92) >at > >> org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.jav a:12 > 50) >at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329) >at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436) >at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) >at > >> org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:48 4) >at > >> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java :317 > ) >at > >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applic atio > nFilterChain.java:215) >at > >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFil terC > hain.java:188) >at > >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapper
Re: Painting a ListView in Ajax via a transparent container fails
When an transparent resolved component is rendered, it is able to correctly resolve any wicket:id in the inner html object because it delegates the Component#get to its parent, and it is able to know who are its children components traversing the html at at the markupStream object. So this special component is designed to be aware of children components only at the rendering time ( working with the markupStream ) and not at the pre-rendering. As the ListView depends on pre-rendering logic, add an transparent resolved component in ajax request target has no effect because no children pre-rendering method will be invoked. On Sun, Nov 28, 2010 at 11:04 AM, Wilhelmsen Tor Iver wrote: > In my quest for a more portlet-oriented use of Wicket, I am trying an > approach where you switch panels (by constructing new instances and > repainting a "wrapper") within one Page. However, it seems that ListViews do > not get repainted (no calls to populateItem()) in that scenario: > > 1) Initial rendering that does not use Ajax works fine. > 2) An AjaxFallbackButton then switches to a second panel > 3) Returning via an AjaxFallbackLink to a new instance of the first > panel paints all components except the ListView items. > > Is there something I have forgotten? Would it make more sense to have all > Panels in the Page at once and then just adjust visibility as needed? > > A quickstart can be found at > http://dl.dropbox.com/u/11463405/listviewtest.zip > > Med vennlig hilsen > > TOR IVER WILHELMSEN > Senior systemutvikler > Arrive AS > T (+47) 48 16 06 18 > E-post: toriv...@arrive.no > http://www.arrive.no > http://servicedesk.arrive.no > > > > -- Pedro Henrique Oliveira dos Santos
wicket + BPM/ jpbm
Hello, as I had no luck in the ICQ channel, I post it here: Has anyone some knowledge about putting wicket and BPM together? I saw that there was a wicketBPM project in past by "kgalligan" under http://bigheadco.blogspot.com/2007/02/wicket-bpm-update.html but email and site are dead. Beside that I found a wicket-jbpm project on google, but it looks quite abandoned with latest updates from last year and targeting an old jBPM 3 version. If anyone has knowledge of any workflow/ BPM solution and wicket I would be really happy to hear. Best, Korbinian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: onSubmit not getting invoked using AjaxButton
Add a feedback and rerender it on the onError method to see the specific error. Regards, Poko On Nov 29, 2010, at 10:29, hemilshah wrote: > > Hi, > > I have a panel with 2 dropdown choice component and an AjaxButton. One > dropdownchoice has a AjaxFormUpdatingComponent behaviour added and this is > working fine. > > But on clicking, its not invoking onSubmit button. It seems that there is a > validation failure as Wicket invokes onError method when my set > defaultFormProcessing to true. But i could not figure out why it is > happening. On making the flag to false Wicket invokes onSubmit method but my > functionality is not working. > > I want to know the possible reasons for not getting onSubmit to be invoked > and also for validation failure. > > Thanks. > Regards, > Hemil > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/onSubmit-not-getting-invoked-using-AjaxButton-tp3063201p3063201.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
onSubmit not getting invoked using AjaxButton
Hi, I have a panel with 2 dropdown choice component and an AjaxButton. One dropdownchoice has a AjaxFormUpdatingComponent behaviour added and this is working fine. But on clicking, its not invoking onSubmit button. It seems that there is a validation failure as Wicket invokes onError method when my set defaultFormProcessing to true. But i could not figure out why it is happening. On making the flag to false Wicket invokes onSubmit method but my functionality is not working. I want to know the possible reasons for not getting onSubmit to be invoked and also for validation failure. Thanks. Regards, Hemil -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/onSubmit-not-getting-invoked-using-AjaxButton-tp3063201p3063201.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
PropertyModel expression for collection object
Hi,
I have a collection object in a class. I want to retrieve the property value
using PropertyModel for the object. Please suggest.
Consider -
class A {
Set objA = new HashSet();
}
class B {
B b = new B();
}
i tried using expression like A[0].b as expression but it fails giving error
like " no get method defined for class: class
org.hibernate.collection.PersistentSet expression: 0]".
Both the above classes have public setter and getter methods.
Please suggest.
Thanks.
Regards,
Hemil
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/PropertyModel-expression-for-collection-object-tp3063675p3063675.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
Wicket 1.4.14 > Bug with panels updated by Ajax rendering a CSS
Hi all, I have just upgraded my dev environment from Wicket 1.4.13 to 1.4.14 this morning and discovered a bug related to CSS. On a page, I have a panel containing a listview, itself populated with panels that have in their constructor: add(CSSPackageResource.getHeaderContribution(CSS)); When browsing to this page, the listview is initially empty. When the panel is updated by an Ajax Link making the listview model list not empty, the list view contents are rendered, but the CSS is not (and the reference to the css script does not appear in the Wicket Ajax Debug Window), and thus the presentation is all messed up. I just downgraded back to Wicket 1.4.13, and all is fine. I don't have time to prepare a Quickstart yet, but if anyone who has been fixing bugs on Wicket 1.4.14 has a brilliant intuition on what can cause this regression, it would be great ;) Otherwise, I'll try to find sometime later this week to file a JIRA issue with a Quickstart. Cheers, Antoine. -- Antoine Angénieux Associé Clinigrid 5, avenue Mozart 75016 Paris, France +336 60 21 09 18 aangeni...@clinigrid.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Painting a ListView in Ajax via a transparent container fails
Transparent container probably doesn't exist/have an id so yes.. but I guess this could be "fixed"/automated in wicket. ** Martin 2010/11/29 Wilhelmsen Tor Iver : >> wicket:enclosure is not present if not visible (from browser >> perspective). So it cannot be repainted. > > I think we are talking past each other: It was just an example of something > that is a transparent container to a Wicket developer, though it is > implemented using IComponentResolver instead of just a transparent markup > container (as in my case in the quickstart where everything within the > transparent container gets repainted except the ListView). > > Anyway, my problem was solved by eliminating the transparent container and > just paint the panel and feedback-panel. > > - Tor Iver > > > - > 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
[Announce] Wicketstuff-core 1.4.14 Released
Hello, Following the release of wicket 1.4.14 I've cut a matching release for wicketstuff-core. The artifacts have been promoted and synced into the maven central repository. They can be retrieved like this: org.wicketstuff progressbar 1.4.14 The release tag is here: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/tags/wicketstuff-core-1.4.14 The new 1.4.14.1-SNAPSHOT stable branch is here: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/branches/wicketstuff-core-1.4.14 The new 1.4.15-SNAPSHOT branch is here: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/branches/wicketstuff-core-1.4 Release Notes - WicketStuff Core - Version 1.4.14: wicketstuff-minis: - added org.wicketstuff.minis.util.FutureModel - added org.wicketstuff.minis.util.ListViewFormComponentReuseManager - added org.wicketstuff.minis.util.VersatileWebRequestCodingStrategy progressbar: - copied wicketstuff-progressbar from wicketstuff trunk into wicketstuff core. - changed the artifactId's from wicketstuff-progressbar-* to progressbar-* to fit into the wicketstuff-core naming convention. The plan is to release a 1.4.14.1 point release within one month from today.If you commit code and/or want a release sooner let me know as one month is the worst case target. Regards, Mike - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
SV: Painting a ListView in Ajax via a transparent container fails
> wicket:enclosure is not present if not visible (from browser > perspective). So it cannot be repainted. I think we are talking past each other: It was just an example of something that is a transparent container to a Wicket developer, though it is implemented using IComponentResolver instead of just a transparent markup container (as in my case in the quickstart where everything within the transparent container gets repainted except the ListView). Anyway, my problem was solved by eliminating the transparent container and just paint the panel and feedback-panel. - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Painting a ListView in Ajax via a transparent container fails
wicket:enclosure is not present if not visible (from browser perspective). So it cannot be repainted. http://apache-wicket.1842946.n4.nabble.com/Wicket-ajax-enabled-enclosures-td3033370.html 2010/11/29 Wilhelmsen Tor Iver : >> I don't know what you mean with transparent but ofcourse you cannot >> repaint invisible things. > > A transparent container is one that appears in the markup and in the code but > which returns true for isTransparentResolver(). It's not "invisible" but is > not part of the explicit hierarchy. An example of such a container is the one > represented by the tag. > > I.e. if you have container A, add a transparent container B to A, and in the > markup have a hierarchy of A - B - C, you would add C to A instead of B: The > code relating to the hierarchy of A will ignore B, but at runtime Wicket > "knows" that B sits between A and C. > > - Tor Iver > > - > 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
SV: Painting a ListView in Ajax via a transparent container fails
> I don't know what you mean with transparent but ofcourse you cannot > repaint invisible things. A transparent container is one that appears in the markup and in the code but which returns true for isTransparentResolver(). It's not "invisible" but is not part of the explicit hierarchy. An example of such a container is the one represented by the tag. I.e. if you have container A, add a transparent container B to A, and in the markup have a hierarchy of A - B - C, you would add C to A instead of B: The code relating to the hierarchy of A will ignore B, but at runtime Wicket "knows" that B sits between A and C. - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: component not visible exception
Here is another scenario: Ajax request sets the visibility of the submit button (or its parent) to false but forgets to repaint the button so it is still visible for the user. Then the user clicks on this button, it fires and then the backend shows this message - the button is invisible so it cannot be clicked. On Mon, Nov 29, 2010 at 9:04 AM, Chris Colman wrote: > A back button where? > > The form is on a page and has a submit button only. If there is an error > a ModalWindow pops up - it only has an OK button which is meant to make > the ModalWindow simply disappear and thus re-enable the page beneath - > the one with the form on it. > > Chris > >-Original Message- > >From: Douglas Ferguson [mailto:doug...@douglasferguson.us] > >Sent: Monday, 29 November 2010 6:53 PM > >To: users@wicket.apache.org > >Subject: Re: component not visible exception > > > >Could this be happening because of the back button? > > > >D/ > > > >On Nov 28, 2010, at 4:54 AM, Chris Colman wrote: > > > >> I had a similar problem. In my scenario it occurred when a > ModalWindow > >> was brought up when a form failed validation. When they clicked ok to > >> close the ModalWindow and then clicked Submit on the form again I got > a > >> similar message saying that the Submit button was no longer visible. > >> > >> It doesn't happen if I use the normal validation 'feedback' panel to > >> display the validation error messages. > >> > >> Chris > >> > >>> -Original Message- > >>> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] > >>> Sent: Saturday, 27 November 2010 3:13 AM > >>> To: Wicket Mailing List List > >>> Subject: component not visible exception > >>> > >>> I have an error I've been seeing in the production logs for awhile > now > >> and > >>> haven't been able to to figure it out. > >>> > >>> My thought is that it is due to a stale page or the back button, but > it > >>> seems to me that it is happening alot, so I thought I might inquire. > >>> > >>> Any thoughts on what might be causing this and how to avoid it? > >>> > >>> 2010-11-26 08:36:36,676 ERROR [TP-Processor34] wicket.RequestCycle - > >> Submit > >>> Button add (path=dataPanel:contentCenterBox:addUserForm:add) is not > >> visible > >>> org.apache.wicket.WicketRuntimeException: Submit Button add > >>> (path=dataPanel:contentCenterBox:addUserForm:add) is not visible > >>> at > >> org.apache.wicket.markup.html.form.Form$2.component(Form.java:622) > >>> at > >>> > org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:89 > >> 9) > >>> at > >>> > org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 > >> 4) > >>> at > >>> > org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 > >> 4) > >>> at > >>> > org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 > >> 4) > >>> at > >>> > org.apache.wicket.markup.html.form.Form.findSubmittingButton(Form.java: > >> 604) > >>> at > >>> > org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:899) > >>> at > >>> > org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubm > >> itBe > >>> havior.java:135) > >>> at > >>> > org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java > >> :177 > >>> ) > >>> at > >>> > org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDe > >> faul > >>> tAjaxBehavior.java:300) > >>> at > >>> > org.apache.wicket.request.target.component.listener.BehaviorRequestTarg > >> et.p > >>> rocessEvents(BehaviorRequestTarget.java:119) > >>> at > >>> > org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(A > >> bstr > >>> actRequestCycleProcessor.java:92) > >>> at > >>> > org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.jav > >> a:12 > >>> 50) > >>> at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329) > >>> at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436) > >>> at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) > >>> at > >>> > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:48 > >> 4) > >>> at > >>> > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java > >> :317 > >>> ) > >>> at > >>> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applic > >> atio > >>> nFilterChain.java:215) > >>> at > >>> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFil > >> terC > >>> hain.java:188) > >>> at > >>> > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVal > >> ve.j > >>> ava:213) > >>> at > >>> > org.apache.catalina.core.StandardContextValve.invoke(StandardContextVal > >> ve.j > >>> ava:172) > >>> at > >>> > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.jav > >> a:12 > >>> 7) > >>> at > >>> > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.jav > >> a:11 > >>> 7) > >>> at > >
Re: Maven: Where to find the current binaries
On 11/26/2010 08:28 PM, Uwe Schäfer wrote: i am quite puzzle due the maven behaviour described below. I took this to the maven mailinglist, but with no result. to be complete, here´s the link to the according thread on maven-user: http://bit.ly/gj33qP - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Painting a ListView in Ajax via a transparent container fails
I don't know what you mean with transparent but ofcourse you cannot
repaint invisible things.
**
Martin
2010/11/29 Wilhelmsen Tor Iver :
>>
>>
>>
>>
>> Which is laid out as:
>> ...
>> panel.add((listviewContainer = new
>> WebMarkupContainer("listview-container")).setOutputMarkupId(true));
>> ...
>
> This is almost what I have (in the Page), except the outermost one is
> transparent; in the "real" project the only reason is to wrap both a
> FeedbackPanel and the switched Panel. The repainting works then except for
> the ListView.
>
> I will try to use an approach which ditches the transparent container and
> instead repaints the Panel and the FeedbackPanel.
>
> - Tor Iver
>
> -
> 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
SV: Painting a ListView in Ajax via a transparent container fails
>
>
>
>
> Which is laid out as:
> ...
> panel.add((listviewContainer = new
> WebMarkupContainer("listview-container")).setOutputMarkupId(true));
> ...
This is almost what I have (in the Page), except the outermost one is
transparent; in the "real" project the only reason is to wrap both a
FeedbackPanel and the switched Panel. The repainting works then except for the
ListView.
I will try to use an approach which ditches the transparent container and
instead repaints the Panel and the FeedbackPanel.
- Tor Iver
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
RE: component not visible exception
A back button where? The form is on a page and has a submit button only. If there is an error a ModalWindow pops up - it only has an OK button which is meant to make the ModalWindow simply disappear and thus re-enable the page beneath - the one with the form on it. Chris >-Original Message- >From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >Sent: Monday, 29 November 2010 6:53 PM >To: users@wicket.apache.org >Subject: Re: component not visible exception > >Could this be happening because of the back button? > >D/ > >On Nov 28, 2010, at 4:54 AM, Chris Colman wrote: > >> I had a similar problem. In my scenario it occurred when a ModalWindow >> was brought up when a form failed validation. When they clicked ok to >> close the ModalWindow and then clicked Submit on the form again I got a >> similar message saying that the Submit button was no longer visible. >> >> It doesn't happen if I use the normal validation 'feedback' panel to >> display the validation error messages. >> >> Chris >> >>> -Original Message- >>> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >>> Sent: Saturday, 27 November 2010 3:13 AM >>> To: Wicket Mailing List List >>> Subject: component not visible exception >>> >>> I have an error I've been seeing in the production logs for awhile now >> and >>> haven't been able to to figure it out. >>> >>> My thought is that it is due to a stale page or the back button, but it >>> seems to me that it is happening alot, so I thought I might inquire. >>> >>> Any thoughts on what might be causing this and how to avoid it? >>> >>> 2010-11-26 08:36:36,676 ERROR [TP-Processor34] wicket.RequestCycle - >> Submit >>> Button add (path=dataPanel:contentCenterBox:addUserForm:add) is not >> visible >>> org.apache.wicket.WicketRuntimeException: Submit Button add >>> (path=dataPanel:contentCenterBox:addUserForm:add) is not visible >>> at >> org.apache.wicket.markup.html.form.Form$2.component(Form.java:622) >>> at >>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:89 >> 9) >>> at >>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 >> 4) >>> at >>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 >> 4) >>> at >>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 >> 4) >>> at >>> org.apache.wicket.markup.html.form.Form.findSubmittingButton(Form.java: >> 604) >>> at >>> org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:899) >>> at >>> org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubm >> itBe >>> havior.java:135) >>> at >>> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java >> :177 >>> ) >>> at >>> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDe >> faul >>> tAjaxBehavior.java:300) >>> at >>> org.apache.wicket.request.target.component.listener.BehaviorRequestTarg >> et.p >>> rocessEvents(BehaviorRequestTarget.java:119) >>> at >>> org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(A >> bstr >>> actRequestCycleProcessor.java:92) >>> at >>> org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.jav >> a:12 >>> 50) >>> at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329) >>> at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436) >>> at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) >>> at >>> org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:48 >> 4) >>> at >>> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java >> :317 >>> ) >>> at >>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applic >> atio >>> nFilterChain.java:215) >>> at >>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFil >> terC >>> hain.java:188) >>> at >>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVal >> ve.j >>> ava:213) >>> at >>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextVal >> ve.j >>> ava:172) >>> at >>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.jav >> a:12 >>> 7) >>> at >>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.jav >> a:11 >>> 7) >>> at >>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve >> .jav >>> a:108) >>> at >>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java: >> 151) >>> at >>> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200) >>> at >>> org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) >>> at >> org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773) >>> at >>> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java >> :703 >>> ) >>> at >>> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket >> .jav >>> a:895) >>> at >>> org.apache.tomca
RE: [ANNOUNCE] Wicket 1.4.14 Released
Cool! Well done guys. Regards, Chris >-Original Message- >From: Jeremy Thomerson [mailto:jrthomer...@apache.org] >Sent: Monday, 29 November 2010 5:07 PM >To: users@wicket.apache.org; Wicket Development; annou...@wicket.apache.org >Subject: [ANNOUNCE] Wicket 1.4.14 Released > >The Wicket development team is proud to announce that we have released >Wicket 1.4.14. This is a bugfix and minor improvement release in the >1.4.x (stable) branch. > >To download: http://www.apache.org/dyn/closer.cgi/wicket/1.4.14 >Release Tag: http://svn.apache.org/repos/asf/wicket/releases/wicket-1.4.14/ >Changelog: >https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561&s >tyleName=Html&version=12315480 > >To use with Maven (the recommended way to use Wicket): > > >org.apache.wicket >wicket >1.4.14 > > >-- >Jeremy Thomerson >http://wickettraining.com >Need a CMS for Wicket? Use Brix! http://brixcms.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
