Hi David, we do a similar thing at work, on Maya boot we look at the users sandbox settings and what project they're working on, then bind that projects data to a global Projects object that all our code then uses for paths etc. It's a nice way to work as it means that project specific data is also bound and can be used where needed. We do some extra path logic so that in the project file itself we can do things like
build_path+asset/path/to/something which is good as it allows extra path logic to be setup in the config file by the TD's rather than in code by the project object itself. Mark On 18 June 2014 11:58, David Martinez <david.martinez.a...@gmail.com> wrote: > I've just realized that replacing the contents of __dict__ with the data > retrieved from the file might not be the best way to go since it will get > rid of any of the instance attributes defined in the parent class. > So I've changed: > > self.__dict__ = data > > > with > > self.__dict__.update(data) > > > This seems to work nicely when it comes to avoid the issue. In any case, > I'm still interested on hearing your thoughts about the approach. > > > Cheers, > > > > > > On Wednesday, June 18, 2014 8:59:50 AM UTC+1, David Martinez wrote: >> >> Hello, >> >> As you might remember, a while ago I sent an email in which I was >> explaining how I wanted to create a schema for the projects at work. >> (Hopefully, I used the right word there). Since a lot of those projects are >> of the same type and they share not only data but behavior, I decided to >> create a class for them. >> >> Initially, I was declaring paths manually as Instance attributes but you >> guys told me that I was better off storing that information in a file and >> then somehow importing it. >> >> I've put together some code that reads JSON data from a file once the >> instance is initialized, and replaces the contents of __dict__ with the >> data retrieved from the file (A dictionary). >> >> Code can be seen here: >> >> - https://gist.github.com/davidmartinezanim/0eddcecc4d141c8fa165 >> >> >> Do you think that this would be an acceptable approach to for the >> 'Project' classes? >> >> The main reason why 'Project' is still a class is that all projects of >> this kind use the same functionality but there are other kinds of projects >> and I want them all to be children of a Project type. (Even though that the >> example above looks like a base class, it will be a concrete one inheriting >> from the base class instead of 'object') >> >> Thanks in advance >> >> >> -- >> David Martinez - Technical Animator >> >> Email: david.martinez.a...@gmail.com >> Website: http://www.elusiveideas.com >> >> >> -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to python_inside_maya+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/5a32b912-3d74-4980-b3bd-768bdc147b80%40googlegroups.com > <https://groups.google.com/d/msgid/python_inside_maya/5a32b912-3d74-4980-b3bd-768bdc147b80%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- ------------------------------------- Mark Jackson Technical Animation Director http://markj3d.blogspot.com/ -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAGQH2FFWUjEvA4vpjzCXS73A3UwcAFwf3ouumwY5%3DPCdcjW0xw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
