Hi Brent, It sounds like what you need is for a DAS instance to maintain a local helper context and provide a getHelperContext() method. Then, the client could register types by calling DAS.getHelperContext().getXSDHelper().define(). Or, they could even call DAS.getHelperContext().getTypeHelper().define() to define types programmatically.
If you don't want clients to register the types themselves, then the other alternative is for them to provide the schemaLocation of the xsd file in the config file and then DAS would call XSDHelper.define() in its context. That's analogous to passing a Factory in the config file for static types. What I don't really understand, is why the client needs to pass a URI to the DAS. What's that used for? Frank "Brent Daniel" <[EMAIL PROTECTED]> wrote on 12/01/2006 04:22:58 PM: > Hi Frank, > > Yes, my note was probably a bit muddled. I'm trying to connect a few > threads together. > > > 1) I began investigating the switch to TypeHelper.INSTANCE because of > a user's request for support of the XSDHelper.define() scenario I > described. Plus, it just seemed like a good idea to move away from the > deprecated method. > > 2) It's actually a user that is calling XSDHelper.define(). They want > to define their own Types, but do not want to generate static types. > The behavior they want is to define the types, and pass a URI to the > DAS so that the DAS will use their Types. > > 3) This is what I've started to do in the DAS. We create a new > HelperContext whenever we define new Types. The issue is that it > disallows the above scenario where the user has defined Types. > > 4) This was just a solution we had discussed before to avoid having > users call SDOUtil.registerStaticTypes(). Today, when a DAS > application is using static types, the user specifies a URI in the DAS > config. The DAS calls SDO.getTypes() to get the List of Types defined > with that URI. We had discussed moving to a model where the user > specifies the generated factory class in the config. This would allows > the DAS to call SDOUtil.registerStaticTypes() instead of the client. > This would also disallow the scenario where a user defines types with > XSDHelper, as they would no longer be able to pass a URI. > > > The main question I want to answer is whether we feel that the DAS > should support a scenario where we look up types that a user has > defined. If the answer to that is "yes", then I need to figure out > some way to do it technically with SDO that fits into the way the DAS > works with generated Types. > > Brent > > On 12/1/06, Frank Budinsky <[EMAIL PROTECTED]> wrote: > > Hi Brent, > > > > I'm having a lot of trouble parsing this note. You seem to be talking > > about several semi-related things, but I can't put it all together. > > > > 1) You say that you are currently using SDOUtil.createTypeHelper(). That > > has been deprecated, but it should still work ... so why are you talking > > about changing to using TypeHelper.INSTANCE? > > > > 2) If you want to have an XSDHelper in the same scope as a given > > TypeHelper you should have been calling SDOUtil.createXSDHelper(TypeHelper > > scope). That's also deprecated now, but should still work. > > > > 3) The proper way to do this now is to create a HelperContext whenever you > > want a uniquely scoped set of helpers. You call > > SDOUtil.createHelperContext(). Then, if you want a TypeHelper, you call > > context.getTypeHelper() or for an XSDHelper you call > > context.getXSDHelper(). > > > > 4) I don't know what your getting at with the point about passing a > > factory class in the config file or DAS looking up types by URI. Can you > > explain the problems more clearly? > > > > Frank. > > > > > > "Brent Daniel" <[EMAIL PROTECTED]> wrote on 12/01/2006 03:33:10 PM: > > > > > I'm running into an issue with the DAS' usage of SDO and looking for > > > some ideas. > > > > > > Currently in the trunk code, we are calling SDOUtil.createTypeHelper() > > > to create a TypeHelper instance. When I convert the DAS over to use > > > TypeHelper.INSTANCE or HelperProvider.getTypeHelper(), the behavior is > > > different -- Types from previous junit tests remain registered, so we > > > get errors when we try to create new Types with the same package URI > > > as a previous DAS invocation. > > > > > > We can get the old behavior by creating a new HelperContext each time > > > we build up a set of Types. However, I'm not sure that this the right > > > thing to do. It disallows the scenario where a user registers types > > > with XSDHelper.define() (or any other helper) and the DAS looks them > > > up by a provided URI. > > > > > > 1) Is the scenario above using XSDHelper.define() something we want to > > > support? We have talked in the past about having the DAS Config > > > specify an SDO Factory class rather than a URI, so that would disallow > > > this scenario as well. Maybe we should instead provide a DAS Factory > > > method that accepts a List of Types to support this scenario? > > > > > > 2) If the XSDHelper scenario is something we want to support, how do > > > we accomplish it? If we don't create a new HelperContext, we run into > > > an issue where the DAS tries to create Types with package URIs that > > > are already registered. We can get around this some of the time by > > > creating a new HelperContext whenever the user has not specified a URI > > > to look up existing Types. However, we are still creating a dynamic > > > root Type in the case where static or predefined Types are used. This > > > dynamic root Type will always have the same URI, so creating it a > > > second time will fail. > > > > > > Any thoughts? > > > > > > Brent > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
