Well maybe not the artist names in there since that is something that usually changes and is handled in the project tracking system. On May 10, 2014 8:01 PM, "LIJU kunnummal" <[email protected]> wrote:
> Hi David, > *Creating classes for Project* > > Maintaining different classes for different project is not good idea > as justin said. I would recommend creating config files(eg:xml) for each > projects, these config describes all the information about the project like > project name, different paths, mount drive, artist working on this projects > and even folder structure etc. You can write generic classes which will use > this config to define your project and create the folder structures too. > Even you can create a tool to create this config (and related files) which > can be handled by any user(producers, supervisors etc) to setup a project. > This way there no need to rewrite codes for every project. > > Cheers > > > > > On Friday, 9 May 2014 13:54:10 UTC+5:30, David Martinez wrote: >> >> Hello, >> >> I'm working on a new script and I'm looking for some advice in relation >> to *Software Design*. >> >> The tool that I'm working on allows to import files into the current >> scene and make changes to the hierarchy. The tool is going to be used by a >> few different departments and the way files are imported depends both on >> the department using the tool and the options selected from the interface. >> Here is a list of the things that I want to accomplish: >> >> *Here are some things to keep in mind* >> >> *Creating classes for Project* >> >> Different projects might have different folder structures and the data is >> not necessarily in the same place for each different project. Because of >> that, I thought that the best thing to do would be to create a base class >> in which I define the basic functionality and then. for those projects that >> have a different structure, I can subclass from the base class and >> overwrite the methods that need to be tweaked. By doing so, I won't be >> duplicating code but just only changing the one that I need to change. >> >> Question 1: >> Does that sound like the best way to go? >> >> >> >> *Isolate Functionality * >> I understand that the best thing to do is isolate functionality and avoid >> having functions/methods that try and tackle with a bunch of unrelated >> stuff. Having said that, I'm not sure when to stop breaking things down and >> I often end up with functions/methods that have simple calls to built-in or >> third party libraries. When that happens, it is crear to me that I've gone >> too far. >> >> Question 2: >> How do you decide what needs to be broken down and what doesn't? >> >> *Allow different UIs* >> >> I want to be able to control the same functionality using different UIs >> (only one would be running at the same time). Because of that, it is clear >> to me that none of the core functionality should be part of the interface >> but isolated (see previous point) >> >> This would allow me to have different versions of the UI and or different >> ways to display the data. This could also be used to load one or the other >> based on the existence of some libraries on the system. Ideally, I would >> like to be able to switch between different UIs at runtime. >> >> Again, it looks to me like OOP might be helpful here. The way I see it, I >> could create a base class that communicates with the main script and then a >> series of subclasses that, not only display a different interface but >> overwrite the functionality of those methods when necessary. >> >> Question 3: >> Do you think the use of classes is justified here? Would do rather use >> another approach? >> >> *Linking different elements together* >> >> I have to admit that I'm having trouble on seeing how to link the >> different elements together. At the moment I have different classes for the >> UI, the project and also for the importer itself (given the fact that >> depending on the department, the import process should be different). >> >> At the moment, I have the UI create an instance of the importer class, >> since it the department is defined in the interface and the importer will >> relate on some of the instance attributes of the UI. Having said that, I >> have the feeling that the instance of the importer should be created >> somewhere else and only change when the department is changed instead of >> the UI itself. If that's the case, I'm not sure how I would communicate >> with the instance variables of the UI. >> >> Question 4: >> What do you think it would be the best way to structure the code in this >> case? If I create an instance of the importer outside of the UI, >> should I pass the instance of the UI as an attribute in order to access >> its class attributes? I want to make sure I'm structuring the code in a way >> that makes sense. >> >> >> Thanks a lot in advance, >> >> Cheers, >> >> >> -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/961aae65-8b60-4248-9c15-41864e466c17%40googlegroups.com<https://groups.google.com/d/msgid/python_inside_maya/961aae65-8b60-4248-9c15-41864e466c17%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA02A21Be%3D%3DGrOMhNu0s6Qydd%3Dv7Jy3YJhO92J2VeECt-A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
