gavo.protocols.useruws module¶
Support for UWSes defined in user RDs.
To understand this, start at makeUWSForService.
- class gavo.protocols.useruws.UserUWS(service, jobActions, parameterGrammar)[source]¶
Bases:
UWSWithQueueing
A UWS for “user jobs”, i.e., generic things an a core.
These dynamically create job classes based on the processing core’s parameters. To make this happen, we’ll need to override some of the common UWS functions.
Note: For async operation (without a custom UWS), you can only have uploads in the upload parameter.
- getIdsAndPhases(*args, **kwargs)[source]¶
returns pairs for id and phase for all jobs in the UWS.
phase, last, after are the respective parameters from UWS 1.1.
- getURLForId(jobId)[source]¶
returns the handling URL for the job with jobId.
You must override this in deriving classes.
- jobdocPreamble = "<?xml-stylesheet href='/static/xsl/useruws-job-to-html.xsl' type='text/xsl'?>"¶
- joblistPreamble = "<?xml-stylesheet href='/static/xsl/useruws-joblist-to-html.xsl' type='text/xsl'?>"¶
- class gavo.protocols.useruws.UserUWSJobBase(props, uws, writable=False)[source]¶
Bases:
UWSJobWithWD
The base class for the service-specific user UWS jobs.
(i.e., the things that the UserUWSJobFactory spits out)
- class gavo.protocols.useruws.UserUWSTransitions[source]¶
Bases:
ProcessBasedUWSTransitions
The transition function for user-defined UWSes.
- gavo.protocols.useruws.makeUWSForService(service)[source]¶
returns a UserUWS instance tailored to service.
All these share a jobs table, but the all have different job classes with the parameters custom-made for the service’s core.
A drawback of this is that each UWS created in this way runs the job table purger again. That shouldn’t be a problem per se but may become cumbersome at some point. We can always introduce a class Attribute on UserUWS to keep additional UWSes from starting cron jobs of their own.