Re: Portlet performance
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 work is delayed until the initial render? I'm now in the situation where I hava JSF and a Tapestry version of a portlet, both of which do the same thing but the JSF version can be added to the portal in less than a second, the Tapestry version takes about 10. It's looking like I am going to have to go down the JSF/Facelets path rather than Tapestry. I prefer the Tapestyr aproach, but we can't take the performance hit. Is there anything I can provide to help find the real source of the problem, or is it unlikely to be fixable? Thanks John. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Portlet performance
Jesse Kuhnert jkuhnert at 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 priority, but if you start a jira issue with some clear parameters for me to test with we can probably figure something out. I've done a few more timings, and it seems like the Registry construction isn't the culprit. ApplicationPortlet.init takes about 2.5s (.6 of which is the constructRegistry call). The initial render takes 4.5s . Will this initial hit be when it constructs the State Object that I am injecting? I'll create a Jira issue, but just wanted to make sure I wasn't doing something silly first. Thanks John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Portlet page resolving.
I've written my own PortletPageResolver, to resolve portlet pages to subdirs - i.e. View gets resolved to portlet-name/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 Winner, injecting the Winner into the View and returning the IPage. Both these resulted in Page 'Winner' not found in application namespace. The only thing that has worked so far is returning portlet-name/Winner. It seems like when I return Winner my PortletPageResolver is not being called. Is it because the PortletPageResolver only resolves the Home page location? Thanks John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Portlet performance
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 portlet to a page. I understand this is because creating the per Portlet instance of the Hivemind registry takes some time. My simple test portlet written in facelets adds to the page in about a second, but the tapestry version takes about 10. The customer probably won't stand for this. Is there anything I can do to reduce this initial hit? Is this something being addressed in 4.1 ? Thanks John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
