On Mon, 02 Mar 2015 10:43:09 -0300, Robert Schmelzer <[email protected]>
wrote:
Hi,
Hi!
we have a quite big business app counting about 220 pages.
Wow! 220! Does it really need that many unique pages? Does each one have
its own logic, different from the others?
By the way, which Tapestry version does the application use?
We are using
a UX style where you can pop up dialogs containing wizards, which can
again pop up dialogs and so on. The dialogs are opened in AJAX request
on top of the page and realized in tapestry as embedded components.
This shouldn't be a problem not impact the memory usage directly, unless
you have one or more pages or components with a large number of embedded
components and just a few of them used per request. If this is actually
the case, and it may be, please let us know so we can present an approach
to deal with this.
With this structure we are ending up, having four
ComponentPageElementImpl instances for Dialog D . In our very deeply
stacked and multiple times reused scenario we are ending up having about
200 000 ComponentPageElementImpl instances. For example we have a single
page holding 23 000 ComponentPageElementImpl instances.
That's definitely a problem, probably proving that assumption in my
paragraph above is true.
How can we adress this problem?
Does anyone have an idea, how we can reuse such dialogs, without
duplicating them in the memory?
The approach is doing something similar to what BeanEditor, Grid et al.
use: create a DialogDPage page (name doesn't matter). In its template,
create a <t:block id="dialogD> and put a DialogD instance inside. Use the
Environment service (or the @Environment annotation) to receive parameters
instead of actual parameters*. To get this block in another page, @Inject
ComponentSource and use
componentSource.getPage("DialogDPage").getBlock("dialogD"). To render it,
use the Delegate component.
* If you're going to use this component in many pages, you can rename
DialogD to InternalDialogD and create a DialogD component that receives
parameters the usual way (@Parameter fields) and deals with the
Environment and ComponentSource by itself.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
