[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] buildSimpleValue issues (was: <a very long subject>)

Jim,
 
>  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.
 
Thanks,
Sergey Lyakhov
----- Original Message -----
Sent: Saturday, April 07, 2007 2:22 AM
Subject: [higgins-dev] buildSimpleValue issues (was: <a very long subject>)

Ok, I'm going to back out the (local) changes I made as suggested in http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02076.html for now because this build* versus Basic* debate is going to take more thought and I don't want to change changes too many times.
 
I am however going to try to address 2.a through 2.d.
 
In terms of 2.a, the table here http://download.eclipse.org/technology/higgins/idas/lastNightlyBuild/javadoc/org/eclipse/higgins/idas/ISimpleValue.html#getData() was intended to draw the xml type to Java data type returned by getData.  Is there something else needed in the doc?  As far as implementation goes, I will add factory-like code to BasicContext.buildSimpleValue which will return the appropriate simple value. 
 
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