You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Ate Douma <at...@douma.nu> on 2007/09/17 18:37:50 UTC
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New Wicket Portlets Demo available
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New Wicket Portlets Demo available
Posted by Ate Douma <at...@douma.nu>.
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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New Wicket Portlets Demo available
Posted by Igor Vaynberg <ig...@gmail.com>.
im with eelco
-igor
On 9/17/07, Eelco Hillenius <ee...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: New Wicket Portlets Demo available
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: New Wicket Portlets Demo available
Posted by "Weaver, Scott" <we...@ugs.com>.
This great news! Thanks for all your hard work on this, Ate.
-scott
-----Original Message-----
From: Ate Douma [mailto:ate@douma.nu]
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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: New Wicket Portlets Demo available
Posted by Dipu Seminlal <di...@googlemail.com>.
Thats good news, thanks very much.
Cheers
Dipu
On 9/25/07, Ate Douma <at...@douma.nu> 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
RE: New Wicket Portlets Demo available
Posted by "Weaver, Scott" <we...@ugs.com>.
This great news! Thanks for all your hard work on this, Ate.
-scott
-----Original Message-----
From: Ate Douma [mailto:ate@douma.nu]
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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New Wicket Portlets Demo available
Posted by Ate Douma <at...@douma.nu>.
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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Jetspeed isn't correctly using the encoding setting of the Servlets
Posted by David Sean Taylor <da...@bluesunrise.com>.
Hi,
On Sep 25, 2007, at 9:14 AM, Andrew F Hall wrote:
> Hi,
>
> I wanted to know if anyone has any feedback on some of my outstanding
> issues. Specifically:
>
> 1. getCapabilites and getAgent are returning null from within a
> portlet. Is this expected behavior is there an issue here?
I am not sure how you are implementing this from a portlet.
I am looking at 2.1.3, and unfortunately we don't expose the
Capability service to portlets
So I assume you are getting the CapabilityMap via the RequestContext,
correct?
> 2. Is version 2.0.1 considered stable? Is this something I can apply
> without extensive testing? Also, is my code patch sensible and
> necessary? Does the code patch need to be applied to 2.1 as well?
I really recommend moving to 2.1.2, or 2.1.3.
Im looking at the 2.1.3 trunk, and it still has the same code:
if (decode)
{
for (int i = 0; i < paramValues.length; i++)
{
try
{
paramValues[i] = new String(paramValues
[i].getBytes("ISO-8859-1"), encoding);
}
catch (UnsupportedEncodingException e)
{
;
}
}
}
I think your patch looks good, but could you post your patch to the
dev list and see if anyone objects
RE: Jetspeed isn't correctly using the encoding setting of the Servlets
Posted by Andrew F Hall <af...@circleup.com>.
Hi,
I wanted to know if anyone has any feedback on some of my outstanding
issues. Specifically:
1. getCapabilites and getAgent are returning null from within a
portlet. Is this expected behavior is there an issue here?
2. Is version 2.0.1 considered stable? Is this something I can apply
without extensive testing? Also, is my code patch sensible and
necessary? Does the code patch need to be applied to 2.1 as well?
Thanks again.
- Andrew Hall
-----Original Message-----
From: Andrew F Hall [mailto:afhall@circleup.com]
Sent: Sunday, September 23, 2007 11:35 PM
To: Jetspeed Users List
Subject: Jetspeed isn't correctly using the encoding setting of the
Servlets
Hi,
I need to support utf-8 encoding for form submission. We are currently
deploying Jetspeed 2.0 - and what I see is that when we set the
character encoding to utf-8 and try to retrieve a parameter, the
encoding is ignored and the data is corrupted. Since I only want to
patch this problem and not undertake an upgrade to 2.1, I looked into
the source code available. I see that there is a version 2.0.1. In
there, ServletRequestImpl looks like it has been changed to fix the
problem. I built that version and tested it. Still didn't work. In
order to get it to work, I had to make the following changes to
getParameterMap:
paramValues[i] = new
String(paramValues[i].getBytes(getCharacterEncoding()), encoding);
The original code had
paramValues[i] = new
String(paramValues[i].getBytes("ISO-8859-1"), encoding);
I have several questions:
1. Is 2.0.1 considered a stable release? I'm going with 2.0.1 instead
of trying to go to 2.1 because I don't have time for migration or proper
stability testing, so, does 2.0.1 require a migration step? Is it a
"patch" or a "release" require stability testing on our part?
2. Is there a reason that "ISO-8859-1" is hardcoded in this method? My
fix seems to work but could there be some unintended consequences of
this?
3. Has this fix been applied to 2.1 or does 2.1 also require a fix?
Thanks in advance.
- Andrew Hall
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Jetspeed isn't correctly using the encoding setting of the Servlets
Posted by Andrew F Hall <af...@circleup.com>.
Hi,
I need to support utf-8 encoding for form submission. We are currently
deploying Jetspeed 2.0 - and what I see is that when we set the
character encoding to utf-8 and try to retrieve a parameter, the
encoding is ignored and the data is corrupted. Since I only want to
patch this problem and not undertake an upgrade to 2.1, I looked into
the source code available. I see that there is a version 2.0.1. In
there, ServletRequestImpl looks like it has been changed to fix the
problem. I built that version and tested it. Still didn't work. In
order to get it to work, I had to make the following changes to
getParameterMap:
paramValues[i] = new
String(paramValues[i].getBytes(getCharacterEncoding()), encoding);
The original code had
paramValues[i] = new
String(paramValues[i].getBytes("ISO-8859-1"), encoding);
I have several questions:
1. Is 2.0.1 considered a stable release? I'm going with 2.0.1 instead
of trying to go to 2.1 because I don't have time for migration or proper
stability testing, so, does 2.0.1 require a migration step? Is it a
"patch" or a "release" require stability testing on our part?
2. Is there a reason that "ISO-8859-1" is hardcoded in this method? My
fix seems to work but could there be some unintended consequences of
this?
3. Has this fix been applied to 2.1 or does 2.1 also require a fix?
Thanks in advance.
- Andrew Hall
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: New Wicket Portlets Demo available
Posted by "Weaver, Scott" <we...@ugs.com>.
Ok, seems to work fine in the installer version of Jetspeed. I must be
missing something else in my pipeline.
-scott
-----Original Message-----
From: Ate Douma [mailto:ate@douma.nu]
Sent: Monday, September 24, 2007 11:51 AM
To: Jetspeed Users List
Subject: Re: New Wicket Portlets Demo available
Weaver, Scott wrote:
> Still having some issues. I narrowed it down to the resourceWindow
not
> being set on the PortletWindowRequestNavigationalState during the call
> to
>
org.apache.jetspeed.container.state.impl.JetspeedNavigationalStateCodec.
> decodeParameter(). Starting at line 422, it looks like my request is
> coming in as an action and hence skips the setting of the resource
> window on the navigational state, which in turn, causes all of the
logic
> in the org.apache.jetspeed.resource.ResourceValveImpl to be skipped.
>
> Any thoughts?
No, that's too limited info for me to work with.
Could you at least deploy and try out your example in the example portal
from the jetspeed-2.1.3-dev-wicket-demo-installer.jar?
If it works there, we at least know it's something to do with your setup
and not wicket and/or default jetspeed-2 configuration.
And make sure you've cleared your browser cache if javascript
(libraries) is involved.
I've got to leave for today.
Good luck,
Ate
>
> Thanks,
> -scott
>
> -----Original Message-----
> From: Weaver, Scott [mailto:weavers@ugs.com]
> Sent: Monday, September 24, 2007 10:06 AM
> To: Jetspeed Users List
> Subject: RE: New Wicket Portlets Demo available
>
> Ahhh! I was wondering about the ResourceValve. I saw it but I didn't
> see any comments on what its purpose was, so I just left it out. I
will
> throw that in and test. I am sure that is what the issue is. Thanks!
>
> -scott
>
> -----Original Message-----
> From: Ate Douma [mailto:ate@douma.nu]
> Sent: Monday, September 24, 2007 9:57 AM
> To: Jetspeed Users List
> Subject: Re: New Wicket Portlets Demo available
>
> Weaver, Scott wrote:
>> Thanks for looking at that, Ate. Yes I updated Friday actually
>> (r578142). I guess I need to dig a little deeper. I run a custom
>> pipeline, could I be missing something there?
>
> Yes, for Wicket support I added a new resourceValve:
>
> <bean id="resourceValve"
> class="org.apache.jetspeed.resource.ResourceValveImpl"
> init-method="initialize">
> <constructor-arg>
> <ref bean="org.apache.pluto.PortletContainer" />
> </constructor-arg>
> <constructor-arg>
> <ref bean="PortletWindowAccessor" />
> </constructor-arg>
> </bean>
>
> This valve needs to be plugged into your pipeline after the
actionValve
> and before the render valve (PageRenderValve in your case).
>
> See also: https://issues.apache.org/jira/browse/JS2-729
>
> Note: if you also use/need the /desktop you do need to update its
> pipelines as well (see the latest pipelines.xml).
> But also: wicket Ajax does not yet work in the /desktop. This is
> actually a problem in J2 and not with the Wicket portlet support
itself
> AFAIK.
> My plan is to fix that too before we release 2.1.3-dev.
>
>
> Ate
>
>> <bean id="no-aggregation-pipeline"
>> class="org.apache.jetspeed.pipeline.JetspeedPipeline"
>> init-method="initialize"
>> >
>> <constructor-arg>
>> <value>NoAggregationPipeline</value>
>> </constructor-arg>
>> <constructor-arg>
>> <list>
>> <ref bean="webkeyValve"/>
>> <ref bean="localeSelectorValve" />
>> <ref bean="localizationValve"/>
>> <ref bean="capabilityValve"/>
>> <ref bean="portalURLValve"/>
>> <ref bean="profilerValve"/>
>> <ref bean="customizerValve"/>
>> <ref bean="containerValve"/>
>> <ref bean="actionValve"/>
>> <ref bean="PageRendererValve" />
>> </list>
>> </constructor-arg>
>> </bean>
>>
>> The webkeyValve, customizerValve and PageRendererValve are custom
>> valves, the rest are the standard ones already provided.
>>
>> Thanks,
>> -scott
>>
>> -----Original Message-----
>> From: Ate Douma [mailto:ate@douma.nu]
>> Sent: Saturday, September 22, 2007 12:19 PM
>> To: Jetspeed Users List
>> Subject: Re: New Wicket Portlets Demo available
>>
>> Scott,
>>
>> You're example works for me.
>> I've actually copy/pasted it and it just works.
>> Do you use at least jetspeed-2.1.3-dev (trunk, or at least >=
r574908,
>> Sept 12)?
>>
>> Ate
>>
>> Weaver, Scott wrote:
>>> Ok, viewing seems to be working without a hitch. However, it
appears
>>> that Link.onClick() is not being fired.
>>>
>>> public class PartnerHandbook extends WebPage {
>>>
>>> private int clicks=0;
>>>
>>> public PartnerHandbook() {
>>> super();
>>> add(new Label("test", "Partner Handbook"));
>>> add(new Label("clicks", new PropertyModel(this,
>>> "clicks")));
>>> add(new Link("testLink"){
>>>
>>> @Override
>>> public void onClick() {
>>>
>>> clicks++;
>>> }
>>>
>>> });
>>>
>>> }
>>>
>>> public int getClicks() {
>>> return clicks;
>>> }
>>>
>>> }
>>>
>>> "clicks" is never incremented and debugging shows it is never
> invoked.
>>> This works if I access the page directly. Any ideas?
>>>
>>> -scott
>>>
>>> -----Original Message-----
>>> From: Ate Douma [mailto:ate@douma.nu]
>>> Sent: Thursday, September 20, 2007 11:07 AM
>>> To: Jetspeed Users List
>>> Subject: Re: New Wicket Portlets Demo available
>>>
>>> Weaver, Scott wrote:
>>>> Ate,
>>>>
>>>> This is great news! Thanks for all of your hard work on the Wicket
>>>> portlet support!
>>>>
>>>> I have a couple small portlet apps I need to develop and really
>> wanted
>>>> to use Wicket to do so.
>>>>
>>>> Just one quick question: Which branch of Wicket should I develop
>>>> against?
>>> At this moment:
>>>
>
http://svn.apache.org/repos/asf/wicket/branches/wicket-1.3.0-beta3-portl
>>> et-support
>>>
>>> See also
>>>
>>> http://issues.apache.org/jira/browse/WICKET-647
>>> and http://issues.apache.org/jira/browse/WICKET-983
>>>
>>> for more information how the portlet-support is implemented and
>> possible
>>> caveats.
>>>
>>> FYI: WICKET-983 concerns merging the portlet-support into the main
>>> Wicket trunk, something which is voted upon right now on the
>>> dev@wicket.apache.org list.
>>> See:
>>>
>>>
>
http://www.nabble.com/-VOTE--WICKET-983%3A-Merging-portlet-support-tf448
>>> 6633.html
>>>
>>> Regards,
>>> Ate
>>>
>>>
>>>> Regards,
>>>> -scott
>>>>
>>>> -----Original Message-----
>>>> From: Ate Douma [mailto:ate@douma.nu]
>>>> Sent: Monday, September 17, 2007 12:38 PM
>>>> To: users@wicket.apache.org
>>>> Cc: Jetspeed Users List
>>>> Subject: 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-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:
jetspeed-user-unsubscribe@portals.apache.org
>>>> For additional commands, e-mail:
>> jetspeed-user-help@portals.apache.org
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
jetspeed-user-unsubscribe@portals.apache.org
>>>> For additional commands, e-mail:
>> jetspeed-user-help@portals.apache.org
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>>> For additional commands, e-mail:
> jetspeed-user-help@portals.apache.org
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>>> For additional commands, e-mail:
> jetspeed-user-help@portals.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail:
jetspeed-user-help@portals.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail:
jetspeed-user-help@portals.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: New Wicket Portlets Demo available
Posted by Ate Douma <at...@douma.nu>.
Weaver, Scott wrote:
> Still having some issues. I narrowed it down to the resourceWindow not
> being set on the PortletWindowRequestNavigationalState during the call
> to
> org.apache.jetspeed.container.state.impl.JetspeedNavigationalStateCodec.
> decodeParameter(). Starting at line 422, it looks like my request is
> coming in as an action and hence skips the setting of the resource
> window on the navigational state, which in turn, causes all of the logic
> in the org.apache.jetspeed.resource.ResourceValveImpl to be skipped.
>
> Any thoughts?
No, that's too limited info for me to work with.
Could you at least deploy and try out your example in the example portal from the jetspeed-2.1.3-dev-wicket-demo-installer.jar?
If it works there, we at least know it's something to do with your setup and not wicket and/or default jetspeed-2 configuration.
And make sure you've cleared your browser cache if javascript (libraries) is involved.
I've got to leave for today.
Good luck,
Ate
>
> Thanks,
> -scott
>
> -----Original Message-----
> From: Weaver, Scott [mailto:weavers@ugs.com]
> Sent: Monday, September 24, 2007 10:06 AM
> To: Jetspeed Users List
> Subject: RE: New Wicket Portlets Demo available
>
> Ahhh! I was wondering about the ResourceValve. I saw it but I didn't
> see any comments on what its purpose was, so I just left it out. I will
> throw that in and test. I am sure that is what the issue is. Thanks!
>
> -scott
>
> -----Original Message-----
> From: Ate Douma [mailto:ate@douma.nu]
> Sent: Monday, September 24, 2007 9:57 AM
> To: Jetspeed Users List
> Subject: Re: New Wicket Portlets Demo available
>
> Weaver, Scott wrote:
>> Thanks for looking at that, Ate. Yes I updated Friday actually
>> (r578142). I guess I need to dig a little deeper. I run a custom
>> pipeline, could I be missing something there?
>
> Yes, for Wicket support I added a new resourceValve:
>
> <bean id="resourceValve"
> class="org.apache.jetspeed.resource.ResourceValveImpl"
> init-method="initialize">
> <constructor-arg>
> <ref bean="org.apache.pluto.PortletContainer" />
> </constructor-arg>
> <constructor-arg>
> <ref bean="PortletWindowAccessor" />
> </constructor-arg>
> </bean>
>
> This valve needs to be plugged into your pipeline after the actionValve
> and before the render valve (PageRenderValve in your case).
>
> See also: https://issues.apache.org/jira/browse/JS2-729
>
> Note: if you also use/need the /desktop you do need to update its
> pipelines as well (see the latest pipelines.xml).
> But also: wicket Ajax does not yet work in the /desktop. This is
> actually a problem in J2 and not with the Wicket portlet support itself
> AFAIK.
> My plan is to fix that too before we release 2.1.3-dev.
>
>
> Ate
>
>> <bean id="no-aggregation-pipeline"
>> class="org.apache.jetspeed.pipeline.JetspeedPipeline"
>> init-method="initialize"
>> >
>> <constructor-arg>
>> <value>NoAggregationPipeline</value>
>> </constructor-arg>
>> <constructor-arg>
>> <list>
>> <ref bean="webkeyValve"/>
>> <ref bean="localeSelectorValve" />
>> <ref bean="localizationValve"/>
>> <ref bean="capabilityValve"/>
>> <ref bean="portalURLValve"/>
>> <ref bean="profilerValve"/>
>> <ref bean="customizerValve"/>
>> <ref bean="containerValve"/>
>> <ref bean="actionValve"/>
>> <ref bean="PageRendererValve" />
>> </list>
>> </constructor-arg>
>> </bean>
>>
>> The webkeyValve, customizerValve and PageRendererValve are custom
>> valves, the rest are the standard ones already provided.
>>
>> Thanks,
>> -scott
>>
>> -----Original Message-----
>> From: Ate Douma [mailto:ate@douma.nu]
>> Sent: Saturday, September 22, 2007 12:19 PM
>> To: Jetspeed Users List
>> Subject: Re: New Wicket Portlets Demo available
>>
>> Scott,
>>
>> You're example works for me.
>> I've actually copy/pasted it and it just works.
>> Do you use at least jetspeed-2.1.3-dev (trunk, or at least >= r574908,
>> Sept 12)?
>>
>> Ate
>>
>> Weaver, Scott wrote:
>>> Ok, viewing seems to be working without a hitch. However, it appears
>>> that Link.onClick() is not being fired.
>>>
>>> public class PartnerHandbook extends WebPage {
>>>
>>> private int clicks=0;
>>>
>>> public PartnerHandbook() {
>>> super();
>>> add(new Label("test", "Partner Handbook"));
>>> add(new Label("clicks", new PropertyModel(this,
>>> "clicks")));
>>> add(new Link("testLink"){
>>>
>>> @Override
>>> public void onClick() {
>>>
>>> clicks++;
>>> }
>>>
>>> });
>>>
>>> }
>>>
>>> public int getClicks() {
>>> return clicks;
>>> }
>>>
>>> }
>>>
>>> "clicks" is never incremented and debugging shows it is never
> invoked.
>>> This works if I access the page directly. Any ideas?
>>>
>>> -scott
>>>
>>> -----Original Message-----
>>> From: Ate Douma [mailto:ate@douma.nu]
>>> Sent: Thursday, September 20, 2007 11:07 AM
>>> To: Jetspeed Users List
>>> Subject: Re: New Wicket Portlets Demo available
>>>
>>> Weaver, Scott wrote:
>>>> Ate,
>>>>
>>>> This is great news! Thanks for all of your hard work on the Wicket
>>>> portlet support!
>>>>
>>>> I have a couple small portlet apps I need to develop and really
>> wanted
>>>> to use Wicket to do so.
>>>>
>>>> Just one quick question: Which branch of Wicket should I develop
>>>> against?
>>> At this moment:
>>>
> http://svn.apache.org/repos/asf/wicket/branches/wicket-1.3.0-beta3-portl
>>> et-support
>>>
>>> See also
>>>
>>> http://issues.apache.org/jira/browse/WICKET-647
>>> and http://issues.apache.org/jira/browse/WICKET-983
>>>
>>> for more information how the portlet-support is implemented and
>> possible
>>> caveats.
>>>
>>> FYI: WICKET-983 concerns merging the portlet-support into the main
>>> Wicket trunk, something which is voted upon right now on the
>>> dev@wicket.apache.org list.
>>> See:
>>>
>>>
> http://www.nabble.com/-VOTE--WICKET-983%3A-Merging-portlet-support-tf448
>>> 6633.html
>>>
>>> Regards,
>>> Ate
>>>
>>>
>>>> Regards,
>>>> -scott
>>>>
>>>> -----Original Message-----
>>>> From: Ate Douma [mailto:ate@douma.nu]
>>>> Sent: Monday, September 17, 2007 12:38 PM
>>>> To: users@wicket.apache.org
>>>> Cc: Jetspeed Users List
>>>> Subject: 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-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: jetspeed-user-unsubscribe@portals.apache.org
>>>> For additional commands, e-mail:
>> jetspeed-user-help@portals.apache.org
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>>>> For additional commands, e-mail:
>> jetspeed-user-help@portals.apache.org
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>>> For additional commands, e-mail:
> jetspeed-user-help@portals.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>>> For additional commands, e-mail:
> jetspeed-user-help@portals.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: New Wicket Portlets Demo available
Posted by "Weaver, Scott" <we...@ugs.com>.
Still having some issues. I narrowed it down to the resourceWindow not
being set on the PortletWindowRequestNavigationalState during the call
to
org.apache.jetspeed.container.state.impl.JetspeedNavigationalStateCodec.
decodeParameter(). Starting at line 422, it looks like my request is
coming in as an action and hence skips the setting of the resource
window on the navigational state, which in turn, causes all of the logic
in the org.apache.jetspeed.resource.ResourceValveImpl to be skipped.
Any thoughts?
Thanks,
-scott
-----Original Message-----
From: Weaver, Scott [mailto:weavers@ugs.com]
Sent: Monday, September 24, 2007 10:06 AM
To: Jetspeed Users List
Subject: RE: New Wicket Portlets Demo available
Ahhh! I was wondering about the ResourceValve. I saw it but I didn't
see any comments on what its purpose was, so I just left it out. I will
throw that in and test. I am sure that is what the issue is. Thanks!
-scott
-----Original Message-----
From: Ate Douma [mailto:ate@douma.nu]
Sent: Monday, September 24, 2007 9:57 AM
To: Jetspeed Users List
Subject: Re: New Wicket Portlets Demo available
Weaver, Scott wrote:
> Thanks for looking at that, Ate. Yes I updated Friday actually
> (r578142). I guess I need to dig a little deeper. I run a custom
> pipeline, could I be missing something there?
Yes, for Wicket support I added a new resourceValve:
<bean id="resourceValve"
class="org.apache.jetspeed.resource.ResourceValveImpl"
init-method="initialize">
<constructor-arg>
<ref bean="org.apache.pluto.PortletContainer" />
</constructor-arg>
<constructor-arg>
<ref bean="PortletWindowAccessor" />
</constructor-arg>
</bean>
This valve needs to be plugged into your pipeline after the actionValve
and before the render valve (PageRenderValve in your case).
See also: https://issues.apache.org/jira/browse/JS2-729
Note: if you also use/need the /desktop you do need to update its
pipelines as well (see the latest pipelines.xml).
But also: wicket Ajax does not yet work in the /desktop. This is
actually a problem in J2 and not with the Wicket portlet support itself
AFAIK.
My plan is to fix that too before we release 2.1.3-dev.
Ate
>
> <bean id="no-aggregation-pipeline"
> class="org.apache.jetspeed.pipeline.JetspeedPipeline"
> init-method="initialize"
> >
> <constructor-arg>
> <value>NoAggregationPipeline</value>
> </constructor-arg>
> <constructor-arg>
> <list>
> <ref bean="webkeyValve"/>
> <ref bean="localeSelectorValve" />
> <ref bean="localizationValve"/>
> <ref bean="capabilityValve"/>
> <ref bean="portalURLValve"/>
> <ref bean="profilerValve"/>
> <ref bean="customizerValve"/>
> <ref bean="containerValve"/>
> <ref bean="actionValve"/>
> <ref bean="PageRendererValve" />
> </list>
> </constructor-arg>
> </bean>
>
> The webkeyValve, customizerValve and PageRendererValve are custom
> valves, the rest are the standard ones already provided.
>
> Thanks,
> -scott
>
> -----Original Message-----
> From: Ate Douma [mailto:ate@douma.nu]
> Sent: Saturday, September 22, 2007 12:19 PM
> To: Jetspeed Users List
> Subject: Re: New Wicket Portlets Demo available
>
> Scott,
>
> You're example works for me.
> I've actually copy/pasted it and it just works.
> Do you use at least jetspeed-2.1.3-dev (trunk, or at least >= r574908,
> Sept 12)?
>
> Ate
>
> Weaver, Scott wrote:
>> Ok, viewing seems to be working without a hitch. However, it appears
>> that Link.onClick() is not being fired.
>>
>> public class PartnerHandbook extends WebPage {
>>
>> private int clicks=0;
>>
>> public PartnerHandbook() {
>> super();
>> add(new Label("test", "Partner Handbook"));
>> add(new Label("clicks", new PropertyModel(this,
>> "clicks")));
>> add(new Link("testLink"){
>>
>> @Override
>> public void onClick() {
>>
>> clicks++;
>> }
>>
>> });
>>
>> }
>>
>> public int getClicks() {
>> return clicks;
>> }
>>
>> }
>>
>> "clicks" is never incremented and debugging shows it is never
invoked.
>> This works if I access the page directly. Any ideas?
>>
>> -scott
>>
>> -----Original Message-----
>> From: Ate Douma [mailto:ate@douma.nu]
>> Sent: Thursday, September 20, 2007 11:07 AM
>> To: Jetspeed Users List
>> Subject: Re: New Wicket Portlets Demo available
>>
>> Weaver, Scott wrote:
>>> Ate,
>>>
>>> This is great news! Thanks for all of your hard work on the Wicket
>>> portlet support!
>>>
>>> I have a couple small portlet apps I need to develop and really
> wanted
>>> to use Wicket to do so.
>>>
>>> Just one quick question: Which branch of Wicket should I develop
>>> against?
>> At this moment:
>>
>
http://svn.apache.org/repos/asf/wicket/branches/wicket-1.3.0-beta3-portl
>> et-support
>>
>> See also
>>
>> http://issues.apache.org/jira/browse/WICKET-647
>> and http://issues.apache.org/jira/browse/WICKET-983
>>
>> for more information how the portlet-support is implemented and
> possible
>> caveats.
>>
>> FYI: WICKET-983 concerns merging the portlet-support into the main
>> Wicket trunk, something which is voted upon right now on the
>> dev@wicket.apache.org list.
>> See:
>>
>>
>
http://www.nabble.com/-VOTE--WICKET-983%3A-Merging-portlet-support-tf448
>> 6633.html
>>
>> Regards,
>> Ate
>>
>>
>>> Regards,
>>> -scott
>>>
>>> -----Original Message-----
>>> From: Ate Douma [mailto:ate@douma.nu]
>>> Sent: Monday, September 17, 2007 12:38 PM
>>> To: users@wicket.apache.org
>>> Cc: Jetspeed Users List
>>> Subject: 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-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: jetspeed-user-unsubscribe@portals.apache.org
>>> For additional commands, e-mail:
> jetspeed-user-help@portals.apache.org
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>>> For additional commands, e-mail:
> jetspeed-user-help@portals.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail:
jetspeed-user-help@portals.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail:
jetspeed-user-help@portals.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: New Wicket Portlets Demo available
Posted by "Weaver, Scott" <we...@ugs.com>.
Ahhh! I was wondering about the ResourceValve. I saw it but I didn't
see any comments on what its purpose was, so I just left it out. I will
throw that in and test. I am sure that is what the issue is. Thanks!
-scott
-----Original Message-----
From: Ate Douma [mailto:ate@douma.nu]
Sent: Monday, September 24, 2007 9:57 AM
To: Jetspeed Users List
Subject: Re: New Wicket Portlets Demo available
Weaver, Scott wrote:
> Thanks for looking at that, Ate. Yes I updated Friday actually
> (r578142). I guess I need to dig a little deeper. I run a custom
> pipeline, could I be missing something there?
Yes, for Wicket support I added a new resourceValve:
<bean id="resourceValve"
class="org.apache.jetspeed.resource.ResourceValveImpl"
init-method="initialize">
<constructor-arg>
<ref bean="org.apache.pluto.PortletContainer" />
</constructor-arg>
<constructor-arg>
<ref bean="PortletWindowAccessor" />
</constructor-arg>
</bean>
This valve needs to be plugged into your pipeline after the actionValve
and before the render valve (PageRenderValve in your case).
See also: https://issues.apache.org/jira/browse/JS2-729
Note: if you also use/need the /desktop you do need to update its
pipelines as well (see the latest pipelines.xml).
But also: wicket Ajax does not yet work in the /desktop. This is
actually a problem in J2 and not with the Wicket portlet support itself
AFAIK.
My plan is to fix that too before we release 2.1.3-dev.
Ate
>
> <bean id="no-aggregation-pipeline"
> class="org.apache.jetspeed.pipeline.JetspeedPipeline"
> init-method="initialize"
> >
> <constructor-arg>
> <value>NoAggregationPipeline</value>
> </constructor-arg>
> <constructor-arg>
> <list>
> <ref bean="webkeyValve"/>
> <ref bean="localeSelectorValve" />
> <ref bean="localizationValve"/>
> <ref bean="capabilityValve"/>
> <ref bean="portalURLValve"/>
> <ref bean="profilerValve"/>
> <ref bean="customizerValve"/>
> <ref bean="containerValve"/>
> <ref bean="actionValve"/>
> <ref bean="PageRendererValve" />
> </list>
> </constructor-arg>
> </bean>
>
> The webkeyValve, customizerValve and PageRendererValve are custom
> valves, the rest are the standard ones already provided.
>
> Thanks,
> -scott
>
> -----Original Message-----
> From: Ate Douma [mailto:ate@douma.nu]
> Sent: Saturday, September 22, 2007 12:19 PM
> To: Jetspeed Users List
> Subject: Re: New Wicket Portlets Demo available
>
> Scott,
>
> You're example works for me.
> I've actually copy/pasted it and it just works.
> Do you use at least jetspeed-2.1.3-dev (trunk, or at least >= r574908,
> Sept 12)?
>
> Ate
>
> Weaver, Scott wrote:
>> Ok, viewing seems to be working without a hitch. However, it appears
>> that Link.onClick() is not being fired.
>>
>> public class PartnerHandbook extends WebPage {
>>
>> private int clicks=0;
>>
>> public PartnerHandbook() {
>> super();
>> add(new Label("test", "Partner Handbook"));
>> add(new Label("clicks", new PropertyModel(this,
>> "clicks")));
>> add(new Link("testLink"){
>>
>> @Override
>> public void onClick() {
>>
>> clicks++;
>> }
>>
>> });
>>
>> }
>>
>> public int getClicks() {
>> return clicks;
>> }
>>
>> }
>>
>> "clicks" is never incremented and debugging shows it is never
invoked.
>> This works if I access the page directly. Any ideas?
>>
>> -scott
>>
>> -----Original Message-----
>> From: Ate Douma [mailto:ate@douma.nu]
>> Sent: Thursday, September 20, 2007 11:07 AM
>> To: Jetspeed Users List
>> Subject: Re: New Wicket Portlets Demo available
>>
>> Weaver, Scott wrote:
>>> Ate,
>>>
>>> This is great news! Thanks for all of your hard work on the Wicket
>>> portlet support!
>>>
>>> I have a couple small portlet apps I need to develop and really
> wanted
>>> to use Wicket to do so.
>>>
>>> Just one quick question: Which branch of Wicket should I develop
>>> against?
>> At this moment:
>>
>
http://svn.apache.org/repos/asf/wicket/branches/wicket-1.3.0-beta3-portl
>> et-support
>>
>> See also
>>
>> http://issues.apache.org/jira/browse/WICKET-647
>> and http://issues.apache.org/jira/browse/WICKET-983
>>
>> for more information how the portlet-support is implemented and
> possible
>> caveats.
>>
>> FYI: WICKET-983 concerns merging the portlet-support into the main
>> Wicket trunk, something which is voted upon right now on the
>> dev@wicket.apache.org list.
>> See:
>>
>>
>
http://www.nabble.com/-VOTE--WICKET-983%3A-Merging-portlet-support-tf448
>> 6633.html
>>
>> Regards,
>> Ate
>>
>>
>>> Regards,
>>> -scott
>>>
>>> -----Original Message-----
>>> From: Ate Douma [mailto:ate@douma.nu]
>>> Sent: Monday, September 17, 2007 12:38 PM
>>> To: users@wicket.apache.org
>>> Cc: Jetspeed Users List
>>> Subject: 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-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: jetspeed-user-unsubscribe@portals.apache.org
>>> For additional commands, e-mail:
> jetspeed-user-help@portals.apache.org
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>>> For additional commands, e-mail:
> jetspeed-user-help@portals.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail:
jetspeed-user-help@portals.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail:
jetspeed-user-help@portals.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: New Wicket Portlets Demo available
Posted by Ate Douma <at...@douma.nu>.
Weaver, Scott wrote:
> Thanks for looking at that, Ate. Yes I updated Friday actually
> (r578142). I guess I need to dig a little deeper. I run a custom
> pipeline, could I be missing something there?
Yes, for Wicket support I added a new resourceValve:
<bean id="resourceValve"
class="org.apache.jetspeed.resource.ResourceValveImpl"
init-method="initialize">
<constructor-arg>
<ref bean="org.apache.pluto.PortletContainer" />
</constructor-arg>
<constructor-arg>
<ref bean="PortletWindowAccessor" />
</constructor-arg>
</bean>
This valve needs to be plugged into your pipeline after the actionValve and before the render valve (PageRenderValve in your case).
See also: https://issues.apache.org/jira/browse/JS2-729
Note: if you also use/need the /desktop you do need to update its pipelines as well (see the latest pipelines.xml).
But also: wicket Ajax does not yet work in the /desktop. This is actually a problem in J2 and not with the Wicket portlet support itself AFAIK.
My plan is to fix that too before we release 2.1.3-dev.
Ate
>
> <bean id="no-aggregation-pipeline"
> class="org.apache.jetspeed.pipeline.JetspeedPipeline"
> init-method="initialize"
> >
> <constructor-arg>
> <value>NoAggregationPipeline</value>
> </constructor-arg>
> <constructor-arg>
> <list>
> <ref bean="webkeyValve"/>
> <ref bean="localeSelectorValve" />
> <ref bean="localizationValve"/>
> <ref bean="capabilityValve"/>
> <ref bean="portalURLValve"/>
> <ref bean="profilerValve"/>
> <ref bean="customizerValve"/>
> <ref bean="containerValve"/>
> <ref bean="actionValve"/>
> <ref bean="PageRendererValve" />
> </list>
> </constructor-arg>
> </bean>
>
> The webkeyValve, customizerValve and PageRendererValve are custom
> valves, the rest are the standard ones already provided.
>
> Thanks,
> -scott
>
> -----Original Message-----
> From: Ate Douma [mailto:ate@douma.nu]
> Sent: Saturday, September 22, 2007 12:19 PM
> To: Jetspeed Users List
> Subject: Re: New Wicket Portlets Demo available
>
> Scott,
>
> You're example works for me.
> I've actually copy/pasted it and it just works.
> Do you use at least jetspeed-2.1.3-dev (trunk, or at least >= r574908,
> Sept 12)?
>
> Ate
>
> Weaver, Scott wrote:
>> Ok, viewing seems to be working without a hitch. However, it appears
>> that Link.onClick() is not being fired.
>>
>> public class PartnerHandbook extends WebPage {
>>
>> private int clicks=0;
>>
>> public PartnerHandbook() {
>> super();
>> add(new Label("test", "Partner Handbook"));
>> add(new Label("clicks", new PropertyModel(this,
>> "clicks")));
>> add(new Link("testLink"){
>>
>> @Override
>> public void onClick() {
>>
>> clicks++;
>> }
>>
>> });
>>
>> }
>>
>> public int getClicks() {
>> return clicks;
>> }
>>
>> }
>>
>> "clicks" is never incremented and debugging shows it is never invoked.
>> This works if I access the page directly. Any ideas?
>>
>> -scott
>>
>> -----Original Message-----
>> From: Ate Douma [mailto:ate@douma.nu]
>> Sent: Thursday, September 20, 2007 11:07 AM
>> To: Jetspeed Users List
>> Subject: Re: New Wicket Portlets Demo available
>>
>> Weaver, Scott wrote:
>>> Ate,
>>>
>>> This is great news! Thanks for all of your hard work on the Wicket
>>> portlet support!
>>>
>>> I have a couple small portlet apps I need to develop and really
> wanted
>>> to use Wicket to do so.
>>>
>>> Just one quick question: Which branch of Wicket should I develop
>>> against?
>> At this moment:
>>
> http://svn.apache.org/repos/asf/wicket/branches/wicket-1.3.0-beta3-portl
>> et-support
>>
>> See also
>>
>> http://issues.apache.org/jira/browse/WICKET-647
>> and http://issues.apache.org/jira/browse/WICKET-983
>>
>> for more information how the portlet-support is implemented and
> possible
>> caveats.
>>
>> FYI: WICKET-983 concerns merging the portlet-support into the main
>> Wicket trunk, something which is voted upon right now on the
>> dev@wicket.apache.org list.
>> See:
>>
>>
> http://www.nabble.com/-VOTE--WICKET-983%3A-Merging-portlet-support-tf448
>> 6633.html
>>
>> Regards,
>> Ate
>>
>>
>>> Regards,
>>> -scott
>>>
>>> -----Original Message-----
>>> From: Ate Douma [mailto:ate@douma.nu]
>>> Sent: Monday, September 17, 2007 12:38 PM
>>> To: users@wicket.apache.org
>>> Cc: Jetspeed Users List
>>> Subject: 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-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: jetspeed-user-unsubscribe@portals.apache.org
>>> For additional commands, e-mail:
> jetspeed-user-help@portals.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>>> For additional commands, e-mail:
> jetspeed-user-help@portals.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: New Wicket Portlets Demo available
Posted by "Weaver, Scott" <we...@ugs.com>.
Thanks for looking at that, Ate. Yes I updated Friday actually
(r578142). I guess I need to dig a little deeper. I run a custom
pipeline, could I be missing something there?
<bean id="no-aggregation-pipeline"
class="org.apache.jetspeed.pipeline.JetspeedPipeline"
init-method="initialize"
>
<constructor-arg>
<value>NoAggregationPipeline</value>
</constructor-arg>
<constructor-arg>
<list>
<ref bean="webkeyValve"/>
<ref bean="localeSelectorValve" />
<ref bean="localizationValve"/>
<ref bean="capabilityValve"/>
<ref bean="portalURLValve"/>
<ref bean="profilerValve"/>
<ref bean="customizerValve"/>
<ref bean="containerValve"/>
<ref bean="actionValve"/>
<ref bean="PageRendererValve" />
</list>
</constructor-arg>
</bean>
The webkeyValve, customizerValve and PageRendererValve are custom
valves, the rest are the standard ones already provided.
Thanks,
-scott
-----Original Message-----
From: Ate Douma [mailto:ate@douma.nu]
Sent: Saturday, September 22, 2007 12:19 PM
To: Jetspeed Users List
Subject: Re: New Wicket Portlets Demo available
Scott,
You're example works for me.
I've actually copy/pasted it and it just works.
Do you use at least jetspeed-2.1.3-dev (trunk, or at least >= r574908,
Sept 12)?
Ate
Weaver, Scott wrote:
> Ok, viewing seems to be working without a hitch. However, it appears
> that Link.onClick() is not being fired.
>
> public class PartnerHandbook extends WebPage {
>
> private int clicks=0;
>
> public PartnerHandbook() {
> super();
> add(new Label("test", "Partner Handbook"));
> add(new Label("clicks", new PropertyModel(this,
> "clicks")));
> add(new Link("testLink"){
>
> @Override
> public void onClick() {
>
> clicks++;
> }
>
> });
>
> }
>
> public int getClicks() {
> return clicks;
> }
>
> }
>
> "clicks" is never incremented and debugging shows it is never invoked.
> This works if I access the page directly. Any ideas?
>
> -scott
>
> -----Original Message-----
> From: Ate Douma [mailto:ate@douma.nu]
> Sent: Thursday, September 20, 2007 11:07 AM
> To: Jetspeed Users List
> Subject: Re: New Wicket Portlets Demo available
>
> Weaver, Scott wrote:
>> Ate,
>>
>> This is great news! Thanks for all of your hard work on the Wicket
>> portlet support!
>>
>> I have a couple small portlet apps I need to develop and really
wanted
>> to use Wicket to do so.
>>
>> Just one quick question: Which branch of Wicket should I develop
>> against?
>
> At this moment:
>
http://svn.apache.org/repos/asf/wicket/branches/wicket-1.3.0-beta3-portl
> et-support
>
> See also
>
> http://issues.apache.org/jira/browse/WICKET-647
> and http://issues.apache.org/jira/browse/WICKET-983
>
> for more information how the portlet-support is implemented and
possible
> caveats.
>
> FYI: WICKET-983 concerns merging the portlet-support into the main
> Wicket trunk, something which is voted upon right now on the
> dev@wicket.apache.org list.
> See:
>
>
http://www.nabble.com/-VOTE--WICKET-983%3A-Merging-portlet-support-tf448
> 6633.html
>
> Regards,
> Ate
>
>
>> Regards,
>> -scott
>>
>> -----Original Message-----
>> From: Ate Douma [mailto:ate@douma.nu]
>> Sent: Monday, September 17, 2007 12:38 PM
>> To: users@wicket.apache.org
>> Cc: Jetspeed Users List
>> Subject: 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-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: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail:
jetspeed-user-help@portals.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail:
jetspeed-user-help@portals.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: New Wicket Portlets Demo available
Posted by Ate Douma <at...@douma.nu>.
Scott,
You're example works for me.
I've actually copy/pasted it and it just works.
Do you use at least jetspeed-2.1.3-dev (trunk, or at least >= r574908, Sept 12)?
Ate
Weaver, Scott wrote:
> Ok, viewing seems to be working without a hitch. However, it appears
> that Link.onClick() is not being fired.
>
> public class PartnerHandbook extends WebPage {
>
> private int clicks=0;
>
> public PartnerHandbook() {
> super();
> add(new Label("test", "Partner Handbook"));
> add(new Label("clicks", new PropertyModel(this,
> "clicks")));
> add(new Link("testLink"){
>
> @Override
> public void onClick() {
>
> clicks++;
> }
>
> });
>
> }
>
> public int getClicks() {
> return clicks;
> }
>
> }
>
> "clicks" is never incremented and debugging shows it is never invoked.
> This works if I access the page directly. Any ideas?
>
> -scott
>
> -----Original Message-----
> From: Ate Douma [mailto:ate@douma.nu]
> Sent: Thursday, September 20, 2007 11:07 AM
> To: Jetspeed Users List
> Subject: Re: New Wicket Portlets Demo available
>
> Weaver, Scott wrote:
>> Ate,
>>
>> This is great news! Thanks for all of your hard work on the Wicket
>> portlet support!
>>
>> I have a couple small portlet apps I need to develop and really wanted
>> to use Wicket to do so.
>>
>> Just one quick question: Which branch of Wicket should I develop
>> against?
>
> At this moment:
> http://svn.apache.org/repos/asf/wicket/branches/wicket-1.3.0-beta3-portl
> et-support
>
> See also
>
> http://issues.apache.org/jira/browse/WICKET-647
> and http://issues.apache.org/jira/browse/WICKET-983
>
> for more information how the portlet-support is implemented and possible
> caveats.
>
> FYI: WICKET-983 concerns merging the portlet-support into the main
> Wicket trunk, something which is voted upon right now on the
> dev@wicket.apache.org list.
> See:
>
> http://www.nabble.com/-VOTE--WICKET-983%3A-Merging-portlet-support-tf448
> 6633.html
>
> Regards,
> Ate
>
>
>> Regards,
>> -scott
>>
>> -----Original Message-----
>> From: Ate Douma [mailto:ate@douma.nu]
>> Sent: Monday, September 17, 2007 12:38 PM
>> To: users@wicket.apache.org
>> Cc: Jetspeed Users List
>> Subject: 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-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: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: New Wicket Portlets Demo available
Posted by "Weaver, Scott" <we...@ugs.com>.
Ok, viewing seems to be working without a hitch. However, it appears
that Link.onClick() is not being fired.
public class PartnerHandbook extends WebPage {
private int clicks=0;
public PartnerHandbook() {
super();
add(new Label("test", "Partner Handbook"));
add(new Label("clicks", new PropertyModel(this,
"clicks")));
add(new Link("testLink"){
@Override
public void onClick() {
clicks++;
}
});
}
public int getClicks() {
return clicks;
}
}
"clicks" is never incremented and debugging shows it is never invoked.
This works if I access the page directly. Any ideas?
-scott
-----Original Message-----
From: Ate Douma [mailto:ate@douma.nu]
Sent: Thursday, September 20, 2007 11:07 AM
To: Jetspeed Users List
Subject: Re: New Wicket Portlets Demo available
Weaver, Scott wrote:
> Ate,
>
> This is great news! Thanks for all of your hard work on the Wicket
> portlet support!
>
> I have a couple small portlet apps I need to develop and really wanted
> to use Wicket to do so.
>
> Just one quick question: Which branch of Wicket should I develop
> against?
At this moment:
http://svn.apache.org/repos/asf/wicket/branches/wicket-1.3.0-beta3-portl
et-support
See also
http://issues.apache.org/jira/browse/WICKET-647
and http://issues.apache.org/jira/browse/WICKET-983
for more information how the portlet-support is implemented and possible
caveats.
FYI: WICKET-983 concerns merging the portlet-support into the main
Wicket trunk, something which is voted upon right now on the
dev@wicket.apache.org list.
See:
http://www.nabble.com/-VOTE--WICKET-983%3A-Merging-portlet-support-tf448
6633.html
Regards,
Ate
>
> Regards,
> -scott
>
> -----Original Message-----
> From: Ate Douma [mailto:ate@douma.nu]
> Sent: Monday, September 17, 2007 12:38 PM
> To: users@wicket.apache.org
> Cc: Jetspeed Users List
> Subject: 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-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: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: New Wicket Portlets Demo available
Posted by Ate Douma <at...@douma.nu>.
Weaver, Scott wrote:
> Ate,
>
> This is great news! Thanks for all of your hard work on the Wicket
> portlet support!
>
> I have a couple small portlet apps I need to develop and really wanted
> to use Wicket to do so.
>
> Just one quick question: Which branch of Wicket should I develop
> against?
At this moment: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.3.0-beta3-portlet-support
See also
http://issues.apache.org/jira/browse/WICKET-647
and http://issues.apache.org/jira/browse/WICKET-983
for more information how the portlet-support is implemented and possible caveats.
FYI: WICKET-983 concerns merging the portlet-support into the main Wicket trunk, something which is voted upon right now on the dev@wicket.apache.org list.
See:
http://www.nabble.com/-VOTE--WICKET-983%3A-Merging-portlet-support-tf4486633.html
Regards,
Ate
>
> Regards,
> -scott
>
> -----Original Message-----
> From: Ate Douma [mailto:ate@douma.nu]
> Sent: Monday, September 17, 2007 12:38 PM
> To: users@wicket.apache.org
> Cc: Jetspeed Users List
> Subject: 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-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: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: New Wicket Portlets Demo available
Posted by "Weaver, Scott" <we...@ugs.com>.
Ate,
This is great news! Thanks for all of your hard work on the Wicket
portlet support!
I have a couple small portlet apps I need to develop and really wanted
to use Wicket to do so.
Just one quick question: Which branch of Wicket should I develop
against?
Regards,
-scott
-----Original Message-----
From: Ate Douma [mailto:ate@douma.nu]
Sent: Monday, September 17, 2007 12:38 PM
To: users@wicket.apache.org
Cc: Jetspeed Users List
Subject: 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-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: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: findParent(BasePage.class) returns null
Posted by Eelco Hillenius <ee...@gmail.com>.
That is because you replace a parent in the hierarchy of the component
you ask the page for.
Eelco
On 9/17/07, Maris Orbidans <sm...@ime.lv> wrote:
> Hi
>
> The problem is that findParent(BasePage.class) returns a correct
> reference and after few more lines of code it returns null.
>
> How is that possible ?
>
> I am using 1.3 beta3.
>
> protected void onSubmit(AjaxRequestTarget target, Form form)
> {
> LoginForm loginForm = (LoginForm) form;
> String username = loginForm.getUsername();
> ProjectsSession session = (ProjectsSession) getSession();
> session.setLoggedIn(true);
> session.setUsername(username);
>
> for (int i =0 ; i<3 ; i++)
> {
> log.info("**** :
> "+(findParent(BasePage.class)==null)); // FALSE
> }
>
> MarkupContainer container = findParent(BasePage.class);
>
> container.get("menuPanel").setVisible(true);
> target.addComponent(container.get("menuPanel"));
>
> container.get("contentPanel").replaceWith(new
> ProjectsSearchResultsPanel("contentPanel").setOutputMarkupId(true));
> target.addComponent(container.get("contentPanel"));
>
> if (findParent(BasePage.class)==null) // TRUE
> {
> log.error("ERROR");
> }
>
> log.info("User " + username +" logged in");
> }
>
>
> 21:22:24,703 INFO [LoginPanel] **** : false
> 21:22:24,703 INFO [LoginPanel] **** : false
> 21:22:24,703 INFO [LoginPanel] **** : false
> 21:23:14,359 ERROR [LoginPanel] ERROR
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: findParent(BasePage.class) returns null
Posted by Maris Orbidans <sm...@ime.lv>.
Please ignore. I have figured it out myself.
> Hi
>
> The problem is that findParent(BasePage.class) returns a correct
> reference and after few more lines of code it returns null.
> How is that possible ?
>
> I am using 1.3 beta3.
>
> protected void onSubmit(AjaxRequestTarget target, Form form)
> {
> LoginForm loginForm = (LoginForm) form;
> String username = loginForm.getUsername();
> ProjectsSession session = (ProjectsSession) getSession();
> session.setLoggedIn(true);
> session.setUsername(username);
>
> for (int i =0 ; i<3 ; i++)
> {
> log.info("**** :
> "+(findParent(BasePage.class)==null)); // FALSE
> }
>
> MarkupContainer container = findParent(BasePage.class);
>
> container.get("menuPanel").setVisible(true);
> target.addComponent(container.get("menuPanel"));
>
> container.get("contentPanel").replaceWith(new
> ProjectsSearchResultsPanel("contentPanel").setOutputMarkupId(true));
> target.addComponent(container.get("contentPanel"));
>
> if (findParent(BasePage.class)==null) // TRUE
> {
> log.error("ERROR");
> }
>
> log.info("User " + username +" logged in");
> }
>
>
> 21:22:24,703 INFO [LoginPanel] **** : false
> 21:22:24,703 INFO [LoginPanel] **** : false
> 21:22:24,703 INFO [LoginPanel] **** : false
> 21:23:14,359 ERROR [LoginPanel] ERROR
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
findParent(BasePage.class) returns null
Posted by Maris Orbidans <sm...@ime.lv>.
Hi
The problem is that findParent(BasePage.class) returns a correct
reference and after few more lines of code it returns null.
How is that possible ?
I am using 1.3 beta3.
protected void onSubmit(AjaxRequestTarget target, Form form)
{
LoginForm loginForm = (LoginForm) form;
String username = loginForm.getUsername();
ProjectsSession session = (ProjectsSession) getSession();
session.setLoggedIn(true);
session.setUsername(username);
for (int i =0 ; i<3 ; i++)
{
log.info("**** :
"+(findParent(BasePage.class)==null)); // FALSE
}
MarkupContainer container = findParent(BasePage.class);
container.get("menuPanel").setVisible(true);
target.addComponent(container.get("menuPanel"));
container.get("contentPanel").replaceWith(new
ProjectsSearchResultsPanel("contentPanel").setOutputMarkupId(true));
target.addComponent(container.get("contentPanel"));
if (findParent(BasePage.class)==null) // TRUE
{
log.error("ERROR");
}
log.info("User " + username +" logged in");
}
21:22:24,703 INFO [LoginPanel] **** : false
21:22:24,703 INFO [LoginPanel] **** : false
21:22:24,703 INFO [LoginPanel] **** : false
21:23:14,359 ERROR [LoginPanel] ERROR
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New Wicket Portlets Demo available
Posted by Ate Douma <at...@douma.nu>.
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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: New Wicket Portlets Demo available
Posted by Gwyn Evans <gw...@gmail.com>.
On Thursday, September 20, 2007, 10:50:30 AM, Ate <at...@douma.nu> wrote:
> I've proposed to merge this into trunk now (before -beta4 release),
> but this hasn't been decided or voted upon yet.
Well, you can now vote on it, at least! :-)
/Gwyn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New Wicket Portlets Demo available
Posted by Ate Douma <at...@douma.nu>.
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 <at...@douma.nu> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New Wicket Portlets Demo available
Posted by Ate Douma <at...@douma.nu>.
Gwyn Evans 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!
Although that is going to take some of my time away the next 3 months, I still be online/able to answer questions normally on a daily basis :)
>
> 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)
I've just committed a fix for that test case.
Sorry I missed it out but then it didn't fail on me on my own machine (weird!).
Ate
>
> /Gwyn
>
> On Thursday, September 20, 2007, 10:20:23 AM, Dipu <di...@googlemail.com> 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 <at...@douma.nu> 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: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>
>
>
> /Gwyn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New Wicket Portlets Demo available
Posted by Dipu Seminlal <di...@googlemail.com>.
Thanks Gwyn
Regards
Dipu
On 9/20/07, Gwyn Evans <gw...@gmail.com> 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 <
> dipu.wkt@googlemail.com> 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 <at...@douma.nu> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
>
>
> /Gwyn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: New Wicket Portlets Demo available
Posted by Gwyn Evans <gw...@gmail.com>.
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 <di...@googlemail.com> 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 <at...@douma.nu> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
/Gwyn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New Wicket Portlets Demo available
Posted by Dipu Seminlal <di...@googlemail.com>.
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 <at...@douma.nu> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>