On Jul 14, 2006, at 1:05 PM, Jim Marino wrote:
I'm wondering if specifying the start level in SCDL is crossing
semantics with eager init...
As background, one thing I was planning on proposing to the spec
was moving eager init off of @Init and onto @Scope for couple of
reasons. First, eagerness is associated with the scope, not an
initializer callback, IMO. The second reason is that it avoids a
problem I've been noticing lately where I want to eager init
something but I don't need an initializer callback, and I am forced
to add an empty method just to get the component to be instantiated
eagerly. Couple that with constructor-based injection, and I think
it is better to but things on @Scope.
I've hit this issue as well and it's annoying :-)
I think we still need initializer callbacks but that is independent
of whether initialization is eager or not.
Adding this to @Scope seems odd but I can't think of a better place
right now. I think this would be the default runlevel for this
component type (see below on why I think it should be configurable
per-component).
What if we said eager init is a component type concept and is true
or false (specified on @Scope)? Then, run level is the SCDL
configuration of eager init. So, a component would be eager
initialized based on the component type info and would be done so
in the order specified by the SCDL runlevel attribute. If no
runlevel attribute were present, we would default it to some level
(maybe 100).
I'm not sure that whether something is eagerly initialized is a
component-type level concept. I don't think that all usages of an
implementation will require that - some may be eager init, some may
not. With that thinking, whether to eager init and with what priority
would be a component level concept.
Also, I think we should have a default runlevel attribute on
composites as well that applies to all children. This may be
implicit in the above since composites are just components.
I was thinking order applied within a composite to the components of
a composite (either direct children or ones from include's). You
could specify an initLevel on a component implemented by a composite
but that would determine the order in which the sub-composite as a
whole was started; any order applied to components in the sub-
composite would be independent of the order of those in the parent.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
