I've been down this path. I liked tapestry from a development point of view,
but had a problem with performance wrt Portlets. Basically, each Portlet has
it's own Hivemind registry, so if you have 5 portlets on a page you get 5 x the
initial performance hit for creating the portlet. If it's an i
This initial hit isn't so much of a problem for Servlet based applications, but
for Portlet applications it is, as it's per portlet, and even per portlet
instance for some classes of Portlet. It's bad enough for us to have given up
trying to use Tapestry for our portlet applications.
John
I looked into the issue with the start up time for Tapestry Portlets I was
having, and I added a JIRA issue for it. It seems like the initialisation of
the portlet is relatively short, but the initial render takes many seconds.
This is proably due to lazy initialisation meaning that a lot of the
Jesse Kuhnert gmail.com> writes:
>
> First I've heard of it. I didn't initially have plans on doing anything with
> it but I'd be happy to in order to save you from jsf. :)
>
> Whatever "it" is probably won't happen in the initial alpha release as I
> have some other items taking higher prior
I've written my own PortletPageResolver, to resolve portlet pages to subdirs -
i.e. View gets resolved to /View
This works fine, except when I want to navigate to a different make. When I
submit a form I want to go to a page called Winner. From the form success
listener I've tried returning "Winn
I'm evaluating Tapestry, and facelets, for use in a Portlet based project. We
need to migrate an exsiting Servlet/JSP based application to Portlets.
Currently I'm leaning towards Tapestry, from a coding standpoint it seems much
cleaner to me. The only problem is the initial overhead when adding a
