Re: MarkupContainer's ComponentSourceEntry
On Mon, Oct 18, 2010 at 4:13 PM, richard emberson
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
>> 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
Re: MarkupContainer's ComponentSourceEntry
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,
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?
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?
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
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
Re: MarkupContainer's ComponentSourceEntry
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 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
MarkupContainer's ComponentSourceEntry
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
