On Jul 14, 2006, at 1:58 PM, Jeremy Boynes wrote:
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.
Eager init may be one of those half-way concepts. In some cases a dev
may want to always eagerly initialize something -e.g. something that
performs some action when a scope comes into existence. I could
probably go either way. When would we have the case some
configurations are eager on others not?
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.
Yes good point.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
