RE: [higgins-dev] Producer of user-supplied IdAS objects

["Tom Doman" <TDoman@xxxxxxxxxx>]

An IContext DOES represent a set of IDigitalSubjects!  A BasicContext implementation, on the other hand, CAN be in the business of creating attributes and values and filter items.  No offense in the world, even to the purist, no?

Anyway, to answer your question ... nope, I don't dislike it at all!  ;)

Tom

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 3/9/2007 3:19 PM >>>
Let me repeat and modify to see if I'm following correctly.  You like the factory-ish model which has the benefit of allowing CP's to dish out their own specific object instances.  As this might be a burden on some CP implementors, we could have a basic way of doing it (I'm liberally interpreting and generalizing what you said about the BasicObjectCP).
 
Putting some other ideas together:
- Tom was wondering if we could gather up all the factory-ish methods onto IContext instead of having them spread all over.
- In another message, I mentioned it'd be nice to have a BasicContext which could be extended by all CP's for their IContext class.
 
We could do both of these, such that an IdAS consumer only has to have an instance of IContext in order to create attributes, their values, metadata, filter items, etc., and the BasicContext impl could probably do a lot in the way of making it easy for CPs who don't need to implement their own specializations of IAttribute, IMetadata, etc.
 
The only thing I slightly don't like about this is it offends the sensibilities of the purist side of me.  If an IContext represents a set of IDigitalSubjects, why is it in the business of creating attributes and values and filter items?  Well, I think I can get past that.
 
Does anyone dislike the idea of rolling up the remaining createXYZ methods that we need onto IContext?
 
Jim

>>> "Broberg, Jeffrey C" <Jeffrey.Broberg@xxxxxx> 3/9/07 2:15 PM >>>
as a developer, i prefer the aspect of asking the cp for instances that may have specific implementations to that particular cp, but i can also see your argument for having the ability to instantiate items like BasicAttribute for other reasons.  So, it seems like it may just be a best practices item that needs to be documented.  but instead of placing them on the model, as a funky idea, could we state that you always get the objects from the cp, and we have a "BasicObjectCP" that implements the generic behavior needed for objects so that they adhere to your creating a filter example ? 
 



From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Friday, March 09, 2007 3:54 PM
To: higgins-dev@xxxxxxxxxxx 
Subject: [higgins-dev] Producer of user-supplied IdAS objects

All,
 
In the past, there has been a kind of unspoken understanding (at least in my mind) as to where certain CP objects must come from.  For example, I've been under the assumption that in order to pass an instance of IAttribute to method like IContext.createSubject, the caller needs to get that instance from the CP somehow.  This explains why we have createXYZ methods all over the place.
 
When people started implementing CP's, I added a number of basic implementations of IdAS interfaces (like BasicAttribute).  I did this to make life easier for CP implementers, not intending that an IdAS consumer would directly instantiate them.  In fact, I was thinking we needed to state that an IdAS consumer must never directly instantiate them, but rather use the createXYZ factory type methods provided by the CP.  This thinking was based in a belief that the CP could/would potentially create object instances that had special smarts in them (for example, a CP might choose to do syntax checking as the IdAS consumer is in the act of adding values to a phone number attribute).
 
Ok, so one problem with this model was that the IdAS consumer had to have an instance of whatever object contained the createXYZ factory method for whatever it was they needed an instance of.  Sometimes the consumer didn't have anything beyond an IContext instance (for example, when they need to create a filter containing an attribute assertion, or when they needed to create a new digital subject).  To solve that, I began thinking we should move all the createXYZ factory methods over to the model package.
 
Well, in retrospect, I wonder if we should just go ahead and allow consumers to instantiate things like BasicAttribute and pass them into functions that take things like IAttribute.  This just means the CPs have to honor the contract (that's already implied). For example, for a method like doSomething(IAttribute attr) means that the CP (the implementor of doSomething) must be able to handle any implementation of IAttribute (rather than only implementations it knows about).  For the places where consumers need to pass in objects (update and filter-based operations), I think this seems pretty reasonable.
 
Jim