Andreas Hartmann wrote:
That would require that the workflow schema contains a state
"non-existent" with a transition to the state "authoring", triggered
by the event "create". Does this make sense? What do the others think?
i see the problem now, thanks for explaining. but these states could
be implicit, no need to clutter up the workflow schemas with obvious
things.
Hmmm, I'm wouldn't like to add implicit states. IMO the actual workflow
schema should resemble the configuration 1:1.
BTW, currently we have some implicit "mappings" from states,
workflow variables, and AC roles to GUI elements:
- the "live" display is hard-wired to the "is_live" variable
- the "visit" role has a special meaning in the live area
- IIRC "admin" has a special meaning as well
I don't like these either (but I guess there's no obvious,
straightforward solution to this problem). It boils down to
configuration vs. convention (ATM we use convention). IMO
convention needs good and prominent documentation, which we
don't have. Any ideas how to improve the situation? Or is
it fine with everybody? :)
no. it needs to be documented.
this seems to be orthogonal to the actual workflow definition for a
doctype (i.e. how many stages etc.), and i don't see how this could
possibly have implications for the robustness of the repository.
<...>
you are always advocating to handle documents only via a well-defined
api.
Yes, but this is a different point. The storage of the workflow history
is an internal detail. What matters is the semantics:
Should the creation of a document require a workflow transition?
i did not talk about a transition, but a default state. nothing at all
has to change in the way workflow is defined and implemented.
currently, we have this:
* new document is created, no workflow state.
* someone edits it, and the workflow implementation figures, hey,
someone is editing it, let's initiate a state transistion. oh wait,
there is no state yet. must be new. no problem: event:edit, new state is
"authoring".
what i want is this:
* new document is created with default workflow state event:create or
whatchamacallit, and a proper timestamp, user and machine tag.
* someone edits it, and the workflow implementation initiates a state
transistion. the same logic that used to handle the "no state yet" case
now handles the <just created> state. not hard at all, and the change is
strictly local to this one piece of code.
iiuc, this has no implication at all for current workflow declarations
or the way modules handle their workflows. (see below)
IMO no - it should be up to the publication developer.
Should it be the default behaviour? That would be OK with me.
But this is just my current point of view, which is subject to change :)
where is the problem to tell that api to always set a workflow state
(it might even be called "uninitialized", fwiw)
That would be another implicit state.
well, no, that's not fair. it's just another name for the same state i
proposed before. i'm not advocating to add implicit semantics all over
the place. my usual role is to bitch about too much implicit semantics
being already there...
<...>
"event:create" is an event outside of whatever workflow you want to
define.
-1
IMO there shouldn't be "system" events which are not defined by the
workflow schema.
agreed in general (i.e. the system should not generate any more
special events after creation).
but since the creation of a document happens outside of a workflow but
does have implications for the workflow, it seems natural for me that
the document creator should set an initial workflow state. and to keep
this change from affecting the workflow.xml files, i'd suggest to have
an implicit, reserved state such as event:create that does not need
explicit state transitions, but implies the state "authoring".
But the states are configured in the workflow schema, the state
"authoring" is not mandatory ...
no. "authoring" must of course not be hardcoded. the information where
to go from this initial state is already in the workflow configuration:
<state id="authoring" initial="true"/>
^^^^^^^^^^^^^^^^^
modules must define what their initial workflow state is. so control
remains with the module, no SoC violation, and they lived happily ever
after.
or do i misunderstand this?
the reason i want this is to be able to display meta information on
the page ("last modified on <date> by <user>", or even "created by
<user>").
I'd rather handle this separated from the workflow, e.g. using
a "created:" meta data entry.
i could live with that, although doing it all via the workflow state
mechanism seems cleaner and more generic to me, even if it is more
intrusive.
I guess from a user's point of view you are right. From a developer's
point of view (thinking in state machines and keeping orthogonality
in mind) it is rather unclean, unless we find a generic way to express
the creation using the workflow schema.
i hope i can get you to reconsider, or educate me further...
best,
jörn
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
