Eelco Hillenius wrote:
Wow, that was a long mail.
Well, you digested it much quicker that I expected!
It definitely took me much longer to write :)
It's a bit unfortunate that many of the
abstractions in Wicket actually came from the idea of separating the
servlet and portlet environments, and that we won't need those now,
Oh no!
Those abstractions really are a big advantage. Because of these, most developers don't need to use the servlet api directly anymore (although they still can)
and thus handling the differences between the servlet and portlet api is now much easier and safer to do than if those abstractions wouldn't be in place.
Developers actually using the servlet api directly might have a much harder time to migrate to a portlet environment as they might depend on unsupported
features then.
but I guess that's the way it goes. Most of those abstractions proved
to be useful anyway.
Definitely!
I think I agree with the proposal for the large part. For the details,
I think it is better to discuss actual code. The goal you are setting
seems to be high, but if you can pull it off, it sounds excellent!
Well, I have high requirements to meet to be able to really use Wicket in a
portlet environment so I can't really shoot for anything less.
Thanks for the thumbs up!
One thing about the implementation you're working on. Do you think you
can provide a test project with a configured portlet environment (e.g.
based on JetSpeed) so that it is real easy for people (including the
other team members of Wicket) to check it out and let our debuggers
loose on it? For me, and at least a couple of others, the fact that it
is quite some work to set a portlet server up, configure it to run a
(Wicket) application etc has been the greatest stumbling block in
trying to help out and review. If you can provide an environment that
is really easy to set up, I bet there will be quite a bit of interest
and it would increase the changes of succes this time considerably.
Yes, I will provide detailed instructions how to do so.
With the latest Jetspeed 2.1 release, its actually very simple now to install
and setup a test/development portal.
You just need to download the installer (the standard/minimum version is what I
usually install):
http://www.apache.org/dyn/closer.cgi/portals/jetspeed-2/binaries/jetspeed-2.1-installer.jar
If you accept the default provided embedded Derby database installing Jetspeed
requires only a few mouse clicks.
Then, start up the installed Tomcat server in your favorite IDE and hook it up to the debugger (I use Eclipse+MyEclipseIDE debugger integration) and you are
almost ready to start debugging your first Wicket portlet application :)
Build the war file, hot deploy it to the jetspeed deploy folder (I'll give exact instructions once I've got a test project ready) and add the Wicket portlet to
a portal page (which you can do on the fly with the Jetspeed page customizer) and set a few breakpoints.
Go!
I hope that sounds easy enough :)
I know its not as simple as running Wicket directly within Eclipse using Jetty,
but for me it is good enough.
Ate
