On Mon, Oct 18, 2010 at 4:13 PM, richard emberson
<richard.ember...@gmail.com> wrote:
> If I might ask a couple of follow-up questions?
>
> Is the primary driver for having the ability to
> dehydrate Components:
> 1) Lessening in-memory RAM usage,
yes. certain usecases require for a lot of components that are simple
labels, as such they have a lot of overhead. if a page displays 1000
labels it is a big waste. the idea was that once the page rendered
waht will be stored are the dehydrated versions of these 1000 labels
which will take up a tiny fraction of space.
> 2) Faster serialization,
> 3) Network transmission speed for machine-to-machine
> transfer of Components, or
> 4) Lessening disk usage when Components are stored on
> disk?
these are all derivatives of (1)
> Next, regardless of the driver, they are all good goals.
> Was any consideration given to refactoring the Object/Interface
> hierarchy so that 1) MarkupContainer could simply hold
> one type of Object (an IComponent) with an API that supports
> the wet/dry water state of Components (this would simplify
> the MarkupContainer code) and 2) maybe have a higher-level
> hydration interface so that things other than Components
> could support wet/dry states?
i dont think any one of the core developers is actively working on
this, so i dont think we have the cycles to put into analyzing the
possible ways of doing this right now.
the markupcontainer children is already object[] not componet[]. i
think the only piece of code that is missing is an
IComponentSourceProvider interface that components can implement and
functionality in container#detachchildren() that would replace
components with ComponentSourceEntry in the childrens array.
-igor
>
> For example (only):
>
> IHydratable
> boolean isHydrated()
> Object hydrated()
> Object dehydrated()
>
> IComponent extends IHydratable
> Component hydrated(Component parent)
> ComponentSourceEntry dehydrate(Component parent)
>
> ComponentSourceEntry implements IComponent
> boolean isHydrated() { return false; }
> Component hydrated(Component parent) {
> Component comp = (Component)hydrated()
> .....
> return comp
> }
> ComponentSourceEntry dehydrate(Component parent) { return this; }
>
> Component implements IComponent
> boolean isHydrated() { return true; }
> Component hydrated(Component parent) { return this; }
> ComponentSourceEntry dehydrate(Component parent) {
> ComponentSourceEntry compSE = (ComponentSourceEntry)dehydrated()
> .....
> return compSE
> }
>
> Thanks
>
> Richard
>
>
> On 10/14/2010 11:20 AM, Igor Vaynberg wrote:
>>
>> this is an experimental feature that hasnt quiet been finished yet.
>> see IComponentSource.
>>
>> -igor
>>
>> On Thu, Oct 14, 2010 at 10:15 AM, richard emberson
>> <richard.ember...@gmail.com> wrote:
>>>
>>> The MarkupContainer's ComponentSourceEntry is a private class with a
>>> private constructor. No where in the MarkupContainer code is an
>>> instance of ComponentSourceEntry created.
>>> Is ComponentSourceEntry something on its way out or some feature
>>> yet to be engaged?
>>>
>>> Richard
>>> --
>>> Quis custodiet ipsos custodes
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> --
> Quis custodiet ipsos custodes
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
