DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=42994>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42994 ------- Additional Comments From [EMAIL PROTECTED] 2007-07-30 03:40 ------- (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? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
