On Mon, 02 Mar 2015 11:42:57 -0300, Robert Schmelzer <[email protected]>
wrote:
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.
Wow indeed. :)
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.
Yeah, you'll need to write a second component, but then you won't need to
change the existing usages of your component at all. It diminishes the
cost of change a lot.
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...
You can try figuring out the worst offender (the larger ones) and work on
them first.
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]
--
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]
