Currently the different application specific deadline submitter’s frequently mix GUI code with application logic.
This architecture makes it difficult to extend a submitter.
Common scenarios for extending are:
- Studio’s build their own streamlined GUI and just want to utilize the submitter as an API without a GUI
- Studio’s want to extend the existing GUI
So to fix it there could be at least two approaches:
MINIMALISTIC (backwards compatible & minimal OOP)
- a settings class which throws errors when an invalid value is set and which can be utilized from the GUI and code
class Settings(object):
def getpriority(self): return self.__x
def setpriority(self, value):
if value > 100: raise ValueError("Priority can't be higher then 100")
self.__x = value
x = property(getx, setx, "I'm the 'x' property.")
1b) If no OOP available (MaxScript) a function which is used to set a value on an array and throws errors if the value is out of range
2) separate function which allow tweaking and intercepting the original code easily:
def submitter_function():
settings = getDefaultSettingsForScene()
preUISettingsTweakHook(settings)
ShowUserUI(settings)
postUISettingsTweakHook(settings)
submitJob(settings)
saveSettingsAsDefaultForNextSubmission(settings)
OOP (object oriented)
[code]class SettingsBase()
class SubmitterBase()
def submit: raise NotImplementedException()
class SubmitterGuiBase() # based on PySide
def getDefaultSettingsForScene()
return SettingsBase
def buildWidgets()
Now every submitter inherits from the base
class MaxSubmitter(SubmitterBase)
class MaxSubmitterGui(SubmitterGuiBase)
If customers have a custom submitter they just inherit and overwrite and the code lifes in custom
class MaxSubmitterInhouse()
class MaxSubmitterGuiInhouse(MaxSubmitterGui)[/code]
etc.
We wanted to bring up the topic for discussion in the hope that the submitters will be easier to extend in the future.
Thanks
Patrick