Do we want to add all these methods to IContext (it currently only has
createSubject and createFilter)? If no one complains, I'll plan on doing
this and implementing them in some BasicContext class that CP's can use.
>>> "Tom Doman"
<TDoman@xxxxxxxxxx> 3/9/07 3:39 PM >>>
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
_______________________________________________
higgins-dev
mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev