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
<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
