Jörn Nettingsmeier schrieb:
[...]
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.
The versions are bound to transitions, not to states. I.e., a
version is only created when a transition is executed.
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.
No, it is in the initial state:
<state id="authoring" initial="true"/>
* 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.
No, it is in the initial state.
must be new. no problem: event:edit, new state is
"authoring".
Yes: authoring (initial state) -> [edit] -> 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.
That would mean a version which is not bound to a transition.
We could introduce that. Maybe it is the least intrusive option.
* someone edits it, and the workflow implementation initiates a state
transistion. the same logic that used to handle the "no state yet" case
Rather the "initial state" 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)
That's true.
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.
OK, I'm sorry :)
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...
:)
I'm glad that somebody raises these issues which everybody else
got used to ...
<...>
"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.
Hmmm, why should modules define their initial workflow state?
But I guess with the option mentioned above (initial version without
transition) this problem doesn't occur.
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...
It looks like the "initial version without transition" option is the
cleanest and least intrusive solution. It doesn't cause any conflicts
and requires just a little tweaking of internal interfaces.
What do the others think?
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
