> From: Ryan Leslie <ryle...@gmail.com>
> Sent: Thursday, October 8, 2009 11:24:06 AM
>
Ryan -
I'm also posting this to the generateds-users list. There may be
others who are interested and have ideas on it.
> > I'm sure that you understand how to use this better than I do. If
> > it enables you to do the tasks that you foresee for yourself, then
> > it sounds good to me.
> >
> > Do you think that we've implemented something that is general
> > enough so that it will enable you to solve problems in the future,
> > too?
>
> Well, I wouldn't say I understand it any better. As I see it, the goal
> of member_data_items_ {} was simply to list the members of the
> generated class and their types. Let me summarize what I believe we've
> been doing and why. For this work, it was noted that:
>
> 1. An element's (generated class's) 'content' (valueOf_) wasn't making
> its way into member_data_items_, although, from Python's perspective
> this can be regarded as just a member of the class with an expected
> type. More simply, valueOf_ is just another argument to init(), so
> anyone interested in using member_data_items_ for type information
> misses it for valueOf_ in their subclass / specialized __init__() or
> factory.
>
OK. So, we've extended the use of member_data_items_ to (1) mixed
content elements and (2) elements that extend simple types. Sounds
good.
> 2. In considering 1) we started to realize that not only is there a
> 'terminal' python type associated with a particular
> attribute/child/content, but that there are higher-level abstractions
> in the XSD (e.g. RelationType) that can also describe what it is.
> Although there may currently be no related python types for these
> abstactions (e.g. RelationType doesn't really have a generated class),
> it's reasonable to still provide that info.
So, we've provided additional information in the generated class
that can be of use to those who are writing applications. Sounds
like a step forward.
>
> 3. It's useful (and better encapsulation) to have a convenience method
> for accessing member_data_items_ (see memberSpec() above). In this
> case, we observed that through inheritance (xs:extension), which
> generateDS supports, it's possible to have generated classes like
> 'class DerivedType(BaseType)'. Since, DerivedType instances work
> directly with BaseType members (e.g. in __init__()) it's useful for a
> derived type instance to somehow be able to provide type information
> for those inherited members. That's what our MRO-aware memberSpec()
> does, which is capable of looking up specs in parent classes. And
> since this is something that every class can have, then yes, it
> probably does make sense for it to exist in the super class. I think
> in the future, whenever possible, we should think of ways to make
> methods generic so they can go into the super class. There are
> probably some existing generated methods which fit the bill, but it's
> reasonable to not fix those if they're not broke.
Seems reasonable. Let's take one step at a time until we
understand what some of the additional use cases are.
>
> Actually, my example memberSpec() function is probably not sufficient.
> I believe generateDS can also generate member_data_items_ as a list,
> and not a dict. In that case we'd obviously need a different version
> that just does a linear search:
>
> Untested:
>
> def memberSpec(cls, memberName):
> """" Return a MemberSpec for the named member.
>
> Raises KeyError if no MemberSpec is found.
> """
> for class_ in cls.mro()[:-1]:
> for name, spec in class_.member_data_items_:
> if name == memberName:
> return spec
> raise KeyError('No member spec for: ' + memberName)
> memberSpec = classmethod(memberSpec)
>
> And maybe to be more consistent the dictionary version should be written as:
>
> def memberSpec(cls, memberName):
> """" Return a MemberSpec for the named member.
>
> Raises KeyError if no MemberSpec is found.
> """
> for class_ in cls.mro()[:-1]:
> try:
> return class_.member_data_items_[memberName]
> except KeyError::
> pass
> raise KeyError('No member spec for: ' + memberName)
> memberSpec = classmethod(memberSpec)
>
> Since these are class methods, the class of the instance these are
> called on should be automatically passed. You can rename / rewrite
> these however you want. I'll be glad to test them out, though, in the
> next version.
>
Sounds good. And, since generateDS enables you to use your own
version of class GeneratedsSuper (by providing a module
generatedssuper containing class GeneratedsSuper where your app can
import it), I'll suggest that we let users provide this method on
an individual basis. Later, when we had more experience with this,
perhaps we can add it to the distribution version.
> > In order to keep us in synch, I've attached a new version with the
> > two fixes mentioned above.
>
> Thank you. Looks as expected from your description.
I'll wait until next week sometime. Then if we have not found any
bugs, I'll release a new version. Oh, and I need to fix up the
unit tests on this, too.
Thanks again for all the help. And, thanks again for taking the
time to write out those explanations, above. It's very helpful,
and will be useful when I'm trying to write some additional
documentation on this.
- Dave
--
Dave Kuhlman
http://www.rexx.com/~dkuhlman
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
