David E. Jones wrote:
On Feb 13, 2007, at 3:46 AM, Jacopo Cappellato wrote:
What about implementing something more robust in this direction?
I'm thinking of implementing document processor and distribution
features for the OFBiz framework.
The idea is this:
* when a user submits a report creation request (e.g. an invoice), he
has also to provide the distribution channel (file, mail, print, fax,
etc...) and also the physical device options (to and cc email address,
printer name, fax number etc...)
* the request is stored in a record somewhere (a new entity or
something existing, in the Content component?, or just the JobSandbox
entity) with the following information:
jobId|status|screen path|input context(serialized?)|output channel
(print/mail etc...)|output options (e.g. \\printserver\prt01, num of
copies etc..)
* an async service listens to this entity and process the report
creation requests, then updates the status there
For set of documents we could simply create many records in the above
entity.
Does it make sense?
Yeah, I think so. Sounds interesting.
As far as my thoughts on which to go: rather than having job management
just for this, it might be nice to use the service engine job management
for it and just store parameters in the persisted context and such. The
service engine job management is pretty feature rich on a low level, but
it needs some enhancements to the management UI. That is actually of the
areas that may see some work during the dev conference.
-David
Ok, I will look into the details in this direction.
The next steps could be:
a) review the existing job scheduling services and entities (what is
missing or should be enhanced to properly support output management?)
b) ui: enhancements to the webtools
c) ui: implement a new screen in WorkEffort for "My Submitted Jobs"
where a user can see the job scheduled by him and maybe further filter
the list to see the one of 'type' output (aka documents)
d) create a generic service (similar to the one used to send emails),
that given a context, a printer name, and a screen name (the template
for the document) can be put in the job queue (async, thus visible in #b
and #c) and once executed will create a pdf and send it to the printer
Misc ideas:
A) if we store the persisted context in the JobSandbox, then the same
job can be re-run to recreate the document: the contaxt is passed to the
screen definition, the actions (minilang/bsh) are run and the context is
filled with data, that is then shown on screen by the widgets/fo templates
B) as an alternative option to #A, we could also give the ability to
store the persisted context AFTER the actions are run, so that, if we
rerun the job (aka recreate the document) the context is immediately
served to the widgets/fo templates: this would be a nice way to "store"
the documents (like invoices etc...); do you think it is possible/useful
something like this?
Anyone interested in this?
Ideas, remarks?
Jacopo