> First, we can't do static URIs because the URI constructor
throws an exception. However, we can at least provide static
strings.
There is the static method URI.create(String) that doesn't throw any exceptions. We can use it
for static URI contatnts.
> In fact, we do -- just not in ISimpleValue. Right now, they're
in the BasicValue* classes. You could do this:
> myContext.buildSimpleValue(new URI
BasicValueDateTime.ATTR_VALUE_TYPE_URI_STR), <Object value>).
> Should we move these all up to ISimpleValue so you
can use a constant that instead looks like
> ISimpleValue.DATE_TIME_TYPE_URI_STR?
I propose this only
for user's convenience, not for my. I think when
the user creates an instance of ISimpleValue using
IContext.buildSimpleValue(...) it will be more convenient to set the
type of ISimpleValue using such constant (like as
ISimpleValue.DATE_TIME_TYPE). By the way in this case user shouldn't be
aware which basic implementation of SimpleValue encapsulates needed
data type.
----- Original Message -----
Sent: Saturday, April 07, 2007 2:22
AM
Subject: [higgins-dev] buildSimpleValue
issues (was: <a very long subject>)
I am however going to try to address 2.a through 2.d.
I can look at 2.b while doing the above, but as there's a many to one
mapping from xml type to java type, we'll end up arguing about which should be
used for the defaults. I'll make this a slightly lower priority for
now.
On 2.c, we have this, just not like you want it :). First, we can't
do static URIs because the URI constructor throws an exception. However,
we can at least provide static strings. In fact, we do -- just not in
ISimpleValue. Right now, they're in the BasicValue* classes. You
could do this:
myContext.buildSimpleValue(new URI
BasicValueDateTime.ATTR_VALUE_TYPE_URI_STR), <Object value>).
Should we move these all up to ISimpleValue so you can use a constant that
instead looks like ISimpleValue.DATE_TIME_TYPE_URI_STR?
On 2.d, yes. There are a few that have similar symmetry
problems between their getData return arg and what they allow in the
constructor.
Jim
>>> "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx>
4/6/07 12:41 PM >>>
Jim,
> So, how does an IdAS consumer get an object to pass to one of
these methods? To date, we've said that they have to get them
> from the context provider -- this is why we have IContext.build*
methods (IContext.buildAttribute for example will build an IAttribute
> instance which could then be passed to IContext.addSubject. On
thee other hand, there are Basic implementations (like
> BasicAttribute) that are easy to instantiate without the help of a
context instance.
1. I do not think it is useful to have BasicComplexValue and BasicArttribute. Their type and
content (properties, values) depends on used higgins schema. So,
when we create "in-memory" instance of ComplexValue or Arttribute we need to validate its type. We need to validate the
type of value/property which we add to "in-memory" ComplexValue or Arttribute. So I prefer to use Context.build...() methods
for ComplexValue and Arttribute.
2. I am unable to answer what is better - to
have a set of BasicSimpleValue classes such as BasicValueInt,
BasicValueBoolean etc. or one IContext.buildSimpleValue(). I have some
proposals for ISimpleValue:
a) The type of object returned
by getData() should unambiguously correspond to xml type returned by
getType();
b) We may to define default xml type
for some java classes to allow the user to pass
null type into IContext.buildSimpleValue(URI type, Object value) method.
For example, if user pass null type and java.util.Date, this
method should create BasicValueDateTime
instance.
c) Add to ISimpleValue a
list of static public constant URIs of used xml
types. User will use this to pass the type of SimpleValue to
IContext.buildSimpleValue(URI type, Object value) method.
d) BasicValueDateTime need to have
BasicValueDateTime(java.util.Date obj) constructor.
Thanks,
Sergey Lyakhov
----- Original Message -----
Sent: Friday, April 06, 2007 5:07
PM
Subject: [higgins-dev] IdAS: The
contract CP's must follow for incomingobjects
We have a number of IdAS methods that take as input some interface or
another. For example, IContext.addSubject takes a set of IAttribute
instances, IContext.getSubjects takes an IFilter instance.
So, how does an IdAS consumer get an object to pass to one of
these methods? To date, we've said that they have to get them from the
context provider -- this is why we have IContext.build* methods
(IContext.buildAttribute for example will build an IAttribute instance which
could then be passed to IContext.addSubject. On thee other hand, there
are Basic implementations (like BasicAttribute) that are easy to instantiate
without the help of a context instance.
We need to decide whether the IdAS consumer must call the build*
methods to get interface instances to be used as arguments to
subsequent method calls, or whether the contract is simply the interface --
in other words, the CPs must allow any object to be passed as long as the
object implements the prescribed interface.
Arguments for making the IdAS consumer to always call build
methods to create interface instances:
- CP controls all instances. This allows the CP to always
deal with its own well-known concrete classes. It may be able to
do things that increase performance and scalability. It also allows
the CP to cause a failure earlier when the consumer is requesting something
that doesn't fit the context's model (schema).
Arguments for making the CP allow any instance of an interface to be
passed:
- Consumers can new an org.eclipse.higgins.idas.impl.Basic* class
without having an IContext instance and later use it (and
re-use it).
- Seems like a more natural programming model.
- Solves a chicken and egg problem which is this:
Some org.eclipse.higgins.idas.impl.AuthN* classes work by populating
themselves with properties (like name and password). Today, these are
simply instantiating BasicProperty objects which hold BasicValueString
data. This is wrong according to the existing model. To keep
with the existing model, I must change these such that the constructors
require an IContext instance so I can call IContext.build* to create these
properties.
That change means two things to the consumer: 1) The consumer must
already have an IContext instance. 2) The consumer cannot re-use an
AuthN*Materials across contexts. It means something worse to the
CP. Some CP's will require that open is called prior to allowing
build* methods to be called. If we need to get an
AuthNNamePasswordMaterials to open the context, but we can't until the
context is open, then we're stuck.
So, do people think a CP should allow any instance of a prescribed
interface to be passed as an argument, or do we want to maintain that only
instances produced by that CP's build methods may be passed?
Jim
_______________________________________________
higgins-dev
mailing
list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing
list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev