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

Sergey,

+1 on the thanks for pointing out the static create - I'd totally missed 
it and implemented my own (URIHelper).
I am going to remove my redundant class soon and change my code to use 
this function.

Thanks,
Mike

higgins-dev-bounces@xxxxxxxxxxx wrote on 04/10/2007 12:54:52 AM:

> Thanks for pointing out the static create method.  And I also agree 
> on the other point.  I started implementing buildSimpleValue on 
> BasicContext and you're right, it doesn't make sense to have users 
> know about the constants in the BasicValue* classes.
> 
> Jim
> 
> >>> "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx> 4/9/07 6:05 AM >>>
> 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 ----- 
> From: Jim Sermersheim 
> To: 'Higgins (Trust Framework) Project developer discussions' 
> 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 ----- 
> From: Jim Sermersheim 
> To: higgins-dev@xxxxxxxxxxx 
> 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
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev