Richard S. Hall wrote:
Yes, this is an open-ended question and there is likely no single answer.
The mission of iPOJO is to make creating dynamic applications simpler.
Precisely how you use it to accomplish this depends on your use case.
The main debate, it seems, is when to use an object and when to use a
component. Since iPOJO components handle dynamism (among other
things), you may choose to use it for those pieces of your application
that require dynamism, for example, but it is difficult to say when to
decide between object vs component. Granularity is another metric.
iPOJO is a full-blown, hierarchical component model built on top of an
object-oriented language. In the end, it leaves these decisions up to
you.
-> richard
Does this mean iPojo strives to make it easy for me to smoothly evolve
my bundle through the entire continuum starting from one-uber-component
and ending at all-is-component? Naturally I am free to stop at any
appropriate point during this evolution.
On the practical side:
1) Is it possible (and ideally easy and clean) for components to create,
configure and manage the lifecycle of other components at runtime? This
is required for all stages where near the all-is-component point as I
replace more and more of the traditional object construction with the
higher-abstraction of component instance construction. Still not all
components need to exist all the time - in fact only a small set of
"core" components do. For example in the classical runtime scope
hierarchy of application-session-request only the application scoped
components exist all the time while the session and request scoped
components must be created and destroyed depending on the number and
state of sessions.
2) If a component propagates a service dependency to objects that are
created in the traditional way will iPojo support that dependency within
these objects?. For example consider the case when a component has a
temporal dependency. That component creates a new object and passes the
dependency to it. Later some code within this new object calls the
dependency. Will iPojo perform all the required management of this call:
block for the required period and when it expires throw an exception or
delegate to a default implementation? Things like these are again
required for all the "mixed" stages where the
create-configure-start-stop-destroy state machine of some objects is
managed by iPojo and of other objects by the programmer.
Cheers,
Todor
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
