Hi,
we built a prototype based on your suggestions. The main idea would work
- but there is one main issue we are not able to address:
Event propagation - if the component fires a request it will be
propagated to its "dummy" page where the component is hosted and we
cannot attach listeneres on it.
Another thing was, that the former parameters must be changed to
@Persist because in sub-sequent requests to the dialog the Environment
will not be filled. So we grow up the session, which is also not ideal.
So it seems that we have to take a closer look on where to buy cheap RAM
;-).
Robert
Am 02.03.2015 um 16:24 schrieb Thiago H de Paula Figueiredo:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
