Wicket's native portlet support is still a work in progress, but so far it works fine. So far I have only done some testing with it (see wicket-portlet-examples subproject), but I'm expecting to start a real world application based on it in a month or two. So far I have tested running the examples on Apache JetSpeed2 and Liferay.

I committed the support for portlet modes and window states today (so they will not make it to the wicket 1.2.1, but are available on the 1.2 branch on the svn), and the basic portlet support is pretty much complete now. There is a couple of pending issues on my TODO list, but they are not going to change the actual functionality. 

Actually, opposed to what Eelco said, portlet matches a wicket application, so a portlet can contain multiple pages, and for example setResponsePage functions in the portlets exactly as in the normal web pages. Also, for different window states (like normal or maximized), you can have different wicket pages.

I believe wicket would fit nice on your project, if you don't mind the fact the portlet support has not yet been tested in any real world projects. 

What CMS framework are you going to use?


On 21.7.2006, at 23.55, Eelco Hillenius wrote:

Janne will try to answer some more later, but JSR 168 is support is
built in Wicket in a basic version. It uses a page per portlet, so if
you have four wicket portlets in your portal, you'll have four wicket
pages. The match is there.

I think it basically works, but is a bit rough in the sense that it
doesn't have specific support for portlet modes etc, and to my
knowledge, other than the other parts of Wicket, there isn't any
project the core team is running to eat our own dog food.

For the rest, I'll gladly let Janne and Ate answer. Same for what
portal environment has good CMS features etc.


On 7/21/06, Julian Klappenbach <[EMAIL PROTECTED]> wrote:
Does anyone have experience using Wicket with a Portal solution?  We
have a set of requirements that are very nicely satisfied with a CMS
framework.  It might help to reduce effort if we utilized the platform,
and design the elements in the UI featuring dynamic content as portlets
(JSR 168).  We'd like to use Wicket for this, but at first glance, it
doesn't seem like Wicket would fit, since the architecture of Wicket
assumes (correct me if I'm wrong) that there's a single backing object
per page.  What would be optimal is a single backing object per portlet
per page.

Perhaps this is outside of the intended domain of Wicket, and if so,
we'll save Wicket for later (as I'm very interested in exploring its
potential) and go the JSF route that's supported by the CMS framework.
Oh, I did notice that there was a CMS project in the Wicket SVN.  What
is the status of that project (alpha, beta, etc?)

Thanks in advance,

Julian Klappenbach
Architect / Development Lead
Ramp Technology Group

Janne Hietamäki

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
Wicket-user mailing list

Reply via email to