Thats kinda kool. Need time to digest it though. One thing I would prefer is to not have component participate in constraint validation.
At 10:20 AM 6/5/2002 -0400, you wrote: >On Tuesday 04 June 2002 07:20 pm, Peter Donald wrote: > > I have been experimenting with something like > > > > <constraint type="initializer" value="o.c.TimeServer"/> > > <constraint type="initializer" value="o.c.BlahServer"/> > > > > The constraints will be container specific but can do most of what I wanted > > but so far the experients been less than successful. > >Here's something weird and off-the-wall. > >Ideally, we would want container-agnostic constraints, correct? > >And in most (all?) cases there is a container-containee heirarchy with a root >container at the top, ala (sorry my ascii art skills are sub-par) > > +----------------+ > | Root Container | > +--+-------------+ > | > +-----------+------+-----+ > +-------+ +-------+ +--------+ > | Comp1 | | Comp2 | | Comp3 | > +-------+ +---+---+ +--------+ > | > +-----+----+ > +---------+ +---------+ > | SubComp1| | SubComp2| > +---------+ +---------+ > > >How about using XPath expression? > >Peter's examples above could be written as: > ><constraint value="o.c.TimeServer/@initialized"/> ><constraint value="o.c.BlahServer/@initialized"/> > >various lifecycle stages could be represented as "attributes" upon roles, >"elements". The container is responsible for the mapping. My inspiration for >this is from Jaxen (http://jaxen.org) which lets you execute XPath >expressions against arbitrary object models (or anything you can represent as >an element-attribute heirarchy) by subclassing their >org.jaxen.DefaultNavigator class. Different containers could have their own >implementations to perform the mapping as needed for their internals. > >Or for something more complex, say Comp1 needed a SocketServer with SSL >sockets, we could do > ><constraint >value="component-exists(o.a.a.cornerstone.service.sockets.SocketManager/ssl)"> > >But then how does the container know to determine if the SocketManager has a >specified socket type? It doesn't. It just knows how to pass the constraint >resolution onto the SocketManager. SocketManager could implement an interface >such as ConstraintResolveable that would indicate to a container that it >knows how to resolve contraints that delve into its internal component >structure that the container may be unaware of. > >Sometimes expressing everything as XML can become unweildy. (i have a >hammer.. etc etc). > >But just some seriously random thoughts. Fire away and ask questions. >-pete > >-- >peter royal -> [EMAIL PROTECTED] > >-- >To unsubscribe, >e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
