Bug 42994 - workflow.xml should be moved into the core
Summary: workflow.xml should be moved into the core
Status: NEW
Alias: None
Product: Lenya
Classification: Unclassified
Component: Default Publication (show other bugs)
Version: Trunk
Hardware: Other other
: P2 normal
Target Milestone: 2.0.1
Assignee: Lenya Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-29 17:28 UTC by J
Modified: 2007-11-05 11:29 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description J 2007-07-29 17:28:10 UTC
we have a number of modules and core components that make assumptions about
states and transitions defined in pubs/default/config/workflow/workflow.xml.
there is no way around it, unless we want to really dumb down our GUI.
the workflow file is referenced via fallback:// in the publication.xml file, so
we could easily move the file from the default publication into the core. users
can still override it on a per-publication basis, but imnsho we must provide at
least a skeleton in the core, because core components should not depend on
publication resources.

wdyt?
Comment 1 Andreas Hartmann 2007-07-30 01:49:07 UTC
(In reply to comment #0)
> we have a number of modules and core components that make assumptions about
> states and transitions defined in pubs/default/config/workflow/workflow.xml.

Uh, that's *very* bad. Can you point them out? TIA!

> there is no way around it, unless we want to really dumb down our GUI.
> the workflow file is referenced via fallback:// in the publication.xml file,
> so we could easily move the file from the default publication into the core.

-1, we shouldn't give the impression of a "core" workflow.

Comment 2 J 2007-07-30 03:40:25 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > we have a number of modules and core components that make assumptions about
> > states and transitions defined in pubs/default/config/workflow/workflow.xml.
> 
> Uh, that's *very* bad. Can you point them out? TIA!

the revision usecase, the way i patched it up yesterday. i'm open to suggestions
as to avoiding workflow assumptions, but i don't see them atm. 

and every workflow-related usecase view has very workflow-specific i18n data.

if we wanted to play this by the book, all workflow i18n must go into the
publication, we need to introduce custom state-dependent error messages in
workflow.xml, and all workflow-related menu items *must* be provided by the
publcation. that means a lot of extra boilerplate code for user publications,
because the default publication basically sucks as a template.

i see the benefit of keeping the usecases workflow-agnostic. but at the same
time i see no harm in providing a default workflow in the core - people can
always override it. 
in fact, i think all properties that are frequently treated as "fallback://"
properties should have a very basic version in the core, so that publications
with hardly more than a config file in them still work to some extent.


> > there is no way around it, unless we want to really dumb down our GUI.
> > the workflow file is referenced via fallback:// in the publication.xml file,
> > so we could easily move the file from the default publication into the core.
> 
> -1, we shouldn't give the impression of a "core" workflow.

the other side of the coin is that we now have core functionality that depends
on publication configuration, which to me is worse.

however, i'm convinced now that my revision patch is highly problematic - can we
look at it together, to try circumvent the workflow assumptions?

 

Comment 3 J 2007-08-02 13:07:45 UTC
hmm. another candidate is "Rollback.java". it must assume an "edit" event, as
must the editor usecases.
i'm becoming more convinced that it's an illusion that core usecases can be
totally workflow-agnostic, unless we want to move all that stuff into the
publication, which i think is a very bad idea indeed.

all for reducing assumptions to the minimum, but let's not abstract the child
out of the bath water :)
Comment 4 Andreas Hartmann 2007-08-03 05:04:06 UTC
Maybe we can add a some workflow schema presets to the workflow module?
Comment 5 J 2007-08-03 06:15:37 UTC
(In reply to comment #4)
> Maybe we can add a some workflow schema presets to the workflow module?

hmmm. that means publications would have to place their workflow in
<pub>/lenya/modules/workflow/config...
i'd rather have them in webapp/lenya/config/workflow, so that the current
location does not have to change (i hope that's where fallback:// would look,
but i'd need to check that).
but if you disagree, any other place is fine with me. my main issue is that we
do make assumptions about states and transitions being there, and these should
be provided by the core if a publication does not include its own workflow (and
not just as examples, but as a resource to fallback:// to).

this core workflow should include authoring and live as states and edit, publish
and maybe deactivate as events. i guess this is the minimal subset below which a
cms no longer makes sense. wdyt?
Comment 6 Andreas Hartmann 2007-08-05 04:23:00 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > Maybe we can add a some workflow schema presets to the workflow module?
> 
> hmmm. that means publications would have to place their workflow in
> <pub>/lenya/modules/workflow/config...

No, they are addressed via URLs so they can be everywhere.

> i'd rather have them in webapp/lenya/config/workflow, so that the current
> location does not have to change (i hope that's where fallback:// would look,
> but i'd need to check that).

I don't think we need fallback for workflow schemas, since you typically don't
override a schema, but use a different one (which has a different name).

> but if you disagree, any other place is fine with me. my main issue is that we
> do make assumptions about states and transitions being there, and these should
> be provided by the core if a publication does not include its own workflow (and
> not just as examples, but as a resource to fallback:// to).
> 
> this core workflow should include authoring and live as states and edit, publish
> and maybe deactivate as events. i guess this is the minimal subset below which a
> cms no longer makes sense. wdyt?

Hmm, no idea - what do the others think?
Comment 7 J 2007-08-05 04:50:39 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Maybe we can add a some workflow schema presets to the workflow module?
> > 
> > hmmm. that means publications would have to place their workflow in
> > <pub>/lenya/modules/workflow/config...
> 
> No, they are addressed via URLs so they can be everywhere.
<snip>
> I don't think we need fallback for workflow schemas, since you typically don't
> override a schema, but use a different one (which has a different name).
> 

i'd like to reduce boilerplate code in publications, and to sprinkle some more
"convention over configuration" fairy dust on the publications... hence my wish
to use fallback. but you are right, we could also accomplish this by setting a
default URL that points to a minimal workflow.xml in the core, and it can be
overridden by using the workflow attribute in
publications.xml/resource-types/resource-type.
but the advantage of using fallback:// is that this configuration option is
discoverable for users. everybody will read their publication.xml and find out
they can override the workflow if there is a fallback:// entry. the absence of
an attribute is rather less enlightening :)

> > this core workflow should include authoring and live as states and edit, publish
> > and maybe deactivate as events. i guess this is the minimal subset below which a
> > cms no longer makes sense. wdyt?

bob has a point in that there may not even be a publish transition. but
regardless of that, i'd say we should provide our default publication workflow
in the core, so that all interesting features of Lenya are available without
requiring boilerplate code. users can always replace it with a more minimalistic
one.

Comment 8 J 2007-08-12 14:37:25 UTC
any more thoughts on this issue? i'm prepared to shut up about it for now, *if*
someone speaks up and tells me it's unimportant....
Comment 9 Andreas Hartmann 2007-08-24 04:01:48 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > (In reply to comment #4)
> > > > Maybe we can add a some workflow schema presets to the workflow module?
> > > 
> > > hmmm. that means publications would have to place their workflow in
> > > <pub>/lenya/modules/workflow/config...
> > 
> > No, they are addressed via URLs so they can be everywhere.
> <snip>
> > I don't think we need fallback for workflow schemas, since you typically don't
> > override a schema, but use a different one (which has a different name).
> > 
> 
> i'd like to reduce boilerplate code in publications, and to sprinkle some more
> "convention over configuration" fairy dust on the publications... hence my wish
> to use fallback. but you are right, we could also accomplish this by setting a
> default URL that points to a minimal workflow.xml in the core, and it can be
> overridden by using the workflow attribute in
> publications.xml/resource-types/resource-type.
> but the advantage of using fallback:// is that this configuration option is
> discoverable for users. everybody will read their publication.xml and find out
> they can override the workflow if there is a fallback:// entry. the absence of
> an attribute is rather less enlightening :)

Hmm, I'm afraid I don't see the point ...
If the user reads something like

<resource-type name="xhtml"
workflow="cocoon://modules/workflow/presets/no-staging.xml"/>

I guess she will figure out how to configure her own workflow schema.
Comment 10 J 2007-11-05 11:29:17 UTC
we should revisit this issue after 2.0. there are too many workflow assumptions
all over the place for this to reside exclusively in the default publication.
i think a basic workflow definition belongs in the workflow module, so that
people can create fully-functional publications from scratch without too much
boilerplate code and without having to inherit from the default pub.

(btw, "core" can also mean a module - i wanted to say it should be available
without having to rely on the default publication.)