Re: how to fix this error in wicket app
That's great! Thanks On 16/1/13 17:25, saty wrote: Yes, this has been fixed in wicket 6.4.0 See below for more on this fix. http://apache-wicket.1842946.n4.nabble.com/understanding-ajax-response-td4654310.html#a4654715 -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/how-to-fix-this-error-in-wicket-app-tp4653954p4655431.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
Add an invisible component to an AjaxRequestTarget target
Hi, We have partial page updates all over a page. So panels and components all over the place that need Ajax updates. We're using an Interface on those components and with an IVisitor we traverse the component tree and add every component to the target that has this interface. But during development we see that we get errors in the ajax debug log when these components have an invisible state. These components themselves can have this state but some of the times, the parent component is invisible. In these cases when such a hidden component is added to the AjaxRequestTarget we get an error in the ajax debug log. Adding the isVisible check before adding the component to the target could save us in some situations but not all (as it might get visible or invisible) at a later state. How can I prevent these components from being added to the AjaxRequestTarget? Or from the error being thrown? I had hoped that a component being in an invisible state (somewhere in the tree) wouldn't get rendered. It's not really a problem in a 'deployment' situation, but it's not 'nice' either. Thijs - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Add an invisible component to an AjaxRequestTarget target
OK thnx will give it a try On 6/9/12 22:39, Igor Vaynberg wrote: isVisibleInHierarchy() will make sure all parents are visible as well -igor On Thu, Sep 6, 2012 at 1:27 PM, Thijs Vonk vonk.th...@gmail.com wrote: Hi, We have partial page updates all over a page. So panels and components all over the place that need Ajax updates. We're using an Interface on those components and with an IVisitor we traverse the component tree and add every component to the target that has this interface. But during development we see that we get errors in the ajax debug log when these components have an invisible state. These components themselves can have this state but some of the times, the parent component is invisible. In these cases when such a hidden component is added to the AjaxRequestTarget we get an error in the ajax debug log. Adding the isVisible check before adding the component to the target could save us in some situations but not all (as it might get visible or invisible) at a later state. How can I prevent these components from being added to the AjaxRequestTarget? Or from the error being thrown? I had hoped that a component being in an invisible state (somewhere in the tree) wouldn't get rendered. It's not really a problem in a 'deployment' situation, but it's not 'nice' either. Thijs - 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: Using Eclipse Wicket for Modular Webapps
Looks really interresting, I've read the pdf. but it seems that there is a part missing at the end... On 2/6/09 6:02 PM, Thomas Mäder wrote: Hi Folks, I've been experimenting with getting the Eclipse plugin engine up inside a wicket application. The idea is to build Wicket applications out of plugins. You can find an article about my experiences (+sample code) here: http://devotek-it.ch/stuff.html I'm grateful for any feedback, both concerning the Eclipse/OSGI and the Wicket part. enjoy the weekend Thomas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Problems Ajax with Portlet 2.0 in Liferay 5.2.1
This is an issue with Liferay (see
http://issues.liferay.com/browse/LPS-1911)
You can probably fix it by making sure that portlet-name (in
portlet.xml) and the wicketfilter mapping url-pattern are identical
(portlet.xml web.xml)
On 2/5/09 4:30 PM, Benjamin Ernst wrote:
Hi,
I am Testing the new Portlet 2.0 with Liferay and have some problems with
Ajax-calls.
I am using wicket 1.4-SNAPSHOT(Revision 741130) and Liferay Portal Standard
Edition 5.2.1 (Augustine / Build 5201 / February 3, 2009).
I have a simple page with one label and one Ajaxlink:
public HomePage(final PageParameters parameters) {
final Label label = new Label(label, new
PropertyModelInteger(this, value));
label.setOutputMarkupId(true);
add(label);
AjaxLink link = new AjaxLink(link)
{
@Override
public void onClick(AjaxRequestTarget target) {
value = value + 1;
target.addComponent(label);
}
};
add(link);
}
The portlet is shown correctly but when I click the Ajaxlink nothing
happens. In the Ajax-Debug-Log appears the following text:
INFO:
INFO: Initiating Ajax POST request on
http://localhost:8080/web/guest/home?random=0.9410006487742066
INFO: Invoking pre-call handler(s)...
INFO: Received ajax response (84 characters)
INFO:
The requested resource (/ACE_PortletTest-1.0-SNAPSHOT/portlettest/) is not
available
ERROR: Error while parsing response: Could not find rootajax-response
element
INFO: Invoking post-call handler(s)...
INFO: Invoking failure handler(s)...
This is the log form Java when the Ajax-Link is clicked:
DEBUG - 0-SNAPSHOT]- servletPath=/ACETEST, pathInfo=/invoke,
queryString=null, name=null
DEBUG - 0-SNAPSHOT]- Path Based Forward
DEBUG - WicketPortlet - Portlet RESOURCE_PHASE for wicket
url:/portlettest/?wicket:interface=:0:link::IBehaviorListener:0:
DEBUG - 0-SNAPSHOT]- servletPath=/portlettest/,
pathInfo=null, queryString=wicket:interface=:0:link::IBehaviorListener:0:,
name=null
DEBUG - 0-SNAPSHOT]- Path Based Include
DEBUG - WicketPortlet - redirect url after inclusion:null
DEBUG - WicketPortlet - end of request, wicket
url:/portlettest/?wicket:interface=:0:link::IBehaviorListener:0:
DEBUG - 0-SNAPSHOT]- Disabling the response for futher
output
DEBUG - 0-SNAPSHOT]- The Response is vehiculed using a
wrapper: com.liferay.portal.servlet.AbsoluteRedirectsResponse
Here is my web.xml and my portlet.xml:
?xml version=1.0 encoding=ISO-8859-1?
web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=
http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
version=2.4
display-nameACE_PortletTest/display-name
context-param
param-nameorg.apache.wicket.detectPortletContext/param-name
param-valuetrue/param-value
/context-param
context-param
param-nameconfiguration/param-name
param-valuedevelopment/param-value
!-- param-valuedeployment/param-value --
/context-param
filter
filter-namewicket.ACE_PortletTest/filter-name
filter-classorg.apache.wicket.protocol.http.WicketFilter/filter-class
init-param
param-nameapplicationClassName/param-name
param-valuede.acando.ace.WicketApplication/param-value
/init-param
/filter
filter-mapping
filter-namewicket.ACE_PortletTest/filter-name
url-pattern/portlettest/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
/filter-mapping
/web-app
?xml version=1.0 encoding=UTF-8?
portlet-app xmlns=http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=1.0
xsi:schemaLocation=http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd
http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd;
portlet
descriptionACE Test/description
portlet-nameACETEST/portlet-name
display-nameACETEST/display-name
portlet-classorg.apache.wicket.protocol.http.portlet.WicketPortlet/portlet-class
init-param
namewicketFilterPath/name
value/portlettest/value
/init-param
supports
mime-typetext/html/mime-type
portlet-modeVIEW/portlet-mode
portlet-modeEDIT/portlet-mode
/supports
supports
mime-typetext/xml/mime-type
portlet-modeVIEW/portlet-mode
portlet-modeEDIT/portlet-mode
/supports
portlet-info
titleACE Portlet Test/title
keywordsACE Portlet Test/keywords
/portlet-info
/portlet
container-runtime-option
namejavax.portlet.escapeXml/name
valuefalse/value
/container-runtime-option
/portlet-app
I have no idea whats
Re: Portlets (JSR-168) and Ajax
I have no experience with WSRP, but I do know that the portal should support a bit more then just jsr-168. See http://cwiki.apache.org/WICKET/portal-howto.html also the way DWR does it is different then the way wicket works. If I remember correctly DWR functions as a separate servlet next to te portal that catches the ajax requests. With wicket the portlet itself handles the ajax request and response, which officially isn't supported by jsr-168. Thijs On 11/22/08 5:42 PM, Adriano dos Santos Fernandes wrote: Hi! I'm trying to create portlets with Wicket, to use in Oracle Portal. Portlets on it is with JSR-168 via WSRP. And I'm having trouble... But before go further, I want to know, with JSR-168 can I use Ajax? On my environment, Oracle Portal and the portlets application runs in different servers, but on the Portal server there is a URL redirection to the application server. I have portlets using AJAX with DWR working there... Adriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invalid URLPatternSpec for Ajax Calls in Wicket Portlet
https://issues.apache.org/jira/browse/WICKET-1620 (Though it's still a work in process) and not yet supported by the wicket core committers On 11/20/08 9:17 PM, krisNog wrote: which portlet 2 patch are you referring to? Where is it available? Thanks Thijs wrote: But does it also have a problem if it's running a standalone wicket application? Btw I've run wicket portlets (with the portlet 2 patch) in Glassfish open portal portlet container(v. rc2 then) and that worked just fine... So I don't know what the problem could be... Thijs On 11/19/08 8:44 PM, krisNog wrote: The difference appears to be : vs %3A (the URL encoded : ) in urls. For example wicket seems to be creating test:test2 in Firefox and test%3Atest2 in IE. Glassfish doesn't like the : Thijs wrote: Do you know what is send differently to the server in FF2 vs IE (WireShark?) And where the error is thrown, why it says that the URLPatternSpec is invalid... Thijs On 18-11-2008 22:57, prasana wrote: Hi all, We are running Wicket Portlet in Jetspeed Portal deployed in Glassfish. But whenever we make a Ajax calls, it results in There are some problems in the request: invalid URLPatternSpec|# in the server log file and Ajax Debug windows shows ERROR: Received Ajax response with code: 400 The above error happens only in Firefox 2 and not in IE 6/7 I greatly appreciate any help regarding on what I need to do to see the workflow actions for assets. Thanks Prasanna - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to navigate from edit mode to view mode
You'll have to be more specific. What kind of problems. What works, what doesn't etc. Singh Mukesh wrote: Hi I have created a bookmark portlet using wicket. And the bookmark portlet includes two portlet- mode i.e. view and edit. I have deployed the basic portlet on sun portal. I have a problem with the navigation form edit mode to view mode. Do you have any good suggestion how to solve this problem? Thanks in advance Thanks and Regards, MUKESH SINGH CAPGEMINI Consultant Arrive AS T (+47) 46 47 90 16 E-post: [EMAIL PROTECTED] http://servicedesk.arrive.no - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Anybody tried Wicket with WebSphere portal?
Thats not completely correct. The current Wicket implementation depends on the PortletBridge implementation and is not 286 ready. Athough it has some 286 features like the resourceUrl, that part of the implementation depends on the PortletBridge implementation. Work is in progress to make Wicket more jsr-286 compliant, but at this point there is not a final solution or a timeframe for a final solution. Peter Eriksson wrote: Hello everybody, In my day job I use WebSphere Portal, working as a consultant, and I have been using JSF in portlet development and really found it quite painful. The version of WebSphere Portal is 6.0 and that uses JSF 1.1 and I know things have improved somewhat in more recent versions of JSF, but that is not really helping much. Now to my question, I have been trying out Wicket and I find it very nice to work with compared to JSF and I really would like to use it in WebSphere Portal, so is anybody out there using it with WebSphere Portal 6? I have read a few postings regarding portal support and understood that it depends on how and if the PortletBridge is implemented in the Portlet container of the vendor in question. WebSphere Portal 6.0 is JSR168 compliant and I know that the upcoming release WebSphere Portal 6.1 is going to be JSR286 compliant and that Wicket support should be working in a JSR286 environment without problem, or have I misunderstood something? Best Regards, /Peter Eriksson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket portles in Sun Portal
Ate Douma wrote: Wilhelmsen Tor Iver wrote: To dig up this old thread: I now use Ate Douma's patch for JSR-286 support from https://issues.apache.org/jira/browse/WICKET-1620 which has removed the need for the portal to implement the Apache portlet bridge's two interfaces. A small step for man etc. :) Well, credits for those patches go to Thijs Vonk, I'm just the assignee of that issue :) Note though: those patches *as such* still need quite some refactoring (as already discussed on this list before) and the final JSR-286 support very likely will turn out a little bit different... For those who haven't discovered this yet, I might have a nice news update: JSR-286 has finally landed! See: http://jcp.org/aboutJava/communityprocess/final/jsr286/index.html Finally :) There now is an issue - the same I had in JBoss - that it seems the bridge has a bug where the WicketFilterPortletContext call to ServletPortletSessionProxy.createProxy(filterRequestContext.getRequest() ) places a Double into the window-id propery that later will be cast to String... No. This is *not* a bug in the bridge, but one in their portlet container implementation. The method concerning this issue is o.a.p.bridges.util.PortletWindowUtils.getPortletWindowId(PortletSession) That method (which I wrote) is 100% following the JSR-168 specification, its just too bad JBoss Portal (and now it seems also Sun Portal) fail to follow those rules concerning this functionality. ... makes me wonder if they (now) share some common codebase ? ... Anyway, I know this is annoying and I could maybe fix this through a workaround (not sure yet though: this exception might indicate something more/worse is wrong, but I haven't debugged *their* engines yet). But... such a fix or workaround will take some time to formally land in a new release of bridges anyway, and maybe by that time this is moot if we have (basic) JSR-286 support in place for Wicket by then ... I tested on Sun Portlet container and ran into this problem as well. The 'QuickFix' I used was to alter the Bridges code and check if it was a String or not and depending I cast to String or to Double and then to String. I know it's dirty (as I didn't check if it actually is a worse problem as Ate indicated), but after I fixed that I haven't run into any other problems with it yet. Note though that you have to build a svn copy of the portlet-container. RC2 contains a bug I found which prevents Ajax to work correctly. Are there plans to completely disconnect the Wicket portlet impl. from the bridge (i.e. including this dependency to ServletPortletSessionProxy)? Yes/no. JSR-286 support will no longer need/depend on the two ServletContextProvider and PortletResourceURLFactory implementations. Additionally, the ServletPortletSessionProxy functionality *might* be replaced by a native JSR-286 feature but... that is an optional feature of the spec, so it depends if the underlying portlet container does support it or not. If not, the ServletPortletSessionProxy (which provides exactly the same functionality as this optional feature... wonder how come?) will still be needed. But in that case, the part you encountered the exception in comes from determining the Portlet WindowId, and *that* is now also formally provided by JSR-286 and thus can be resolved in a JSR-286 native way too. HTH, Ate - Tor Iver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Anchors in Wicket?
Michael Mehrle wrote: How do create a link that jumps to some anchor in a page? Is there a way to define this in Wicket or do I have to do this manually somehow? Michael yes. use link.setAnchor(Component) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: missing something: getting AjaxCheckBox to recheck value from model as its redrawn?
I'm not sure what you are saying here. But if it is what I'm thinking then you have misunderstood the meaning of .setDefaultFormProcessing. If your component is in a form, the 'defaultFormProcessing' will try to write any changes in the form to the model, and then call the onSubmit of the form, and finally the onSubmit of the button. If set to false it will skip all the form handling and call the onSubmit of the button directly. http://wicket.apache.org/docs/wicket-1.3.2/wicket/apidocs/org/apache/wicket/markup/html/form/Button.html#setDefaultFormProcessing(boolean) So if you are doing anything in the buttons 'onSubmit' that you don't want in certain cases, then calling setDefaultFormProcessing(false) won't have any affect. Thijs Kirk Israel wrote: the left/right moves ARE being done in the buttons onSubmit, I was hoping calling .setDefaultFormProcessing(false); when adding the button to the page would have prevented that? On Fri, May 23, 2008 at 4:50 AM, Thomas Mäder [EMAIL PROTECTED] wrote: Do the move left/move right controls do a submit? If so you might also be resubmitting the (old) check box value. Thomas We have a list view that iterates over manufacturers, and each manufacturer has a pallet control of devices (two list boxes w/ move selection to right list, move selection to left list buttons between) along with a all for manufacturer checkbox - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Portlets in Liferay 5
Hi Benjamin I'll see if I have some time left tomorrow, otherwise hopefully before next tuesday. Thijs Benjamin Ernst wrote: Hi Thijs, We are currently trying to integrate Liferay 5 with wicket 1.3. Can you give us the advise you offered? That would be very nice. Thank you in advance, Benjamin On Mon, May 5, 2008 at 11:33 PM, Thijs Vonk [EMAIL PROTECTED] wrote: Hi, Currently without building wicket against Liferay (using com.liferay.portlet.renderresponseimpl, instead of javax.portlet.renderresponse) it is not possible to run wicket without losing most of wickets functionality. I can, if you want, give you a patch and some instructions to get wicket working on liferay 5, but we are still modifying wicket and Liferay code to get things working as we want it. So I can't guaranty anything. Thijs Bobby Quninne wrote: Hi there, I am currently considering using wicket 1.3.3(and newer) with liferay 5. The site is going to be used for backend administration, standard CRUD stuff. How big a risk is it, using wicket portal and liferay? Thanks Thijs wrote: Hi, I'm working on getting wicket compatible with jsr-286 now. However while doing this I've noticed that Liferay has still some major issues regarding jsr-286. Especially regarding setting properties on the response (essentially setting response headers, cookies, etc) there is still some work to be done. They also don't support the MARKUP_HEAD_ELEMENT_SUPPORT feaure jet, what would be a really nice addition because of the CSS and JS files wicket adds to it's pages. Comment and vote on http://support.liferay.com/browse/LEP-5828. and track it to follow the property changes I'm also planning on opening a Wicket-jira issue so that you can track the progress of the wicket implementation. But we will have to wait at least until the portlet 2.0 specifications get official and added to a maven repository before we can add anything to the wicket code base. Besides that it's a lot of work and I'm doing this in my free hours so don't get over excited just jet :). I'll post a message on the list when I open the jira issue, and I'll attach patches to that issue as soon as I feel confident about the work I've been doing. I hope that answers your questions a bit. Thijs gaugat wrote: I've read in the forums, that it is better to wait for Liferay 5 (JSR 286) to develop portlets in Apache Wicket. So has anyone developed portlets using Wicket and deployed them in Liferay 5?. If you have, is there a sample wicket portlet posted somewhere that I could look at? Are there still issues with Wicket and Liferay? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Portlets in Liferay 5
Hi, I'm working on getting wicket compatible with jsr-286 now. However while doing this I've noticed that Liferay has still some major issues regarding jsr-286. Especially regarding setting properties on the response (essentially setting response headers, cookies, etc) there is still some work to be done. They also don't support the MARKUP_HEAD_ELEMENT_SUPPORT feaure jet, what would be a really nice addition because of the CSS and JS files wicket adds to it's pages. Comment and vote on http://support.liferay.com/browse/LEP-5828. and track it to follow the property changes I'm also planning on opening a Wicket-jira issue so that you can track the progress of the wicket implementation. But we will have to wait at least until the portlet 2.0 specifications get official and added to a maven repository before we can add anything to the wicket code base. Besides that it's a lot of work and I'm doing this in my free hours so don't get over excited just jet :). I'll post a message on the list when I open the jira issue, and I'll attach patches to that issue as soon as I feel confident about the work I've been doing. I hope that answers your questions a bit. Thijs gaugat wrote: I've read in the forums, that it is better to wait for Liferay 5 (JSR 286) to develop portlets in Apache Wicket. So has anyone developed portlets using Wicket and deployed them in Liferay 5?. If you have, is there a sample wicket portlet posted somewhere that I could look at? Are there still issues with Wicket and Liferay? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practice for a wait page
Scott Swank wrote:
We have a page with a form and the form's onSubmit() method takes a
while. After it is complete the user is re-directed to another page.
We'd like to introduce a nice please wait while we process your
request page in between these pages. If anyone has done this, what
approach has worked well for you?
public class Page1 extends ...
{
...
add(new SomeForm()
{
public void onSubmit()
{
aBunchOfProcessing();
redirect(new Page2());
}
}
...
}
Thank you,
Scott
How about using a LazyLoadingPanel (or similar?) see wicket-extention
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
