[
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
