[quills-dev] Fwd: [Quills Issue Tracker] New issue: #127 - does not play nicely with Intranet/Extranet Workflow
Sasha Vincic sasha.vincic at valentinewebsystems.seWed Jan 9 17:23:52 UTC 2008
- Previous message: [quills-dev] Fwd: [Quills Issue Tracker] New issue: #127 - does not play nicely with Intranet/Extranet Workflow
- Next message: [quills-dev] Fwd: [Quills Issue Tracker] New issue: #127 - does not play nicely with Intranet/Extranet Workflow
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 9 jan 2008, at 15.01, Tim Hicks wrote: > > For now, my preferred solution is to add a couple of config options to > the IWeblog settings tab so that admins can define which workflow > states > should be deemed as 'published' and which as 'drafts' - or perhaps > just > the former. That would seem to offer enough flexibility, and keeps > things simple. > > Does that sound reasonable to everybody here? +1 because this is exactly that we want. We do not want to add secondary workflows och special properties to our blog entries. > The problem is that views cannot *only* use the various Quills > interfaces for rendering things. In order to look at all plone-ish, > it > is necessary that the published object is plone-content-ish - e.g. has > an absolute_url. So, I've found a need to have methods like > 'getParentWeblogContentObject' and 'getWeblogEntryContentObject'. My > difficulty is not knowing whether it is more appropriate to have these > as methods on the IWeblog[Entry] interfaces or on the views. Either > way, it feels slightly kludgy :(. > > Any thoughts on this? I'd be happy to explain further if none of the > above makes sense :). Please do :) where do you use those methods? /Sasha
- Previous message: [quills-dev] Fwd: [Quills Issue Tracker] New issue: #127 - does not play nicely with Intranet/Extranet Workflow
- Next message: [quills-dev] Fwd: [Quills Issue Tracker] New issue: #127 - does not play nicely with Intranet/Extranet Workflow
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the quills-dev mailing list