Re: user activity disabled during page load
In your getWindowOpenJavaScript() you need to set one property to disable the confirmation dialog: Wicket.Window.unloadConfirmation = false; See here: http://stackoverflow.com/questions/8013364/how-to-defeat-browser-dialog-popup-when-calling-wicket-setresponsepage-from-mo -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/user-activity-disabled-during-page-load-tp4662891p4662907.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: Components can no longer be added
Sven,
" once rendering of components via Ajax has started, you cannot update
components."
But at the moment when this happens, we are in the onConfigure() part of the
lifecycle. Which is before onBeforeRender(), and hence components should've
have started rendering... but that is minor as...
"You should just add all expanded nodes to your tree's model. That's faster and
won't trigger any updates:"
Brilliant! I didn't realize that tree model was the *expanded* nodes, but it
makes sense since you now say it...
Thanks! This works great and gets round any other issues. :)
Cheers,
Col.
-Original Message-
From: Sven Meier [mailto:s...@meiers.net]
Sent: Monday, December 9, 2013 8:01 PM
To: users@wicket.apache.org
Subject: Re: Components can no longer be added
Hi,
once rendering of components via Ajax has started, you cannot update components.
AbstractTree#expand() is a convenience method that updates the expanded branch
automatically, hence you get the IllegalStateException.
You should just add all expanded nodes to your tree's model. That's faster and
won't trigger any updates:
tree.getModel().addAll(addNodes);
If you always start with all nodes expanded, you might want to use a custom
set, which inverses its contents. See
org.apache.wicket.examples.tree.FooExpansion for inspiration.
Regards
Sven
On 12/09/2013 06:28 AM, Colin Rogers wrote:
> Wicketeers,
>
> I have another hard-to-track down issue.
>
> To make matters worse, I've actually taken this code/pattern, put it
> into a quickstart - and what do you know - it works fine...! This
> means I have no way to recreate this error in a demonstrable way.
> Hopefully if I throw this out there, someone might be able to describe
> the error and I can then determine what I'm doing to cause it.
> Unfortunately google has zero results for;
>
> +"Components can no longer be added" +wicket
>
> Anyway... the exception I'm getting is;
>
> java.lang.IllegalStateException: Components can no longer be added
> at
> org.apache.wicket.ajax.AbstractAjaxResponse.assertNotFrozen(AbstractAjaxResponse.java:740)
> at
> org.apache.wicket.ajax.AbstractAjaxResponse.assertComponentsNotFrozen(AbstractAjaxResponse.java:733)
> at
> org.apache.wicket.ajax.AbstractAjaxResponse.add(AbstractAjaxResponse.java:358)
> at
> org.apache.wicket.ajax.AjaxRequestHandler.add(AjaxRequestHandler.java:239)
> at
> org.apache.wicket.ajax.AjaxRequestHandler.add(AjaxRequestHandler.java:232)
> at
> org.apache.wicket.extensions.markup.html.repeater.tree.TableTree.updateBranch(TableTree.java:178)
> at
> org.apache.wicket.extensions.markup.html.repeater.tree.AbstractTree.expand(AbstractTree.java:204)
> at myapp.TreeUtils.expandNode(TreeUtils.java:25)
> at myapp.TreeUtils.expandAll(TreeUtils.java:19)
>
>
> It is caused when refreshing a table-tree component, that had previous
> rendered correctly and had successfully expanded the nodes. This problem
> happens when the table-trees parent component is refreshed, in which the
> table is rebuilt from new, and replaced the old table. Having debugged the
> code, it's something to do with the AjaxRequestHandler that has been
> retrieved - in that it's components are 'frozen'. It's odd as I'm in the
> onConfigure() part of the lifecycle, and therefore components should be okay
> to be added - especially as they are brand new components. Could the
> AjaxRequestHandler being retrieved be the wrong one, stale one?
>
> List I said - I can't recreate it in a Quickstart, so there is obviously
> something else in the 100k+s of the projects code that is doing something
> else to mess it up.
>
> The 'Tree Utils' class looks like this;
>
> public class TreeUtils {
>
> @SuppressWarnings("unchecked")
> public static void expandAll( AbstractTree tree ) {
>
> // stupid cast!! Has to happen for use to retrieve the roots,
> generically.
> AbstractTree castTree = (AbstractTree) tree;
>
> Iterator roots = tree.getProvider().getRoots();
> while( roots.hasNext() ) {
>
> Object root = roots.next();
> expandNode( castTree, root );
> }
> }
>
> private static void expandNode( AbstractTree tree, Object
> node) {
>
> tree.expand(node);
>
> Iterator children = tree.getProvider().getChildren(node);
> while( children.hasNext() ) {
>
> Object child = children.next();
> expandNode( tree, child );
> }
> }
> }
>
>
> Any pointers and tips would be greatly appreciated.
>
> Cheers,
> Col.
> EMAIL DISCLAIMER This email message and its attachments are confidential and
> may also contain copyright or privileged material. If you are not the
> intended recipient, you may not forward the email or disclose or use the
> information contained in it. If you have received this email message in
> error, please advise the sender immediately by replying to
Re: Converting 1.4.7 to 6.12
Hello, I think you can use getSession().getPageFactory().newPage(); Depending on your context you could use Session.get() or getSession() Hope that helps -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Converting-1-4-7-to-6-12-tp4662892p4662893.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
Converting 1.4.7 to 6.12
Hi, it's me again. I'm still converting to 6.12 from 1.4.7. Thanks for your help on previous questions. Here's the next item I didn't see in the conversion docs. In one of our pages, someone did this: setResponsePage(getApplication().getSessionSettings().getPageFactory().newPage(loginService.getHomePage(uInfo),(PageParameters) null)); The part the compiler complains about is getApplication().getSessionSettings(). Sure enough, looking at the v6 javadoc, it isn't there. But in this javadoc page: http://ci.apache.org/projects/wicket/apidocs/6.0.x/org/apache/wicket/Application.html under the Settings bullet, it specifically mentions the method as if it exists. So if this method no longer exists. What is it's v6 equivalent? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Converting-1-4-7-to-6-12-tp4662892.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
user activity disabled during page load
Dear all,
I have been having trouble with a page that is heavy in loading, especially
at client locations with low bandwidth. The main problem is that fields that
are updated by the user before load has completed are not saved in their
edited form.
I have made an attempt to solve this problem with a modal window based on
this:
http://apache-wicket.1842946.n4.nabble.com/opening-ModalWindow-on-page-load-td3055618.html
renderHead has been amended to:
public void renderHead(IHeaderResponse response) {
response.render(OnDomReadyHeaderItem.forScript(getWindowOpenJavaScript()));
response.render(OnLoadHeaderItem.forScript(getCloseJavacript()));
}
However, a problem with this approach is the modal window can be closed by
the user at will.
This problem, again, I have sought to resolve by amending the close
behavior:
private void initialize() {
setCloseButtonCallback(new CloseButtonCallback() {
@Override
public boolean onCloseButtonClicked(AjaxRequestTarget target) {
return false;
}
});
This works fine for modal window's case. However, I now suddenly get this
message: "The page is asking you to confirm that you want to leave - data
you have entered may not be saved." With the options: Leave Page. Stay on
Page.
This behavior seems to show up no matter what if a new CloseButtonCallback
is implemented. If this behavior were non-present, everything would be fine.
I just want to disable user activity in the page before the entire page is
loaded.
I have looked into using an adaptation of the DisableComponentListener:
http://wicket.apache.org/guide/guide/chapter17.html#chapter17_6
But I have thus far failed to see how this can be applied when I am not
using Ajax in this instance.
Any tips that can please be provided for this task to move forward will be
greatly appreciated.
Thank you very much in advance.
Best regards,
J.K. Baltzersen
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/user-activity-disabled-during-page-load-tp4662891.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket CDI Status
Hi Diogo, It already is: https://github.com/apache/wicket/blob/wicket-6.x/wicket-experimental/wicket-cdi-1.1/pom.xml#L45 There are no dependencies on weld packages, as wicket-cdi-1.1 is fully portable. It only has a testing dependency on cdi-unit, which depends on weld. Emond On Tuesday 10 December 2013 09:07:52 Diogo Casado wrote: > Edmond, > > Please when you assembly the package for the new CDI version, use > scope provided for javax.* and org.jboss.* dependencies. > I'm fixing the plumbing of my project and several undesired packages > are being assembled because of current wicket-cdi. > Thank you for your efforts! > > - Diogo > > On Thu, Dec 5, 2013 at 6:09 PM, Emond Papegaaij > > wrote: > > The new module should be fully functional, including all scopes. The > > performance should be much better than with the old module, due to > > InjectionTarget caching. The biggest changes are in conversation > > propagation. If you do not use the conversation scope, the transition to > > the new module should be very smooth. > > > > Best regards, > > Emond > > > > Op 5 dec. 2013 20:24 schreef "Diogo Casado" : > >> Thanks Emond, > >> > >> I will watch the progress and report back. > >> For now.. I'm ignoring the warnings and using a snapshot from glassfish. > >> I'm using CDI just for EntityManager injection..and it's just > >> RequestScoped. > >> So.. from what I saw in the current version, the biggest problem would > >> be if it was context oriented. > >> > >> Regards, > >> Diogo C. > >> > >> > >> On Wed, Dec 4, 2013 at 7:01 PM, Emond Papegaaij > >> > >> wrote: > >> > Hi Diogo, > >> > > >> > Please note that wicket-cdi-1.1 is still experimental. I do have high > >> > confidence it will work fine, but it has not been tested extensively. > >> > The > >> > API is mostly compatible with the current wicket-cdi module. One of the > >> > changes is that the constructor of the CdiConfiguration no longer takes > >> > a > >> > BeanManager. CDI 1.1 has several portable ways of looking up this > >> > BeanManager. A fallback is added (see CdiConfiguration), in case your > >> > environment does not provide any of the portable lookup methods, but > >> > Glassfish should. Also, it is no longer possible to disable injection > >> > of > >> > various Wicket classes. Components, behaviors, sessions and the > >> > >> application > >> > >> > are always injected. > >> > > >> > A major difference in behavior is the way conversations are propagated. > >> > >> The > >> > >> > current cdi module uses non-portable code (which only works with Weld) > >> > to > >> > propagate the conversation. wicket-cdi-1.1 always propagates the > >> > conversation via the url (with the cid query-parameter), which is > >> > >> portable > >> > >> > across all CDI 1.1 providers. > >> > > >> > As Martin mentioned, wicket-cdi-1.1 requires a recent version of Weld > >> > (if > >> > used with Weld). Weld 2.1.1 (which has not yet been released) has some > >> > fixes regarding warning floods ( > >> > >> https://issues.jboss.org/browse/WELD-1547). > >> > >> > Until then, you either have to ignore the warnings or lower the logging > >> > level. > >> > > >> > To use wicket-cdi-1.1, once wicket 6.13 is released, add the following > >> > dependency: > >> > > >> > > >> > org.apache.wicket > >> > wicket-cdi-1.1 > >> > 0.2 > >> > > >> > > >> > > >> > Until then, you can test with 0.2-SNAPSHOT. You can find the details > >> > for > >> > the snapshot repository on our download page. > >> > > >> > If you find any issues with wicket-cdi-1.1, please file JIRA issues and > >> > assign them to me. > >> > > >> > Best regards, > >> > Emond Papegaaij > >> > > >> > > >> > On Wed, Dec 4, 2013 at 7:02 PM, Diogo Casado > >> > >> wrote:
Re: response headers in Wicket 6
Just remove them. Wicket do not persist the form components' values anymore. On Tue, Dec 10, 2013 at 4:10 PM, Entropy wrote: > Thanks Francois, > > Second question: > > In 1.4.7 the page object supported a removePersistedFormData() method and > the TextField has a method setPersistent() on it. Both appear gone, and I > don't see anything in the 6 or 1.5 conversion guides about them. What is > the replacement? > > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/response-headers-in-Wicket-6-tp4662864p4662888.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: response headers in Wicket 6
Thanks Francois, Second question: In 1.4.7 the page object supported a removePersistedFormData() method and the TextField has a method setPersistent() on it. Both appear gone, and I don't see anything in the 6 or 1.5 conversion guides about them. What is the replacement? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/response-headers-in-Wicket-6-tp4662864p4662888.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket CDI Status
Edmond, Please when you assembly the package for the new CDI version, use scope provided for javax.* and org.jboss.* dependencies. I'm fixing the plumbing of my project and several undesired packages are being assembled because of current wicket-cdi. Thank you for your efforts! - Diogo On Thu, Dec 5, 2013 at 6:09 PM, Emond Papegaaij wrote: > The new module should be fully functional, including all scopes. The > performance should be much better than with the old module, due to > InjectionTarget caching. The biggest changes are in conversation > propagation. If you do not use the conversation scope, the transition to > the new module should be very smooth. > > Best regards, > Emond > Op 5 dec. 2013 20:24 schreef "Diogo Casado" : > >> Thanks Emond, >> >> I will watch the progress and report back. >> For now.. I'm ignoring the warnings and using a snapshot from glassfish. >> I'm using CDI just for EntityManager injection..and it's just >> RequestScoped. >> So.. from what I saw in the current version, the biggest problem would >> be if it was context oriented. >> >> Regards, >> Diogo C. >> >> >> On Wed, Dec 4, 2013 at 7:01 PM, Emond Papegaaij >> wrote: >> > Hi Diogo, >> > >> > Please note that wicket-cdi-1.1 is still experimental. I do have high >> > confidence it will work fine, but it has not been tested extensively. The >> > API is mostly compatible with the current wicket-cdi module. One of the >> > changes is that the constructor of the CdiConfiguration no longer takes a >> > BeanManager. CDI 1.1 has several portable ways of looking up this >> > BeanManager. A fallback is added (see CdiConfiguration), in case your >> > environment does not provide any of the portable lookup methods, but >> > Glassfish should. Also, it is no longer possible to disable injection of >> > various Wicket classes. Components, behaviors, sessions and the >> application >> > are always injected. >> > >> > A major difference in behavior is the way conversations are propagated. >> The >> > current cdi module uses non-portable code (which only works with Weld) to >> > propagate the conversation. wicket-cdi-1.1 always propagates the >> > conversation via the url (with the cid query-parameter), which is >> portable >> > across all CDI 1.1 providers. >> > >> > As Martin mentioned, wicket-cdi-1.1 requires a recent version of Weld (if >> > used with Weld). Weld 2.1.1 (which has not yet been released) has some >> > fixes regarding warning floods ( >> https://issues.jboss.org/browse/WELD-1547). >> > Until then, you either have to ignore the warnings or lower the logging >> > level. >> > >> > To use wicket-cdi-1.1, once wicket 6.13 is released, add the following >> > dependency: >> > >> > org.apache.wicket >> > wicket-cdi-1.1 >> > 0.2 >> > >> > >> > Until then, you can test with 0.2-SNAPSHOT. You can find the details for >> > the snapshot repository on our download page. >> > >> > If you find any issues with wicket-cdi-1.1, please file JIRA issues and >> > assign them to me. >> > >> > Best regards, >> > Emond Papegaaij >> > >> > >> > On Wed, Dec 4, 2013 at 7:02 PM, Diogo Casado >> wrote: >> > >> >> It looks like it is running with glassfish4 snapshot 4.1 b4m1. >> >> They use the latest version of weld on it. >> >> Well.. I will continue this way.. >> >> Do you have an idea on when we will have v6.13 with cdi1.1? >> >> Thank you very much. >> >> >> >> On Wed, Dec 4, 2013 at 2:07 PM, Martin Grigorov >> >> wrote: >> >> > Hi, >> >> > >> >> > I am not very into CDI business but here are some solutions: >> >> > - upgrade Weld to 2.1.0 in Glassfish 4, if this is possible. The >> >> exception >> >> > is caused by a bug in Weld 2.0.x >> >> > - use Wicket 6.9.0. This will work unless you use @Inject in anonymous >> >> > Wicket components. I personally never thought about this pattern >> before >> >> > Wicket 6.9.1. I guess you don't use it too >> >> > - Wicket 6.13.0 will bring wicket-cdi-1.1 module. But again it will >> work >> >> > only if you use it with Weld 2.1.x >> >> > >> >> > >> >> > On Wed, Dec 4, 2013 at 5:01 PM, Diogo Casado >> >> wrote: >> >> > >> >> >> Hello guys.. >> >> >> >> >> >> I'm setting up a Glassfish4 environment with wicket 6.12.0 and I >> >> >> previously started using cdi to inject entity managers. >> >> >> On Tomee, cdi was working but I decided that this particular >> >> >> application will need a more robust JavaEE server (specially because >> >> >> of OpenJPA slow pace). >> >> >> >> >> >> Anyway.. I'm getting warnings everywhere and specially this exception >> >> >> that just broke the app: >> >> >> WELD-70 Simple bean [EnhancedAnnotatedTypeImpl] class >> >> >> comLoginPage$1 cannot be a non-static inner class >> >> >> >> >> >> The offending class is basically a anonymous Form.. I conclude that >> >> >> any anonymous class would cause this. >> >> >> >> >> >> Found this ticket: https://issues.apache.org/jira/browse/WICKET-5264 >> >> >> I guess it happened before and was fixed in v6.9.0 but I'm stil
