set the reuse strategy to one that reuses components. we ship one,
look for implementations of the interface
-igor
On Fri, Mar 26, 2010 at 5:57 PM, wrote:
> Igor,
>
> I don't understand the optimal use of the different repeaters list
> views in different scenarios well enough yet, so I would be
Igor,
I don't understand the optimal use of the different repeaters list
views in different scenarios well enough yet, so I would be greateful
if someone could provide a link for more documentation.
As far as I understand, though, refreshingview.setreuseitemstrategy()
is about re-using items - it
repeaters support this, see listview.setreuseitems() and
refreshingview.setreuseitemstrategy()
-igor
On Fri, Mar 26, 2010 at 1:50 PM, wrote:
> But why in repeating views are the components duplicated for each row?
> Wicket should re-use the components - one instance for each row could
> do all
But why in repeating views are the components duplicated for each row?
Wicket should re-use the components - one instance for each row could
do all the rendering. Not one instance for each row which is a waste.
Caching is a different concept as it also preserves the data which is
not wanted in rep
the recommended way to handle this would be to cache the data not the
generated html
-igor
On Fri, Mar 26, 2010 at 1:11 AM, Martin Sachs wrote:
> We have a lot of Repeating views, which containing a lot of components,
> which also contains repeatingviews.
>
> To know would should be rendered, we
I'd wrap the getModel().getObject() in accessor methods to hide the
fact that you do that. getContract() is so much more legible than
getModel().getObject()
Martijn
On Fri, Mar 26, 2010 at 10:59 AM, Martin Sachs wrote:
> Yes we use LoadableDetachableModel. But we also do some times
> getModel().
Yes we use LoadableDetachableModel. But we also do some times
getModel().getObject() deeper in hierarchy inside the construction, to
e.g. set the visibility of a panel or to create just the right panel,
instead of creating e.g. ten panels and implement isVisible().
Martin
Jan Kriesten schrieb
Hi Martin,
> One reason for loading some data in contstructur or onBeforeRender is to
> prevent creating huge hierarchies. This is faster than override
> isVisible(), since isVisible would called more than one times.
why are you loading data in the component at all? There is this nice
'LoadableD
We have a lot of Repeating views, which containing a lot of components,
which also contains repeatingviews.
To know would should be rendered, we load some hopefully small
(listsizes, objectbyId, ...) datas from DB in the constructor and/or in
onBeforeRender and in isVisible. You are right, this is
On Wed, Mar 24, 2010 at 3:26 AM, Martin Sachs wrote:
> hi,
>
> we need caching of components, since the construction of huge
> hierarchies is not cheap. The rendering ist fast. We cache the rendered
> HTML of a hole component via a beheaviour and write them on the next
> requests into a Label (une
Maybe this will get you started
http://twenty-six-wicket-tricks.googlecode.com/svn/trunk/twenty-six-wicket-tricks/src/main/java/com/locke/library/web/panels/caching/CachingPanel.java
After reading Jeremy's reply I think this code suffers some thread-safeness
issues though.
Antoine
On Wed, Mar
Thanks Martin!
If possible can you please give a hint how to use behavior to cache the
rendered HTML for a component?
On 24.03.2010, at 10:26, Martin Sachs wrote:
> hi,
>
> we need caching of components, since the construction of huge
> hierarchies is not cheap. The rendering ist fast. We cach
On 24.03.2010, at 09:23, Jeremy Thomerson wrote:
> Components are not thread safe, and not intended to be used in this way -
> there would be a significant undertaking to make them cacheable, and the
> cost of the synchronization would likely far outweigh the current costs of
> component instanti
hi,
we need caching of components, since the construction of huge
hierarchies is not cheap. The rendering ist fast. We cache the rendered
HTML of a hole component via a beheaviour and write them on the next
requests into a Label (unescaped). So instead of creating the complete
hierarchie on every
Components are not thread safe, and not intended to be used in this way -
there would be a significant undertaking to make them cacheable, and the
cost of the synchronization would likely far outweigh the current costs of
component instantiation, etc...
Where you can make the biggest difference is
Hi,
since Wicket uses session to store the components hierarchy for a page is it
possible to store parts of the hierarchy in the application context instead of
the user session? If it's not possible do you consider it worth to add as
feature request?
What's the idea: imagine a home page of a w
f I do not break it myself)?
> Is it allowed to add a component instance to multiple other objects at the
> same time?
>
> I cannot find such info anywhere in wiki.
> Any hint in this area would be helpful.
>
> Regards
> Dariusz Wojtas
> --
> View this message in context:
ponent instance to multiple other objects at the
same time?
I cannot find such info anywhere in wiki.
Any hint in this area would be helpful.
Regards
Dariusz Wojtas
--
View this message in context:
http://www.nabble.com/Caching-components-tf4219802.html#a12004616
Sent from the Wicket - User maili
18 matches
Mail list logo
