Wicket Portlets
Is anyone here using Wicket in a portal (i.e. for portlets)? I'm trying to figure out how to switch pages when the user changes Portlet mode (e.g. VIEW - EDIT). Looking through the source, it looks like the responsible method (WicketPortlet#getWicketConfigParameter(PortletRequest request, String paramName, String defaultValue)) doesn't do anything except return the given defaultValue, whereas I was expecting it to try and look up the page for the given paramName...! :( Has anyone got around this problem?
Re: Wicket Portlets
For us this works in the Application class:
/**
* @see wicket.Application#getHomePage()
*/
public Class? extends Page getHomePage()
{
PortletRequestContext prc = (PortletRequestContext)
RequestContext.get();
if (PortletMode.EDIT.equals(prc.getPortletRequest().getPortletMode()))
{
return EditPage.class;
}
return HomePage.class;
}
On 19-7-2010 11:34, Gareth Western wrote:
Is anyone here using Wicket in a portal (i.e. for portlets)? I'm trying to
figure out how to switch pages when the user changes Portlet mode (e.g. VIEW
- EDIT).
Looking through the source, it looks like the responsible method
(WicketPortlet#getWicketConfigParameter(PortletRequest request, String
paramName, String defaultValue)) doesn't do anything except return the given
defaultValue, whereas I was expecting it to try and look up the page for the
given paramName...! :(
Has anyone got around this problem?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Portlets
Thanks Thijs!
I also found another example that works sitting in the Wicket SVN repo:
https://svn.apache.org/repos/asf/wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/portlet/menu/
Basically all I needed to do was add the init-params to my portlet.xml (in
addition to the standard portlet-mode bits):
init-param
nameviewPage/name
value/customModes/view/value
/init-param
init-param
nameeditPage/name
value/customModes/edit/value
/init-param
init-param
namehelpPage/name
value/customModes/help/value
/init-param
(/customModes is my wicketFilterPath)
And then, in my WebApplication class:
@Override
public Class? extends Page getHomePage() {
return ViewPage.class;
}
@Override
protected void init() {
mountBookmarkablePage(/view, ViewPage.class);
mountBookmarkablePage(/edit, EditPage.class);
mountBookmarkablePage(/help, HelpPage.class);
}
And it's all working fine now. Whew!
On Mon, Jul 19, 2010 at 12:58 PM, Thijs vonk.th...@gmail.com wrote:
For us this works in the Application class:
/**
* @see wicket.Application#getHomePage()
*/
public Class? extends Page getHomePage()
{
PortletRequestContext prc = (PortletRequestContext)
RequestContext.get();
if (PortletMode.EDIT.equals(prc.getPortletRequest().getPortletMode()))
{
return EditPage.class;
}
return HomePage.class;
}
On 19-7-2010 11:34, Gareth Western wrote:
Is anyone here using Wicket in a portal (i.e. for portlets)? I'm trying to
figure out how to switch pages when the user changes Portlet mode (e.g.
VIEW
- EDIT).
Looking through the source, it looks like the responsible method
(WicketPortlet#getWicketConfigParameter(PortletRequest request, String
paramName, String defaultValue)) doesn't do anything except return the
given
defaultValue, whereas I was expecting it to try and look up the page for
the
given paramName...! :(
Has anyone got around this problem?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Wicket Portlets and Liferay
Hi, We want to use Wicket Portlets in Liferay. The first step would be that all the wicket-example stuff is working - including Ajax. Onfortunately it does not work as intended. The versions to be used are: - Liferay-5.2.2 with Tomcat 6 (currently they use 6.0.18) bundled - Apache Wicket 1.4.5 The tests I did so far are: Jetspeed-2 with Tomcat 6.0.18 and wicket 1.4.5 - everything is working Liferay-5.2.2 with Jetty bundled, wicket-1.4.5 - everything is working Liferay-5.2.2 with Tomcat bundled, wicket-1.4.5 - nothing is displayed Liferay-5.2.2 with Tomcat bundled, wicket-1.4-rc2: porlets working, ajax stuff not Liferay-5.2.2 with Tomcat bundled, wicket 1.4.5 but portlet.xml removed: methods work (incl. Ajax), but as it is unusable (no portlets). Any experience? Klaus - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
AW: Wicket Portlets and Liferay
Hi, I stumbled across this problem, too. I was using LR 5.2.3 with Tomcat 6 bundled and Wicket 1.4.3. After several unsuccessful tries to get the wicket examples running, I tried to get a simple wicket portlet running. After several frustrating days, I got it running. Here's what I did: 1) Mime types Liferay apparently does not support wildcards in portlet.xml for the //supports/mime-type element. Instead of supports mime-type*/*/mime-type portlet-modeVIEW/portlet-mode /supports I had to use: supports mime-typetext/html/mime-type portlet-modeVIEW/portlet-mode /supports For AJAX/resource requests, another supports element for mime-type text/xml is needed. 2) Name congruence in deployment descriptors The name in the pattern under //filter-mapping/url-pattern in web.xml (e.g. /testPortlet/*) has to match with the value under //portlet/portlet-name in portlet.xml, otherwise the portlet will not be rendered, or you get StackOverflowExceptions in LR. //portlet/init-param[name='wicketFilterPath']/value has to be adapted accordingly, e.g. /testPortlet. Otherwise the portal shows a message The requested resource (/hellowicket-portlet-1.0-SNAPSHOT/testPortlet/) is not available. instead of the actual portlet content. (The entry in liferay-display.xml should be adapted, too, otherwise the portlet will be listed under the category Undefined in the application chooser.) 3) Activate portlet mode for Wicket I used the web.xml method to tell wicket to run in portlet mode. In web.xml of my wicket portlet, I added: context-param param-nameorg.apache.wicket.detectPortletContext/param-name param-valuetrue/param-value /context-param Otherwise, I got an java.lang.IllegalArgumentException: URL path must start with a '/' or include '://' 4) FORWARD dispatcher in filter mapping An additional FORWARD dispatching in the servlet-filter for the wicket portlet is indispensable, otherwise you get StackOverflow exceptions: filter-mapping filter-namewicket.testPortlet/filter-name url-pattern/testPortlet/*/url-pattern dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher !-- important -- dispatcherINCLUDE/dispatcher /filter-mapping 5) Spring In web.xml of my wicket portlet, another context-param is needed so that Spring can find the context configuration for the WebApplicationContext of wicket: context-param param-namecontextConfigLocation/param-name param-valueclasspath*:applicationContext.xml/param-name /context-param Also needed there: listener listener-classorg.springframework.web.context.ContextLoaderListener/listener-class /listener Otherwise, I got the following message during deployment of the wicket portlet: FATAL: Error filterStart Hope this helps. Cheers, Andreas -- Andreas Thiel Principal Consultant mailto:andreas.th...@valtech.de Mobile: +49 172 8982687 Valtech GmbH Bahnstraße 16 40212 Düsseldorf Germany Phone: +49 211 179237-0 Fax: +49 211 179237-19 http://www.valtech.de Geschäftsführer: Ingo Kriescher Amtsgericht Düsseldorf HRB48672 -Ursprüngliche Nachricht- Von: Klaus Astner [mailto:klaus.ast...@ec3.at] Gesendet: Mittwoch, 13. Januar 2010 09:40 An: users@wicket.apache.org Betreff: Wicket Portlets and Liferay Hi, We want to use Wicket Portlets in Liferay. The first step would be that all the wicket-example stuff is working - including Ajax. Onfortunately it does not work as intended. The versions to be used are: - Liferay-5.2.2 with Tomcat 6 (currently they use 6.0.18) bundled - Apache Wicket 1.4.5 The tests I did so far are: Jetspeed-2 with Tomcat 6.0.18 and wicket 1.4.5 - everything is working Liferay-5.2.2 with Jetty bundled, wicket-1.4.5 - everything is working Liferay-5.2.2 with Tomcat bundled, wicket-1.4.5 - nothing is displayed Liferay-5.2.2 with Tomcat bundled, wicket-1.4-rc2: porlets working, ajax stuff not Liferay-5.2.2 with Tomcat bundled, wicket 1.4.5 but portlet.xml removed: methods work (incl. Ajax), but as it is unusable (no portlets). Any experience? Klaus - 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: Wicket Portlets and Liferay
We are running Wicket + Liferay (Webspace) in Glassfish 2, and experience no problems; IIRC Glassfish uses the same Catalina engine as Tomcat? For AJAX/resource requests, another supports element for mime-type text/xml is needed. This sounds like a Tomcat issue, our portlets use Ajax fine without such a mime-type setting. 2) Name congruence in deployment descriptors The name in the pattern under //filter-mapping/url-pattern in web.xml (e.g. /testPortlet/*) has to match with the value under //portlet/portlet-name in portlet.xml, otherwise the portlet will not be rendered, or you get StackOverflowExceptions in LR. Again, possibly a Tomcat issue, in Glassfish we use e.g. a name LocalMessagesPortlet with the filter-mapping /localmessages/* with no issues The requested resource (/hellowicket-portlet-1.0- SNAPSHOT/testPortlet/) is not available. instead of the actual portlet content. I would recommend using a more readable build/finalName pom.xml setting instead of the version-appended artifact name unless you want to deploy multiple versions. - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: SV: Wicket Portlets and Liferay
On 13-1-2010 14:20, Wilhelmsen Tor Iver wrote: We are running Wicket + Liferay (Webspace) in Glassfish 2, and experience no problems; IIRC Glassfish uses the same Catalina engine as Tomcat? For AJAX/resource requests, another supports element for mime-type text/xml is needed. This sounds like a Tomcat issue, our portlets use Ajax fine without such a mime-type setting. This is a Liferay issue, they don't support */* so when using ajax you need: supports mime-typetext/html/mime-type mime-typetext/xml/mime-type portlet-modeVIEW/portlet-mode /supports 2) Name congruence in deployment descriptors The name in the pattern under //filter-mapping/url-pattern in web.xml (e.g. /testPortlet/*) has to match with the value under //portlet/portlet-name in portlet.xml, otherwise the portlet will not be rendered, or you get StackOverflowExceptions in LR. Again, possibly a Tomcat issue, in Glassfish we use e.g. a name LocalMessagesPortlet with the filter-mapping /localmessages/* with no issues The requested resource (/hellowicket-portlet-1.0- SNAPSHOT/testPortlet/) is not available. instead of the actual portlet content. I would recommend using a more readable build/finalName pom.xml setting instead of the version-appended artifact name unless you want to deploy multiple versions. For the portlet naming check http://issues.liferay.com/browse/LPS-1911?focusedCommentId=52180#action_52180 and further the portet war should end with -portlet - 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
Re: SV: Wicket Portlets and Liferay
Many thanks to Andreas, now it works smoothly. - Klaus Am 13.01.2010 um 14:20 schrieb Wilhelmsen Tor Iver: We are running Wicket + Liferay (Webspace) in Glassfish 2, and experience no problems; IIRC Glassfish uses the same Catalina engine as Tomcat? For AJAX/resource requests, another supports element for mime-type text/xml is needed. This sounds like a Tomcat issue, our portlets use Ajax fine without such a mime-type setting. 2) Name congruence in deployment descriptors The name in the pattern under //filter-mapping/url-pattern in web.xml (e.g. /testPortlet/*) has to match with the value under //portlet/portlet-name in portlet.xml, otherwise the portlet will not be rendered, or you get StackOverflowExceptions in LR. Again, possibly a Tomcat issue, in Glassfish we use e.g. a name LocalMessagesPortlet with the filter-mapping /localmessages/* with no issues The requested resource (/hellowicket-portlet-1.0- SNAPSHOT/testPortlet/) is not available. instead of the actual portlet content. I would recommend using a more readable build/finalName pom.xml setting instead of the version-appended artifact name unless you want to deploy multiple versions. - 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
Wicket Portlets : content-type problem
Hello,
I'm currently facing a problem with a simple code. I'm trying and display a
YUI Carousel but my portal (eXo Platform) gives me an error :
exception returned by processAction() or render() methods
java.lang.IllegalStateException: the content type has not been set before
calling thegetPortletOutputStream() method.
Here is the code, which works in a servlet context :
ListString list = Arrays.asList(new String[] { images/bangkok.jpg,
images/hk.jpg,
images/jakarta.jpg, images/sgp.jpg,
images/neuschwanstein.jpg,
images/hongkong.png, images/singapore.png });
add(new YuiCarouselString(carousel, list)
{
@Override
protected Component newPanel(String id, String object)
{
return new ImagePanel(id, object);
}
}
I've seen several people having the same problem on the Net but was unable
to find a solution. Any help would be greatly appreciated.
Regards,
Pierre
--
Sans amis était le grand maître des mondes,
Eprouvait manque, ce pour quoi il créa les esprits,
Miroirs bienveillants de sa béatitude.
Mais au vrai, il ne trouva aucun égal,
Du calice du royaume total des âmes
Ecume jusqu'à lui l'infinité.
(Schiller, l'amitié)
Re: Portlets - Loosing state in wicket portlets
You could try setting
layout.default.p_l_reset=false
to portal-ext.properties and see if it helps keeping the state of the
portlets.
(http://www.liferay.com/web/guest/community/forums/-/message_boards/message/2190331#_19_message_2214544)
Benjamin Ernst wrote:
Hi,
I am using two Wicket-Portlets in a Liferay 5.2.1 Portal. Both Portlets
have
a link which switches to another page within the portlet (via
setResponsepage(new
Page()) ).
When I click the link in Portlet_1 the page within the portlet one changes
as desired. After that I click the link in Portlet_2 and the page in
Portlet_2 changes as desired, but i Portlet_1 the page changes to the
Homepage.
I think that the problem might be in the getWicketURL(PortletRequest
request, String pageType, String defaultPage) - method form
WicketPortlet.java:
protected String getWicketURL(PortletRequest request, String pageType,
String defaultPage)
{
String wicketURL = null;
// get the name of the wicket url paramater, as looked up from a
request attribute called
// WicketPortlet#WICKET_URL_PORTLET_PARAMETER_ATTR
String wicketUrlParameterName =
(String)request.getAttribute(WicketPortlet.WICKET_URL_PORTLET_PARAMETER_ATTR);
if (request instanceof ActionRequest)
{
// try to lookup the passed in wicket url parameter
wicketURL = request.getParameter(wicketUrlParameterName);
}
else if (request instanceof ResourceRequest)
{
wicketURL = ((ResourceRequest)request).getResourceID();
}
else
{
// try to lookup the passed in wicket url parameter, suffixed
with the portlet mode
String parameterName = wicketUrlParameterName +
request.getPortletMode().toString();
wicketURL = request.getParameter(parameterName);
}
// if the wicketURL could not be retrieved, return the url for the
default page
if (wicketURL == null)
{
wicketURL = getWicketConfigParameter(request,
CONFIG_PARAM_PREFIX + pageType,
defaultPage);
}
return wicketURL;
}
- In the RenderRequest for Portlet_2 the wicketUrlParameterName is for
the
Linklistener that was clicked. This works fine.
- In the RenderRequest for Portlet_1 the wicketUrlParameterName is null.
So
by default the defaultPage of Portlet_1 is loaded, which is the Homepage.
Is this the correct behaviour?
I think the wicketURL for the RenderRequest for Portlet_1 should not be
the
defaultPage but instead the last rendered Page from Portlet_1. Is there a
way to get the URL of the last page from Wicket?
Thanks for any help!
--Benjamin
--
View this message in context:
http://www.nabble.com/Portlets---Loosing-state-in-wicket-portlets-tp22431482p23668875.html
Sent from the Wicket - User 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 Portlets and Liferay
Hello Everyone! Im currently developing portlets with Wicket 1.4-rc2 and liferay 5.2 . They have some compatibility issues (portlet names must be equal the wicket filter-mappings). Does anyone know anyother issues? I saw in liferay foruns some guys that are developing portlets (in liferay) with wicket, but i dont know if they handled compatibilty issues changing some wicket or liferay code... If someone that did this kind of job, it would be great to have some feedback! thanks ! Bruno Ledesma
Re: Wicket Portlets and Liferay
Hi Bruno, I'm a beginner in wicket, also in liferay and was able to use wicket to construct a portlet. My first experience was a bit tough, a lot of minor problems Take a look at all the things find in the internet, I was trying to make a simple doc with all the issues but I was not able. The 2 most important things I remember: 1). Add to your portal-ext.properties this line portlet.container.impl=sun 2). Never call your appl/portlet-name with the same name as the url-mapping. Hope this helps tonio On Mon, May 11, 2009 at 10:44 AM, Bruno Ledesma led.br...@gmail.com wrote: Hello Everyone! Im currently developing portlets with Wicket 1.4-rc2 and liferay 5.2 . They have some compatibility issues (portlet names must be equal the wicket filter-mappings). Does anyone know anyother issues? I saw in liferay foruns some guys that are developing portlets (in liferay) with wicket, but i dont know if they handled compatibilty issues changing some wicket or liferay code... If someone that did this kind of job, it would be great to have some feedback! thanks ! Bruno Ledesma
Re: Wicket Portlets and Liferay
Well, its kind of curious... the 2nd issue that you posted: 2). Never call your appl/portlet-name with the same name as the url-mapping. In fact, I was not able to see my portlet if the portlet name and filter-mapping are differents. Just to confirm , when you say URL Mapping do you mean...? filter-mapping filter-namewickportlet/filter-name url-pattern/wickportlet/*/url-pattern dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping I had to put a url-pattern equal to the portlet name, and without any different char (like '-'). The first issue, i didn't knew nothing about it. thanks! Bruno Ledesma 2009/5/11 Tonio Caputo ton...@exeo.com.ar Hi Bruno, I'm a beginner in wicket, also in liferay and was able to use wicket to construct a portlet. My first experience was a bit tough, a lot of minor problems Take a look at all the things find in the internet, I was trying to make a simple doc with all the issues but I was not able. The 2 most important things I remember: 1). Add to your portal-ext.properties this line portlet.container.impl=sun 2). Never call your appl/portlet-name with the same name as the url-mapping. Hope this helps tonio On Mon, May 11, 2009 at 10:44 AM, Bruno Ledesma led.br...@gmail.com wrote: Hello Everyone! Im currently developing portlets with Wicket 1.4-rc2 and liferay 5.2 . They have some compatibility issues (portlet names must be equal the wicket filter-mappings). Does anyone know anyother issues? I saw in liferay foruns some guys that are developing portlets (in liferay) with wicket, but i dont know if they handled compatibilty issues changing some wicket or liferay code... If someone that did this kind of job, it would be great to have some feedback! thanks ! Bruno Ledesma
Re: Wicket Portlets and Liferay
Bruno, Well that is a surprise for me, this is my web file filter-mapping filter-namekmkApplication/filter-name url-pattern/kmk/*/url-pattern dispatcherREQUEST/dispatcher dispatcherINCLUDE/dispatcher dispatcherFORWARD/dispatcher /filter-mapping and my portlet file portlet-namekmkApplication/portlet-name init-param namewicketFilterPath/name value/kmk/value /init-param supports and it works pretty well :) I remember another thing, while I was pasting this XML don't use * for the *supports* tag, I begin writting something like supports mime-type*/*/mime-type portlet-modeVIEW/portlet-mode portlet-modeEDIT/portlet-mode /supports and finally need to put at least two items with mime-types *text/html* and *text/xml* if not it won't work. The important thing is just to get it working, hope it helps tonio On Mon, May 11, 2009 at 11:57 AM, Bruno Ledesma led.br...@gmail.com wrote: Well, its kind of curious... the 2nd issue that you posted: 2). Never call your appl/portlet-name with the same name as the url-mapping. In fact, I was not able to see my portlet if the portlet name and filter-mapping are differents. Just to confirm , when you say URL Mapping do you mean...? filter-mapping filter-namewickportlet/filter-name url-pattern/wickportlet/*/url-pattern dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping I had to put a url-pattern equal to the portlet name, and without any different char (like '-'). The first issue, i didn't knew nothing about it. thanks! Bruno Ledesma 2009/5/11 Tonio Caputo ton...@exeo.com.ar Hi Bruno, I'm a beginner in wicket, also in liferay and was able to use wicket to construct a portlet. My first experience was a bit tough, a lot of minor problems Take a look at all the things find in the internet, I was trying to make a simple doc with all the issues but I was not able. The 2 most important things I remember: 1). Add to your portal-ext.properties this line portlet.container.impl=sun 2). Never call your appl/portlet-name with the same name as the url-mapping. Hope this helps tonio On Mon, May 11, 2009 at 10:44 AM, Bruno Ledesma led.br...@gmail.com wrote: Hello Everyone! Im currently developing portlets with Wicket 1.4-rc2 and liferay 5.2 . They have some compatibility issues (portlet names must be equal the wicket filter-mappings). Does anyone know anyother issues? I saw in liferay foruns some guys that are developing portlets (in liferay) with wicket, but i dont know if they handled compatibilty issues changing some wicket or liferay code... If someone that did this kind of job, it would be great to have some feedback! thanks ! Bruno Ledesma
Re: Wicket Portlets and Liferay
Tonio, what are the wicket/liferay versions that you are using? My problem with filtermapping and porltet names are currently registered in liferay's JIRA You can take a look at: http://issues.liferay.com/browse/LPS-1911 But anyway, its working :) ! My fear right now is about using all wicket's features as a portlet. I need to know if there is any real world case of wicket apps as portlets. If there is, if uses a wide range of wicket's components and features... Knowing that, i'ĺl fell more safe to use wicket as my standard framework for portlets development in Liferay 5 (5.2). (sorry for the bad english :)) thanks ! Bruno 2009/5/11 Tonio Caputo ton...@exeo.com.ar Bruno, Well that is a surprise for me, this is my web file filter-mapping filter-namekmkApplication/filter-name url-pattern/kmk/*/url-pattern dispatcherREQUEST/dispatcher dispatcherINCLUDE/dispatcher dispatcherFORWARD/dispatcher /filter-mapping and my portlet file portlet-namekmkApplication/portlet-name init-param namewicketFilterPath/name value/kmk/value /init-param supports and it works pretty well :) I remember another thing, while I was pasting this XML don't use * for the *supports* tag, I begin writting something like supports mime-type*/*/mime-type portlet-modeVIEW/portlet-mode portlet-modeEDIT/portlet-mode /supports and finally need to put at least two items with mime-types *text/html* and *text/xml* if not it won't work. The important thing is just to get it working, hope it helps tonio On Mon, May 11, 2009 at 11:57 AM, Bruno Ledesma led.br...@gmail.com wrote: Well, its kind of curious... the 2nd issue that you posted: 2). Never call your appl/portlet-name with the same name as the url-mapping. In fact, I was not able to see my portlet if the portlet name and filter-mapping are differents. Just to confirm , when you say URL Mapping do you mean...? filter-mapping filter-namewickportlet/filter-name url-pattern/wickportlet/*/url-pattern dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping I had to put a url-pattern equal to the portlet name, and without any different char (like '-'). The first issue, i didn't knew nothing about it. thanks! Bruno Ledesma 2009/5/11 Tonio Caputo ton...@exeo.com.ar Hi Bruno, I'm a beginner in wicket, also in liferay and was able to use wicket to construct a portlet. My first experience was a bit tough, a lot of minor problems Take a look at all the things find in the internet, I was trying to make a simple doc with all the issues but I was not able. The 2 most important things I remember: 1). Add to your portal-ext.properties this line portlet.container.impl=sun 2). Never call your appl/portlet-name with the same name as the url-mapping. Hope this helps tonio On Mon, May 11, 2009 at 10:44 AM, Bruno Ledesma led.br...@gmail.com wrote: Hello Everyone! Im currently developing portlets with Wicket 1.4-rc2 and liferay 5.2 . They have some compatibility issues (portlet names must be equal the wicket filter-mappings). Does anyone know anyother issues? I saw in liferay foruns some guys that are developing portlets (in liferay) with wicket, but i dont know if they handled compatibilty issues changing some wicket or liferay code... If someone that did this kind of job, it would be great to have some feedback! thanks ! Bruno Ledesma
Re: Wicket Portlets and Liferay
Bruno, Looking at the issue, this is the reason of the difference *Environment: Liferay's internal portlet container (does not happen on Sun's portlet container) **1). Add to your portal-ext.properties this line portlet.container.impl=sun *This configuration makes liferay use Sun Portlet Container, so if your are not configuring liferay like this, not sure what will work or what not, I always tried my examples using this configuration. I'm in the middle of the same problem as you, use wicket or not, well not much to say around it, we are just beginning, and we are using wicket and portals for the first time. We tried these things, perhaps it can help you: - icefaces Definitely not usable until liferay 5.3 is available, and no sure what will happen then. Personally I don't like JSF too much after dealing with it (2/3 years ago). - GWT it works, not sure if for all portlet-containers, or just liferay ( I think just for liferay, I should check with the guy that test it), as I remember the only important issue: not too friendly to transform a GWT application to a portlet, and GWT learning curve (although I think in this case it worth it's value). - GI (Tibco General Interface) This is an interesting option, sure it works, the learning curve is high, the trouble with it: you must get stuck to their look and feel and it's pure javascript. - There is a liferay framework also JSP/Struts thing You can imagine that if I don't like JSF too much, JSP/Struts won't be one of my favorites, but it is there and it works. If you like we can share some of this things in spanish, but there is not much more than I can say for now, just use my e-mail. Hope it helps PD: We share our bad english knowlege too :) tonio * * 2009/5/11 Bruno Ledesma led.br...@gmail.com Tonio, what are the wicket/liferay versions that you are using? My problem with filtermapping and porltet names are currently registered in liferay's JIRA You can take a look at: http://issues.liferay.com/browse/LPS-1911 But anyway, its working :) ! My fear right now is about using all wicket's features as a portlet. I need to know if there is any real world case of wicket apps as portlets. If there is, if uses a wide range of wicket's components and features... Knowing that, i'ĺl fell more safe to use wicket as my standard framework for portlets development in Liferay 5 (5.2). (sorry for the bad english :)) thanks ! Bruno 2009/5/11 Tonio Caputo ton...@exeo.com.ar Bruno, Well that is a surprise for me, this is my web file filter-mapping filter-namekmkApplication/filter-name url-pattern/kmk/*/url-pattern dispatcherREQUEST/dispatcher dispatcherINCLUDE/dispatcher dispatcherFORWARD/dispatcher /filter-mapping and my portlet file portlet-namekmkApplication/portlet-name init-param namewicketFilterPath/name value/kmk/value /init-param supports and it works pretty well :) I remember another thing, while I was pasting this XML don't use * for the *supports* tag, I begin writting something like supports mime-type*/*/mime-type portlet-modeVIEW/portlet-mode portlet-modeEDIT/portlet-mode /supports and finally need to put at least two items with mime-types *text/html* and *text/xml* if not it won't work. The important thing is just to get it working, hope it helps tonio On Mon, May 11, 2009 at 11:57 AM, Bruno Ledesma led.br...@gmail.com wrote: Well, its kind of curious... the 2nd issue that you posted: 2). Never call your appl/portlet-name with the same name as the url-mapping. In fact, I was not able to see my portlet if the portlet name and filter-mapping are differents. Just to confirm , when you say URL Mapping do you mean...? filter-mapping filter-namewickportlet/filter-name url-pattern/wickportlet/*/url-pattern dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping I had to put a url-pattern equal to the portlet name, and without any different char (like '-'). The first issue, i didn't knew nothing about it. thanks! Bruno Ledesma 2009/5/11 Tonio Caputo ton...@exeo.com.ar Hi Bruno, I'm a beginner in wicket, also in liferay and was able to use wicket to construct a portlet. My first experience was a bit tough, a lot of minor problems Take a look at all the things find in the internet, I was trying to make a simple doc with all the issues but I was not able. The 2 most important things I remember: 1). Add to your portal-ext.properties this line portlet.container.impl=sun 2). Never call your appl/portlet-name with the same name as the url-mapping. Hope this helps tonio
Re: Wicket Portlets in WebLogic Portal?
Just FYI, I was able to get a Wicket portlet to render initially in WebLogic Portal using Java portlets (the Pageables example from the Wicket Examples page - http://www.wicket-library.com/wicket-examples/ajax/pageables.1), but none of the links to page through the results work with no errors. I think that this may be related to the implementation of those two Apache Portals Bridges interfaces mentioned earlier. If anyone has tried this before please let me know. Thanks! -- View this message in context: http://www.nabble.com/Wicket-Portlets-in-WebLogic-Portal--tp22605855p22661884.html Sent from the Wicket - User 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 Portlets in WebLogic Portal?
What version of liferay are you using? Wicket 1.3.x needs the portlet bridge implementation. (to cater for portlet1.0 spec). And for weblogic I think you'r on your own. This bridge implementation is portlet container specific. Wicket 1.4 you shouldn't need the portlet bridges any more but then Weblogic will need to fully support portlet 2.0 spec. I have no idea if they do. Thijs On 23-3-2009 16:00, jakewicket wrote: Just FYI, I was able to get a Wicket portlet to render initially in WebLogic Portal using Java portlets (the Pageables example from the Wicket Examples page - http://www.wicket-library.com/wicket-examples/ajax/pageables.1), but none of the links to page through the results work with no errors. I think that this may be related to the implementation of those two Apache Portals Bridges interfaces mentioned earlier. If anyone has tried this before please let me know. Thanks! - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Portlets in WebLogic Portal?
Thanks for the quick reply. I'm using WebLogic Portal, not Liferay. I'll have to see if WebLogic Portal fully supports the portlet 2.0 spec, and try upgrading to Wicket 1.4 (I was trying this with Wicket 1.3.5). -- View this message in context: http://www.nabble.com/Wicket-Portlets-in-WebLogic-Portal--tp22605855p22662057.html Sent from the Wicket - User 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 Portlets in WebLogic Portal?
duh.. :-) I was just discussing a Liferay issue with a colleague and by mistake typed that instead of Wicket :-) Thijs On 23-3-2009 16:09, jakewicket wrote: Thanks for the quick reply. I'm using WebLogic Portal, not Liferay. I'll have to see if WebLogic Portal fully supports the portlet 2.0 spec, and try upgrading to Wicket 1.4 (I was trying this with Wicket 1.3.5). - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Portlets in WebLogic Portal?
No problem, thanks for the reply anyway! Thijs wrote: duh.. :-) I was just discussing a Liferay issue with a colleague and by mistake typed that instead of Wicket :-) Thijs On 23-3-2009 16:09, jakewicket wrote: Thanks for the quick reply. I'm using WebLogic Portal, not Liferay. I'll have to see if WebLogic Portal fully supports the portlet 2.0 spec, and try upgrading to Wicket 1.4 (I was trying this with Wicket 1.3.5). - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/Wicket-Portlets-in-WebLogic-Portal--tp22605855p22662624.html Sent from the Wicket - User 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 Portlets in WebLogic Portal?
Just FYI, it looks like the next release of WebLogic Portal will fully support the JSR-268 spec (http://forums.oracle.com/forums/thread.jspa?messageID=3310572#3310572), so it looks like no Wicket 1.4.x with WebLogic Portal for now. If anyone has an implementation of those Apache Portals Bridges interfaces for WebLogic Portal that are needed for Wicket 1.3.5 please let me know - thanks! -- View this message in context: http://www.nabble.com/Wicket-Portlets-in-WebLogic-Portal--tp22605855p22663707.html Sent from the Wicket - User 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 Portlets in WebLogic Portal?
Just another follow-up to this earlier post. If anyone has had any success getting Wicket portlets to work in WebLogic Portal (or knows if that is even possible), please let me know. Thanks! -- View this message in context: http://www.nabble.com/Wicket-Portlets-in-WebLogic-Portal--tp22605855p22621574.html Sent from the Wicket - User 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 Portlets in WebLogic Portal?
Hello, I'm trying to use Apache Wicket components as portlets within WebLogic Portal, and am wondering if this configuration is supported. I found the Portal HowTo page for Wicket which discusses this a little bit (http://cwiki.apache.org/WICKET/portal-howto.html), but this seems to be centered more towards Jetspeed 2 and Liferay portals. One thing that this document mentions is that, in order to run Wicket components as portlets, you need implementations for the 'ServletContextProvider' and 'PortletResourceURLFactory' interfaces from the Apache Portals Bridges JAR file. I don't see any implementations of these interfaces for WebLogic Portal, however. I found an implementation of these interfaces and tried using them (along with following steps in the Portal HowTo page) to create a sample Wicket Portlet in WebLogic Portal 10.3 and got an IllegalArgumentException stating that the relative path (./?wicket.) must start with a '/'. I've searched high and low and can't seem to find an answer indicating whether or not this is even possible in WebLogic Portal, so if anyone has any insight or could point me in the right direction, I'd appreciate it! -- View this message in context: http://www.nabble.com/Wicket-Portlets-in-WebLogic-Portal--tp22605855p22605855.html Sent from the Wicket - User 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
Portlets - Loosing state in wicket portlets
Hi,
I am using two Wicket-Portlets in a Liferay 5.2.1 Portal. Both Portlets have
a link which switches to another page within the portlet (via
setResponsepage(new
Page()) ).
When I click the link in Portlet_1 the page within the portlet one changes
as desired. After that I click the link in Portlet_2 and the page in
Portlet_2 changes as desired, but i Portlet_1 the page changes to the
Homepage.
I think that the problem might be in the getWicketURL(PortletRequest
request, String pageType, String defaultPage) - method form
WicketPortlet.java:
protected String getWicketURL(PortletRequest request, String pageType,
String defaultPage)
{
String wicketURL = null;
// get the name of the wicket url paramater, as looked up from a
request attribute called
// WicketPortlet#WICKET_URL_PORTLET_PARAMETER_ATTR
String wicketUrlParameterName =
(String)request.getAttribute(WicketPortlet.WICKET_URL_PORTLET_PARAMETER_ATTR);
if (request instanceof ActionRequest)
{
// try to lookup the passed in wicket url parameter
wicketURL = request.getParameter(wicketUrlParameterName);
}
else if (request instanceof ResourceRequest)
{
wicketURL = ((ResourceRequest)request).getResourceID();
}
else
{
// try to lookup the passed in wicket url parameter, suffixed
with the portlet mode
String parameterName = wicketUrlParameterName +
request.getPortletMode().toString();
wicketURL = request.getParameter(parameterName);
}
// if the wicketURL could not be retrieved, return the url for the
default page
if (wicketURL == null)
{
wicketURL = getWicketConfigParameter(request,
CONFIG_PARAM_PREFIX + pageType,
defaultPage);
}
return wicketURL;
}
- In the RenderRequest for Portlet_2 the wicketUrlParameterName is for the
Linklistener that was clicked. This works fine.
- In the RenderRequest for Portlet_1 the wicketUrlParameterName is null. So
by default the defaultPage of Portlet_1 is loaded, which is the Homepage.
Is this the correct behaviour?
I think the wicketURL for the RenderRequest for Portlet_1 should not be the
defaultPage but instead the last rendered Page from Portlet_1. Is there a
way to get the URL of the last page from Wicket?
Thanks for any help!
--Benjamin
Re: Wicket Portlets on WAS 7.5
On Thu, Feb 26, 2009 at 08:11:46AM -0800, suneeelu wrote: Hi, We are trying to run the echo wicket example application as a wicket portlet on WAS 7.5. We are able to load the echo application as a portlet but when we enter any text and submit the form, the form doesn't gets submitted and the page always gets loaded with the default echo text. We are using the same echo example application given in the wicket examples and we are using the wicket-1.4.2-SNAPSHOT versions for the portlet JSR 286 support. Has the 286 support tested on WAS? Are there known issues? The Wicket documentation mentions that we need to use WicketFilter instead of WicketServlet, but when we run the wicket web application in WAS, the application doesn't run with the WicketFilter. we need to change it to WicketServlet to make it run. do Wicket Portlets also need the WicketServlet configuration? I don't know about WAS 7.5 or portlet but on WAS 6.1 for wicket to run with WicketFilter you have to apply this solution else you get 404 HTTP errors: http://www-01.ibm.com/support/docview.wss?uid=swg24014758 Philippe - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket Portlets on WAS 7.5
Hi, We are trying to run the echo wicket example application as a wicket portlet on WAS 7.5. We are able to load the echo application as a portlet but when we enter any text and submit the form, the form doesn't gets submitted and the page always gets loaded with the default echo text. We are using the same echo example application given in the wicket examples and we are using the wicket-1.4.2-SNAPSHOT versions for the portlet JSR 286 support. Has the 286 support tested on WAS? Are there known issues? The Wicket documentation mentions that we need to use WicketFilter instead of WicketServlet, but when we run the wicket web application in WAS, the application doesn't run with the WicketFilter. we need to change it to WicketServlet to make it run. do Wicket Portlets also need the WicketServlet configuration? Where can we find more documentation on using Wicket for its Portlet 2.0 support? Is there anything wrong in the following configuration? the web.xml configuration filter filter-nameEchoWicketFilter/filter-name filter-classorg.apache.wicket.protocol.http.WicketFilter/filter-class init-param param-nameportletOnlyFilter/param-name param-valuetrue/param-value /init-param init-param param-namedetectPortletContext/param-name param-valuetrue/param-value /init-param init-param param-namefilterMappingUrlPattern/param-name param-value/echo/*/param-value /init-param init-param param-nameapplicationClassName/param-name param-valueorg.apache.wicket.examples.echo.EchoApplication /param-value /init-param /filter filter-mapping filter-nameEchoWicketFilter/filter-name url-pattern/echo/*/url-pattern dispatcherREQUEST/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping and the portlet.xml configuration is as below. portlet descriptionTrivial input form./description portlet-nameEchoApplication/portlet-name display-nameecho/display-name portlet-classorg.apache.wicket.protocol.http.portlet.WicketPortlet/portlet-class init-param namewicketFilterPath/name value/echo/value /init-param supports mime-type*/*/mime-type portlet-modeVIEW/portlet-mode /supports portlet-info titleWicket Echo Example/title keywordsWicket/keywords /portlet-info /portlet Thanks, Sunil. -- View this message in context: http://www.nabble.com/Wicket-Portlets-on-WAS-7.5-tp7452p7452.html Sent from the Wicket - User 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
About Wicket portlets, DatePicker, onLoad and onDomReady
Hi all, While I was experimenting with date pickers in portlets, I've noticed something. When a portlet makes a header contribution, it cannot directly contribute to document's head, instead it generates something like: script type=text/javascript src=/subscriber-web/buyOffer/ps:P-11c703e086b-1/resources/org.apache.wicket.extensions.yui.YuiLib/yuiloader-beta.js/script script type=text/javascript src=/subscriber-web/buyOffer/ps:P-11c703e086b-1/resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js/script script type=text/javascript !--/*--![CDATA[/*!--*/ in the page body. Here P-11c703e086b is the portlet's id, and each portlet fragment on the page has a different id, and hence they load different javascript files (from the browser's point of view). So now, when I have two instances of the same portlet which contains date pickers, they both include their own wicket-event and yuiloader javascript files. The result of this is that only the date pickers in the second (last loaded) portlet work, and the date pickers in the first portlet do not work. I think that the global javascript objects from the last loaded file override the ones from the first (such as Wicket and YAHOO objects). However, I've noticed that (while developing a different javascript behaviour for myself), if I execute the required javascript code during the onLoad event (instead of the onDomReady event), all of the date pickers work as expected. I have confirmed this by modifying the DatePicker class and using it within my portlets. Does anybody have an explanation for this? I know that using onLoad is bad, but it seems to solve my problem.. (BTW I'm using wicket 1.3.4 and Jetspeed 2.1.3) Best regards, SerkanC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Portlets in Liferay 5
Hi Thijs, thanks for your help, but you don't have to hurry. We faked the whole thing by running our Wicket-App inside an iFrame in Liferay. It is just for a showcase. So we don't need it right now. Thanks anyway, Benjamin On Thu, May 15, 2008 at 9:14 PM, Thijs Vonk [EMAIL PROTECTED] wrote: 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 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 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]
Re: Wicket Portlets in Liferay 5
You have a rough guess estimate as to a wicket release that will address JSR-268 compliance? Many thanks Thijs 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] -- View this message in context: http://www.nabble.com/Wicket-Portlets-in-Liferay-5-tp16995052p17077583.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Portlets in Liferay 5
No, as described it depends on several factors 1. my/other people's time to commit to this 2. official release of the portlet 2 specifications Thijs Bobby Quninne schreef: You have a rough guess estimate as to a wicket release that will address JSR-268 compliance? Many thanks Thijs 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
Are JSR-168 portlets also affected by this? If so, is there a version of wicket and liferay that are compatible? Many thanks Thijs :-) Thijs wrote: No, as described it depends on several factors 1. my/other people's time to commit to this 2. official release of the portlet 2 specifications Thijs Bobby Quninne schreef: You have a rough guess estimate as to a wicket release that will address JSR-268 compliance? Many thanks Thijs 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] -- View this message in context: http://www.nabble.com/Wicket-Portlets-in-Liferay-5-tp16995052p17078122.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Portlets in Liferay 5
Bobby Quninne schreef: Are JSR-168 portlets also affected by this? Not sure what you are asking. The current JSR-168 implementation in wicket is pretty much final, and for wicket 1.3.x will probably not change. However newer versions of wicket probably will not be backwards compatible, with JSR 168, but I don't know for sure... If so, is there a version of wicket and liferay that are compatible? As described below. An out of the box wicket version will NOT work on any version of Liferay. So there is no Wicket version that is compatible. If you are willing to work with a patched version of wicket, then you can work with wicket 1.3.3 and LF5(as we are) Thijs Many thanks Thijs :-) Thijs wrote: No, as described it depends on several factors 1. my/other people's time to commit to this 2. official release of the portlet 2 specifications Thijs Bobby Quninne schreef: You have a rough guess estimate as to a wicket release that will address JSR-268 compliance? Many thanks Thijs 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Portlets in Liferay 5
Thank you very much for the prompt responses Thijs. Will have to consider another framework for portlet development, at least until wicket-crew wrap up integration. Keep up the brilliant work! Thijs wrote: Bobby Quninne schreef: Are JSR-168 portlets also affected by this? Not sure what you are asking. The current JSR-168 implementation in wicket is pretty much final, and for wicket 1.3.x will probably not change. However newer versions of wicket probably will not be backwards compatible, with JSR 168, but I don't know for sure... If so, is there a version of wicket and liferay that are compatible? As described below. An out of the box wicket version will NOT work on any version of Liferay. So there is no Wicket version that is compatible. If you are willing to work with a patched version of wicket, then you can work with wicket 1.3.3 and LF5(as we are) Thijs Many thanks Thijs :-) Thijs wrote: No, as described it depends on several factors 1. my/other people's time to commit to this 2. official release of the portlet 2 specifications Thijs Bobby Quninne schreef: You have a rough guess estimate as to a wicket release that will address JSR-268 compliance? Many thanks Thijs 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Wicket-Portlets-in-Liferay-5-tp16995052p17078837.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Portlets in Liferay 5
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] -- View this message in context: http://www.nabble.com/Wicket-Portlets-in-Liferay-5-tp16995052p17061496.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wicket Portlets in Liferay 5
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? -- View this message in context: http://www.nabble.com/Wicket-Portlets-in-Liferay-5-tp16995052p16995052.html Sent from the Wicket - User mailing list archive at Nabble.com. - 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]
Wicket Portlets
I have a simple portlet created using wicket. It contains a PageableListView and PagingNavigator components. The portlet initially renders just fine. When I click on one of the paging links, I get ClassCastException. Part of the stacktrace looks like this... java.lang.ClassCastException: com.liferay.portlet.ActionResponseImpl at org.apache.wicket.protocol.http.portlet.WicketFilterPortletContext.setupFilter(WicketFilterPortletContext.java:75) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:163) Stepping through the code in WicketFilterPortletContext, it looks like (RenderResponse)filterRequestContext.getRequest().getAttribute(javax.portlet.response) returns com.liferay.portlet.ActionResponseImpl which does not implement RenderResponse I'm using Liferay 4.2.2 and Wicket 1.3.1. Any ideas? -- View this message in context: http://www.nabble.com/Wicket-Portlets-tp16048160p16048160.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wicket Portlets in Liferay
I'm trying to get wicket portlets to work in Liferay. As fas as I can tell there are at least 2 issues at the moment: 1.) A nullpointer exception in WebResponse due to an issue in de Liferay code that returns null in the encodeRedirectUrl (see http://www.liferay.com/web/guest/community/forums/message_boards/message/249501 ) To answer a question on the liferay forum I need to know why the encodeRedirectUrl is called. I think this is because of the REDIRECT_TO_RENDER setting done by the WicketFilterPortletContext. But can somebody confirm that?! 2.) https://issues.apache.org/jira/browse/WICKET-1132 I have no clue what causes this issue or where to look. Can somebody give me a push in the right direction? -- View this message in context: http://www.nabble.com/Wicket-Portlets-in-Liferay-tf4790149.html#a13703212 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Portlets in Liferay
Thijs wrote: I'm trying to get wicket portlets to work in Liferay. As fas as I can tell there are at least 2 issues at the moment: 1.) A nullpointer exception in WebResponse due to an issue in de Liferay code that returns null in the encodeRedirectUrl (see http://www.liferay.com/web/guest/community/forums/message_boards/message/249501 ) To answer a question on the liferay forum I need to know why the encodeRedirectUrl is called. I think this is because of the REDIRECT_TO_RENDER setting done by the WicketFilterPortletContext. But can somebody confirm that?! Hi Thijs, I've looked a bit deeper into this issue and it turned out that this is (or was) a JSR-168 conformance problem indeed. On Jetspeed-2 this didn't really cause any problems as we are more relaxed on this specific issue (in the end, redirects during rendering are not and will not ever be possible so allowing encoding doesn't hurt either). But clearly this needed to be resolved independently of Jetspeed, so I've created a new issue, https://issues.apache.org/jira/browse/WICKET-1155, as well as already resolved it :) Please do check if this now works for you too. 2.) https://issues.apache.org/jira/browse/WICKET-1132 I have no clue what causes this issue or where to look. Can somebody give me a push in the right direction? For this one, I really don't have a clue. You'll probably need a Liferay expert here as this goes into the internal url handling of the Liferay portlet container and is beyond Wicket itself. Regards, Ate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Portlets in Liferay
Ate, your the man :) I'll try to dive into the parameter problem this week. Thnx Thijs Ate Douma wrote: Thijs wrote: I'm trying to get wicket portlets to work in Liferay. As fas as I can tell there are at least 2 issues at the moment: 1.) A nullpointer exception in WebResponse due to an issue in de Liferay code that returns null in the encodeRedirectUrl (see http://www.liferay.com/web/guest/community/forums/message_boards/message/249501 ) To answer a question on the liferay forum I need to know why the encodeRedirectUrl is called. I think this is because of the REDIRECT_TO_RENDER setting done by the WicketFilterPortletContext. But can somebody confirm that?! Hi Thijs, I've looked a bit deeper into this issue and it turned out that this is (or was) a JSR-168 conformance problem indeed. On Jetspeed-2 this didn't really cause any problems as we are more relaxed on this specific issue (in the end, redirects during rendering are not and will not ever be possible so allowing encoding doesn't hurt either). But clearly this needed to be resolved independently of Jetspeed, so I've created a new issue, https://issues.apache.org/jira/browse/WICKET-1155, as well as already resolved it :) Please do check if this now works for you too. 2.) https://issues.apache.org/jira/browse/WICKET-1132 I have no clue what causes this issue or where to look. Can somebody give me a push in the right direction? For this one, I really don't have a clue. You'll probably need a Liferay expert here as this goes into the internal url handling of the Liferay portlet container and is beyond Wicket itself. Regards, Ate - 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: New Wicket Portlets Demo available
I'm even more happy to announce that Wicket Portlet Support has now been merged into the trunk and already will be part of the upcoming 1.3.0-beta4 release! In the next few days or hopefully latest end of next week, I'll add some documentation to the Wicket Wiki describing the portlet features, limitations, how to write portlet compliant Wicket applications and how to run them in a portal. For those already familiar with portlets and portals, check out the WICKET-647 and WICKET-658 issues which have some head start info. Regards, Ate Douma Ate Douma wrote: I'm really happy to announce that a new and quite feature complete Wicket Portlets Demo is now available for download at: http://people.apache.org/~ate/wicket/jetspeed-2.1.3-dev-wicket-demo-installer.jar I've worked hard the last few weeks to improve the Wicket portlet support branch and it can now run all Wicket Examples natively as portlet! See also IRA issue WICKET-658 at http://issues.apache.org/jira/browse/WICKET-658#action_12528082 where I have provided more information how to install and use this demo. Although there probably are still some minor issues here and there, the demo will show that portlet development using Wicket is now very much feasible. I'd like to invite anyone interested to try out the demo and see it in action for yourself, and of course please report any encountered issue/problems to the dev list. I've developed the portlet support based on the 1.3.0-beta3 release (with few minor bugfixes ported back from the trunk), so although the trunk development has progressed at it usual aggressive speed, updating the portlet-support to the latest Wicket trunk shouldn't be too much work (that is: right now!). As we would like to start using Wicket for a rewrite of the Jetspeed-2 administration portlets *now*, it would be great if the portlet support can be incorporated into the trunk as soon as possible. Delaying this until after the 1.3.0 release would mean being out-of-sync with the main wicket trunk development all the time and a lot of work each time we want/need to bring it back in sync. Initially, back in May this year, my idea was waiting with merging the portlet support in the trunk to after the 1.3.0 release. But as 1.3.0 still isn't released yet and still in beta phase, it would be much better to merge now otherwise the portlet-support will be constantly out-of-sync with the main wicket trunk development, causing a lot of effort each time we want (or need) to bring it back in sync. For Jetspeed-2, we would very much like to start using Wicket for a rewrite of the Jetspeed-2 administration portlet *now*. Having towait until after the 1.3.0 release, or be dependent on unofficial builds from the portlet-support branch would be less ideal to say the least. Other parties, like my own company, already have started using the Wicket portlet-support branch, so having to delay the merge to trunk really wouldn't be fun. AFAICS though, the impact of merging the portlet-support to trunk won't be big. I had to make a few (internal) changes in the wicket core, but I don't think those will have functional side-effects. To make it easier for the other committers to decide if we can merge the portlet-support to trunk now, I will create a new JIRA issue for it. For the changes needed to the current Wicket trunk I'll create separate patches with explanations why and attach those to that issue. (note: most of these changes I already described in detail under subtasks of the WICKET-647 issue). We can then discuss these changes individually and if need be see if alternative solutions are possible. After those changes are reviewed and accepted, the portlet support then can be merged to the trunk. WDYT? Regards, Ate - 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: New Wicket Portlets Demo available
This great news! Thanks for all your hard work on this, Ate. -scott -Original Message- From: Ate Douma [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 25, 2007 9:31 AM To: users@wicket.apache.org Cc: Jetspeed Users List Subject: Re: New Wicket Portlets Demo available I'm even more happy to announce that Wicket Portlet Support has now been merged into the trunk and already will be part of the upcoming 1.3.0-beta4 release! In the next few days or hopefully latest end of next week, I'll add some documentation to the Wicket Wiki describing the portlet features, limitations, how to write portlet compliant Wicket applications and how to run them in a portal. For those already familiar with portlets and portals, check out the WICKET-647 and WICKET-658 issues which have some head start info. Regards, Ate Douma Ate Douma wrote: I'm really happy to announce that a new and quite feature complete Wicket Portlets Demo is now available for download at: http://people.apache.org/~ate/wicket/jetspeed-2.1.3-dev-wicket-demo-inst aller.jar I've worked hard the last few weeks to improve the Wicket portlet support branch and it can now run all Wicket Examples natively as portlet! See also IRA issue WICKET-658 at http://issues.apache.org/jira/browse/WICKET-658#action_12528082 where I have provided more information how to install and use this demo. Although there probably are still some minor issues here and there, the demo will show that portlet development using Wicket is now very much feasible. I'd like to invite anyone interested to try out the demo and see it in action for yourself, and of course please report any encountered issue/problems to the dev list. I've developed the portlet support based on the 1.3.0-beta3 release (with few minor bugfixes ported back from the trunk), so although the trunk development has progressed at it usual aggressive speed, updating the portlet-support to the latest Wicket trunk shouldn't be too much work (that is: right now!). As we would like to start using Wicket for a rewrite of the Jetspeed-2 administration portlets *now*, it would be great if the portlet support can be incorporated into the trunk as soon as possible. Delaying this until after the 1.3.0 release would mean being out-of-sync with the main wicket trunk development all the time and a lot of work each time we want/need to bring it back in sync. Initially, back in May this year, my idea was waiting with merging the portlet support in the trunk to after the 1.3.0 release. But as 1.3.0 still isn't released yet and still in beta phase, it would be much better to merge now otherwise the portlet-support will be constantly out-of-sync with the main wicket trunk development, causing a lot of effort each time we want (or need) to bring it back in sync. For Jetspeed-2, we would very much like to start using Wicket for a rewrite of the Jetspeed-2 administration portlet *now*. Having towait until after the 1.3.0 release, or be dependent on unofficial builds from the portlet-support branch would be less ideal to say the least. Other parties, like my own company, already have started using the Wicket portlet-support branch, so having to delay the merge to trunk really wouldn't be fun. AFAICS though, the impact of merging the portlet-support to trunk won't be big. I had to make a few (internal) changes in the wicket core, but I don't think those will have functional side-effects. To make it easier for the other committers to decide if we can merge the portlet-support to trunk now, I will create a new JIRA issue for it. For the changes needed to the current Wicket trunk I'll create separate patches with explanations why and attach those to that issue. (note: most of these changes I already described in detail under subtasks of the WICKET-647 issue). We can then discuss these changes individually and if need be see if alternative solutions are possible. After those changes are reviewed and accepted, the portlet support then can be merged to the trunk. WDYT? Regards, Ate - 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: New Wicket Portlets Demo available
Thats good news, thanks very much. Cheers Dipu On 9/25/07, Ate Douma [EMAIL PROTECTED] wrote: I'm even more happy to announce that Wicket Portlet Support has now been merged into the trunk and already will be part of the upcoming 1.3.0-beta4release! In the next few days or hopefully latest end of next week, I'll add some documentation to the Wicket Wiki describing the portlet features, limitations, how to write portlet compliant Wicket applications and how to run them in a portal. For those already familiar with portlets and portals, check out the WICKET-647 and WICKET-658 issues which have some head start info. Regards, Ate Douma Ate Douma wrote: I'm really happy to announce that a new and quite feature complete Wicket Portlets Demo is now available for download at: http://people.apache.org/~ate/wicket/jetspeed-2.1.3-dev-wicket-demo-installer.jar I've worked hard the last few weeks to improve the Wicket portlet support branch and it can now run all Wicket Examples natively as portlet! See also IRA issue WICKET-658 at http://issues.apache.org/jira/browse/WICKET-658#action_12528082 where I have provided more information how to install and use this demo. Although there probably are still some minor issues here and there, the demo will show that portlet development using Wicket is now very much feasible. I'd like to invite anyone interested to try out the demo and see it in action for yourself, and of course please report any encountered issue/problems to the dev list. I've developed the portlet support based on the 1.3.0-beta3 release (with few minor bugfixes ported back from the trunk), so although the trunk development has progressed at it usual aggressive speed, updating the portlet-support to the latest Wicket trunk shouldn't be too much work (that is: right now!). As we would like to start using Wicket for a rewrite of the Jetspeed-2 administration portlets *now*, it would be great if the portlet support can be incorporated into the trunk as soon as possible. Delaying this until after the 1.3.0 release would mean being out-of-sync with the main wicket trunk development all the time and a lot of work each time we want/need to bring it back in sync. Initially, back in May this year, my idea was waiting with merging the portlet support in the trunk to after the 1.3.0 release. But as 1.3.0 still isn't released yet and still in beta phase, it would be much better to merge now otherwise the portlet-support will be constantly out-of-sync with the main wicket trunk development, causing a lot of effort each time we want (or need) to bring it back in sync. For Jetspeed-2, we would very much like to start using Wicket for a rewrite of the Jetspeed-2 administration portlet *now*. Having towait until after the 1.3.0 release, or be dependent on unofficial builds from the portlet-support branch would be less ideal to say the least. Other parties, like my own company, already have started using the Wicket portlet-support branch, so having to delay the merge to trunk really wouldn't be fun. AFAICS though, the impact of merging the portlet-support to trunk won't be big. I had to make a few (internal) changes in the wicket core, but I don't think those will have functional side-effects. To make it easier for the other committers to decide if we can merge the portlet-support to trunk now, I will create a new JIRA issue for it. For the changes needed to the current Wicket trunk I'll create separate patches with explanations why and attach those to that issue. (note: most of these changes I already described in detail under subtasks of the WICKET-647 issue). We can then discuss these changes individually and if need be see if alternative solutions are possible. After those changes are reviewed and accepted, the portlet support then can be merged to the trunk. WDYT? Regards, Ate - 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: New Wicket Portlets Demo available
Hi Ate, I'm interested in the portlet support which you have implemented in wicket. Any idea when it might be merged into the trunk? Regards Dipu On 9/17/07, Ate Douma [EMAIL PROTECTED] wrote: I'm really happy to announce that a new and quite feature complete Wicket Portlets Demo is now available for download at: http://people.apache.org/~ate/wicket/jetspeed-2.1.3-dev-wicket-demo-installer.jar I've worked hard the last few weeks to improve the Wicket portlet support branch and it can now run all Wicket Examples natively as portlet! See also IRA issue WICKET-658 at http://issues.apache.org/jira/browse/WICKET-658#action_12528082 where I have provided more information how to install and use this demo. Although there probably are still some minor issues here and there, the demo will show that portlet development using Wicket is now very much feasible. I'd like to invite anyone interested to try out the demo and see it in action for yourself, and of course please report any encountered issue/problems to the dev list. I've developed the portlet support based on the 1.3.0-beta3 release (with few minor bugfixes ported back from the trunk), so although the trunk development has progressed at it usual aggressive speed, updating the portlet-support to the latest Wicket trunk shouldn't be too much work (that is: right now!). As we would like to start using Wicket for a rewrite of the Jetspeed-2 administration portlets *now*, it would be great if the portlet support can be incorporated into the trunk as soon as possible. Delaying this until after the 1.3.0 release would mean being out-of-sync with the main wicket trunk development all the time and a lot of work each time we want/need to bring it back in sync. Initially, back in May this year, my idea was waiting with merging the portlet support in the trunk to after the 1.3.0 release. But as 1.3.0 still isn't released yet and still in beta phase, it would be much better to merge now otherwise the portlet-support will be constantly out-of-sync with the main wicket trunk development, causing a lot of effort each time we want (or need) to bring it back in sync. For Jetspeed-2, we would very much like to start using Wicket for a rewrite of the Jetspeed-2 administration portlet *now*. Having towait until after the 1.3.0 release, or be dependent on unofficial builds from the portlet-support branch would be less ideal to say the least. Other parties, like my own company, already have started using the Wicket portlet-support branch, so having to delay the merge to trunk really wouldn't be fun. AFAICS though, the impact of merging the portlet-support to trunk won't be big. I had to make a few (internal) changes in the wicket core, but I don't think those will have functional side-effects. To make it easier for the other committers to decide if we can merge the portlet-support to trunk now, I will create a new JIRA issue for it. For the changes needed to the current Wicket trunk I'll create separate patches with explanations why and attach those to that issue. (note: most of these changes I already described in detail under subtasks of the WICKET-647 issue). We can then discuss these changes individually and if need be see if alternative solutions are possible. After those changes are reviewed and accepted, the portlet support then can be merged to the trunk. WDYT? Regards, Ate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Wicket Portlets Demo available
Probably fairly soon - we've been looking at the changes and discussing it on the dev list, to try get an idea if it'll cause a significant delay with regards to the aim of getting a 1.3 release out ASAP. Currently, however, I think the view is that it'll be likely to be in and we'll do a beta4, then see how it looks. I think I saw some comment about some rebuilding work of Ate's house - I don't know any more than that, but if he's quiet for a bit, that might explain it! In the meantime, you could get the baseline code from SVN (http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.0-beta3), apply the patch from the jira issue https://issues.apache.org/jira/secure/attachment/12366048/wicket-1.3.0-beta3-portlet-support.patch and build your own copy if you want to have a look prior to that. (Build with tests disabled mvn -Dmaven.test.skip=true install as the patch missed changing a particular test expectation) /Gwyn On Thursday, September 20, 2007, 10:20:23 AM, Dipu [EMAIL PROTECTED] wrote: Hi Ate, I'm interested in the portlet support which you have implemented in wicket. Any idea when it might be merged into the trunk? Regards Dipu On 9/17/07, Ate Douma [EMAIL PROTECTED] wrote: I'm really happy to announce that a new and quite feature complete Wicket Portlets Demo is now available for download at: http://people.apache.org/~ate/wicket/jetspeed-2.1.3-dev-wicket-demo-installer.jar I've worked hard the last few weeks to improve the Wicket portlet support branch and it can now run all Wicket Examples natively as portlet! See also IRA issue WICKET-658 at http://issues.apache.org/jira/browse/WICKET-658#action_12528082 where I have provided more information how to install and use this demo. Although there probably are still some minor issues here and there, the demo will show that portlet development using Wicket is now very much feasible. I'd like to invite anyone interested to try out the demo and see it in action for yourself, and of course please report any encountered issue/problems to the dev list. I've developed the portlet support based on the 1.3.0-beta3 release (with few minor bugfixes ported back from the trunk), so although the trunk development has progressed at it usual aggressive speed, updating the portlet-support to the latest Wicket trunk shouldn't be too much work (that is: right now!). As we would like to start using Wicket for a rewrite of the Jetspeed-2 administration portlets *now*, it would be great if the portlet support can be incorporated into the trunk as soon as possible. Delaying this until after the 1.3.0 release would mean being out-of-sync with the main wicket trunk development all the time and a lot of work each time we want/need to bring it back in sync. Initially, back in May this year, my idea was waiting with merging the portlet support in the trunk to after the 1.3.0 release. But as 1.3.0 still isn't released yet and still in beta phase, it would be much better to merge now otherwise the portlet-support will be constantly out-of-sync with the main wicket trunk development, causing a lot of effort each time we want (or need) to bring it back in sync. For Jetspeed-2, we would very much like to start using Wicket for a rewrite of the Jetspeed-2 administration portlet *now*. Having towait until after the 1.3.0 release, or be dependent on unofficial builds from the portlet-support branch would be less ideal to say the least. Other parties, like my own company, already have started using the Wicket portlet-support branch, so having to delay the merge to trunk really wouldn't be fun. AFAICS though, the impact of merging the portlet-support to trunk won't be big. I had to make a few (internal) changes in the wicket core, but I don't think those will have functional side-effects. To make it easier for the other committers to decide if we can merge the portlet-support to trunk now, I will create a new JIRA issue for it. For the changes needed to the current Wicket trunk I'll create separate patches with explanations why and attach those to that issue. (note: most of these changes I already described in detail under subtasks of the WICKET-647 issue). We can then discuss these changes individually and if need be see if alternative solutions are possible. After those changes are reviewed and accepted, the portlet support then can be merged to the trunk. WDYT? Regards, Ate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Wicket Portlets Demo available
Dipu Seminlal wrote: Hi Ate, I'm interested in the portlet support which you have implemented in wicket. Cool! Any idea when it might be merged into the trunk? It is under discussion right now on the dev list. I've proposed to merge this into trunk now (before -beta4 release), but this hasn't been decided or voted upon yet. I do hope we can wrap this up quickly though. The discussion is somewhat split up over two different threads which you can view in context using nabble: [1] http://www.nabble.com/Please-review-WICKET-983%3A-Merge-the-portlet-support-branch-into-the-trunk-tf4470851.html [2] http://www.nabble.com/Re%3A--jira--Resolved%3A-%28WICKET-647%29-New-Wicket-Portlet-support-tf4467600.html Feel free to join those and let us know your opinion too :) Regards, Ate Regards Dipu On 9/17/07, Ate Douma [EMAIL PROTECTED] wrote: I'm really happy to announce that a new and quite feature complete Wicket Portlets Demo is now available for download at: http://people.apache.org/~ate/wicket/jetspeed-2.1.3-dev-wicket-demo-installer.jar I've worked hard the last few weeks to improve the Wicket portlet support branch and it can now run all Wicket Examples natively as portlet! See also IRA issue WICKET-658 at http://issues.apache.org/jira/browse/WICKET-658#action_12528082 where I have provided more information how to install and use this demo. Although there probably are still some minor issues here and there, the demo will show that portlet development using Wicket is now very much feasible. I'd like to invite anyone interested to try out the demo and see it in action for yourself, and of course please report any encountered issue/problems to the dev list. I've developed the portlet support based on the 1.3.0-beta3 release (with few minor bugfixes ported back from the trunk), so although the trunk development has progressed at it usual aggressive speed, updating the portlet-support to the latest Wicket trunk shouldn't be too much work (that is: right now!). As we would like to start using Wicket for a rewrite of the Jetspeed-2 administration portlets *now*, it would be great if the portlet support can be incorporated into the trunk as soon as possible. Delaying this until after the 1.3.0 release would mean being out-of-sync with the main wicket trunk development all the time and a lot of work each time we want/need to bring it back in sync. Initially, back in May this year, my idea was waiting with merging the portlet support in the trunk to after the 1.3.0 release. But as 1.3.0 still isn't released yet and still in beta phase, it would be much better to merge now otherwise the portlet-support will be constantly out-of-sync with the main wicket trunk development, causing a lot of effort each time we want (or need) to bring it back in sync. For Jetspeed-2, we would very much like to start using Wicket for a rewrite of the Jetspeed-2 administration portlet *now*. Having towait until after the 1.3.0 release, or be dependent on unofficial builds from the portlet-support branch would be less ideal to say the least. Other parties, like my own company, already have started using the Wicket portlet-support branch, so having to delay the merge to trunk really wouldn't be fun. AFAICS though, the impact of merging the portlet-support to trunk won't be big. I had to make a few (internal) changes in the wicket core, but I don't think those will have functional side-effects. To make it easier for the other committers to decide if we can merge the portlet-support to trunk now, I will create a new JIRA issue for it. For the changes needed to the current Wicket trunk I'll create separate patches with explanations why and attach those to that issue. (note: most of these changes I already described in detail under subtasks of the WICKET-647 issue). We can then discuss these changes individually and if need be see if alternative solutions are possible. After those changes are reviewed and accepted, the portlet support then can be merged to the trunk. WDYT? Regards, Ate - 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: New Wicket Portlets Demo available
Thanks Gwyn Regards Dipu On 9/20/07, Gwyn Evans [EMAIL PROTECTED] wrote: Probably fairly soon - we've been looking at the changes and discussing it on the dev list, to try get an idea if it'll cause a significant delay with regards to the aim of getting a 1.3 release out ASAP. Currently, however, I think the view is that it'll be likely to be in and we'll do a beta4, then see how it looks. I think I saw some comment about some rebuilding work of Ate's house - I don't know any more than that, but if he's quiet for a bit, that might explain it! In the meantime, you could get the baseline code from SVN (http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.0-beta3), apply the patch from the jira issue https://issues.apache.org/jira/secure/attachment/12366048/wicket-1.3.0-beta3-portlet-support.patch and build your own copy if you want to have a look prior to that. (Build with tests disabled mvn -Dmaven.test.skip=true install as the patch missed changing a particular test expectation) /Gwyn On Thursday, September 20, 2007, 10:20:23 AM, Dipu [EMAIL PROTECTED] wrote: Hi Ate, I'm interested in the portlet support which you have implemented in wicket. Any idea when it might be merged into the trunk? Regards Dipu On 9/17/07, Ate Douma [EMAIL PROTECTED] wrote: I'm really happy to announce that a new and quite feature complete Wicket Portlets Demo is now available for download at: http://people.apache.org/~ate/wicket/jetspeed-2.1.3-dev-wicket-demo-installer.jar I've worked hard the last few weeks to improve the Wicket portlet support branch and it can now run all Wicket Examples natively as portlet! See also IRA issue WICKET-658 at http://issues.apache.org/jira/browse/WICKET-658#action_12528082 where I have provided more information how to install and use this demo. Although there probably are still some minor issues here and there, the demo will show that portlet development using Wicket is now very much feasible. I'd like to invite anyone interested to try out the demo and see it in action for yourself, and of course please report any encountered issue/problems to the dev list. I've developed the portlet support based on the 1.3.0-beta3 release (with few minor bugfixes ported back from the trunk), so although the trunk development has progressed at it usual aggressive speed, updating the portlet-support to the latest Wicket trunk shouldn't be too much work (that is: right now!). As we would like to start using Wicket for a rewrite of the Jetspeed-2 administration portlets *now*, it would be great if the portlet support can be incorporated into the trunk as soon as possible. Delaying this until after the 1.3.0 release would mean being out-of-sync with the main wicket trunk development all the time and a lot of work each time we want/need to bring it back in sync. Initially, back in May this year, my idea was waiting with merging the portlet support in the trunk to after the 1.3.0 release. But as 1.3.0 still isn't released yet and still in beta phase, it would be much better to merge now otherwise the portlet-support will be constantly out-of-sync with the main wicket trunk development, causing a lot of effort each time we want (or need) to bring it back in sync. For Jetspeed-2, we would very much like to start using Wicket for a rewrite of the Jetspeed-2 administration portlet *now*. Having towait until after the 1.3.0 release, or be dependent on unofficial builds from the portlet-support branch would be less ideal to say the least. Other parties, like my own company, already have started using the Wicket portlet-support branch, so having to delay the merge to trunk really wouldn't be fun. AFAICS though, the impact of merging the portlet-support to trunk won't be big. I had to make a few (internal) changes in the wicket core, but I don't think those will have functional side-effects. To make it easier for the other committers to decide if we can merge the portlet-support to trunk now, I will create a new JIRA issue for it. For the changes needed to the current Wicket trunk I'll create separate patches with explanations why and attach those to that issue. (note: most of these changes I already described in detail under subtasks of the WICKET-647 issue). We can then discuss these changes individually and if need be see if alternative solutions are possible. After those changes are reviewed and accepted, the portlet support then can be merged to the trunk. WDYT? Regards, Ate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e
Re: New Wicket Portlets Demo available
WDYT? Good news Ate! I'm +1 for putting it in trunk if you take on the responsibility of maintaining it properly. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Wicket Portlets Demo available
im with eelco -igor On 9/17/07, Eelco Hillenius [EMAIL PROTECTED] wrote: WDYT? Good news Ate! I'm +1 for putting it in trunk if you take on the responsibility of maintaining it properly. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Wicket Portlets Demo available
Eelco Hillenius wrote: WDYT? Good news Ate! I'm +1 for putting it in trunk if you take on the responsibility of maintaining it properly. Sure :) I'm pretty much involved in several projects which would like to use the Wicket portlet support, and of course if we manage to rewrite our Jetspeed-2 admin portlets in Wicket (for release 2.2) there will be a direct Apache connection too! So, you can be assured of my continued involvement and interest in this, and even without concrete projects at hand. But I will need support from all the Wicket committers for trying to maintain portlet compatibility as much as possible too! There aren't that many specific rules to follow, but certain things simply aren't allowed like modifying an url after it is generated (like from client side javascript). There are easy workaround/alternatives for that like using POST with hidden parameters instead of GET requests. Once we have portlet support in the branch as an officially supported feature, everyone should take these restrictions in mind. And of course, for very servlet specific features which make no sense in a portlet this won't apply. I plan to create a JIRA issue for merging to trunk later this evening or tomorrow and then you can all see concrete examples of what I mean by this. Many thanks for the positive responses so far already, Regards, Ate Eelco - 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: New Wicket Portlets Demo available
But I will need support from all the Wicket committers for trying to maintain portlet compatibility as much as possible too! As long as you tell us when we're breaking the rules, we'll be happy to comply :) Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New Wicket Portlets Demo available
I'm really happy to announce that a new and quite feature complete Wicket Portlets Demo is now available for download at: http://people.apache.org/~ate/wicket/jetspeed-2.1.3-dev-wicket-demo-installer.jar I've worked hard the last few weeks to improve the Wicket portlet support branch and it can now run all Wicket Examples natively as portlet! See also IRA issue WICKET-658 at http://issues.apache.org/jira/browse/WICKET-658#action_12528082 where I have provided more information how to install and use this demo. Although there probably are still some minor issues here and there, the demo will show that portlet development using Wicket is now very much feasible. I'd like to invite anyone interested to try out the demo and see it in action for yourself, and of course please report any encountered issue/problems to the dev list. I've developed the portlet support based on the 1.3.0-beta3 release (with few minor bugfixes ported back from the trunk), so although the trunk development has progressed at it usual aggressive speed, updating the portlet-support to the latest Wicket trunk shouldn't be too much work (that is: right now!). As we would like to start using Wicket for a rewrite of the Jetspeed-2 administration portlets *now*, it would be great if the portlet support can be incorporated into the trunk as soon as possible. Delaying this until after the 1.3.0 release would mean being out-of-sync with the main wicket trunk development all the time and a lot of work each time we want/need to bring it back in sync. Initially, back in May this year, my idea was waiting with merging the portlet support in the trunk to after the 1.3.0 release. But as 1.3.0 still isn't released yet and still in beta phase, it would be much better to merge now otherwise the portlet-support will be constantly out-of-sync with the main wicket trunk development, causing a lot of effort each time we want (or need) to bring it back in sync. For Jetspeed-2, we would very much like to start using Wicket for a rewrite of the Jetspeed-2 administration portlet *now*. Having towait until after the 1.3.0 release, or be dependent on unofficial builds from the portlet-support branch would be less ideal to say the least. Other parties, like my own company, already have started using the Wicket portlet-support branch, so having to delay the merge to trunk really wouldn't be fun. AFAICS though, the impact of merging the portlet-support to trunk won't be big. I had to make a few (internal) changes in the wicket core, but I don't think those will have functional side-effects. To make it easier for the other committers to decide if we can merge the portlet-support to trunk now, I will create a new JIRA issue for it. For the changes needed to the current Wicket trunk I'll create separate patches with explanations why and attach those to that issue. (note: most of these changes I already described in detail under subtasks of the WICKET-647 issue). We can then discuss these changes individually and if need be see if alternative solutions are possible. After those changes are reviewed and accepted, the portlet support then can be merged to the trunk. WDYT? Regards, Ate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket portlets on LIferay
Thx for help, but this doesn't sort it out.
A tried:
code
...
protected void init() {
getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.ONE_PASS_RENDER);
super.init();
}
...
/code
and also
code
...
protected void init() {
super.init();
getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.ONE_PASS_RENDER);
}
...
/code
Any idea?
Miso
--
View this message in context:
http://www.nabble.com/Wicket-portlets-on-LIferay-tf4231110.html#a12047909
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket portlets on LIferay
Now you are outside my area of expertise :-). I hope that Ate or Janne
is reading this.
Martijn
On 8/8/07, Miso [EMAIL PROTECTED] wrote:
Thx for help, but this doesn't sort it out.
A tried:
code
...
protected void init() {
getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.ONE_PASS_RENDER);
super.init();
}
...
/code
and also
code
...
protected void init() {
super.init();
getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.ONE_PASS_RENDER);
}
...
/code
Any idea?
Miso
--
View this message in context:
http://www.nabble.com/Wicket-portlets-on-LIferay-tf4231110.html#a12047909
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Wicket joins the Apache Software Foundation as Apache Wicket
Apache Wicket 1.3.0-beta2 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta2/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket portlets on LIferay
Also, make sure you are using the code from the experimental portlet
branch, as that is the only part where the portlet support is built
into (seeing you are using wicket 1.3 based code).
Martijn
On 8/8/07, Miso [EMAIL PROTECTED] wrote:
Thx for help, but this doesn't sort it out.
A tried:
code
...
protected void init() {
getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.ONE_PASS_RENDER);
super.init();
}
...
/code
and also
code
...
protected void init() {
super.init();
getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.ONE_PASS_RENDER);
}
...
/code
Any idea?
Miso
--
View this message in context:
http://www.nabble.com/Wicket-portlets-on-LIferay-tf4231110.html#a12047909
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Wicket joins the Apache Software Foundation as Apache Wicket
Apache Wicket 1.3.0-beta2 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta2/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket portlets on LIferay
Yes, I'm using this experimental portlet branch. -- View this message in context: http://www.nabble.com/Wicket-portlets-on-LIferay-tf4231110.html#a12051724 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket portlets on LIferay
Me too :) -- View this message in context: http://www.nabble.com/Wicket-portlets-on-LIferay-tf4231110.html#a12051726 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
