Thanks for the immediate response.
We are building a product which acts as a complete backoffice solution
for a specific business type - so yes the 220 pages are doing really
different things. The reusable parts are all modeled as components. And
yes your assumption is right, all of the pages have an huge number of
embedded components.
I already thougth about this type of "block contributions" but I fear it
a bit, because the usage gets so much more complicated. So I like the
idea to encapsulate that aspect in its own component. Thanks for that.
We will try to make a prototype for it. But as I feared - the answer is
not simple - we will have to rebuild 100+ dialogs if we really want to
save the RAM spendings...
Cheers
Robert
Am 02.03.2015 um 15:33 schrieb Thiago H de Paula Figueiredo:
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
