Etria Lists

Raphael Ritz wrote:
> Tim Hicks wrote:
>> Raphael Ritz wrote:
>>
>>> Other than that, I personally would not like yet another configlet to
>>> (re)map workflow states to what the blog should consider public
>>> versus draft etc. I think it is better to honor the existing
>>> settings. Alternatively, one could consider using a custom
>>> (or local to the blog) workflow from the onset.
>> For the purposes of implementing methods like IWeblog.getDrafts(), how 
>> would we distinguish between drafts and published items when a user has, 
>> say, the Manager role?
>>
> 
> Ah, OK, now I think I see the problem. Sorry for not thinking
> about this more carefully before chiming in.
> It seems to be tricky indeed in particular in the context
> of QuillsEnabled.
> 
> Again, just thinking out loud: would it help to consider the
> option of having a BloggingWorkflow in addition to the regular
> workflows - I mean such that objects that are marked as blog
> entries become subject to an additional workflow managing a
> 'blogging_state'. That way it would be possible to combine
> any existing workflow with the blogging workflow and states
> could be managed independently.

Hmm, I don't think I'm so keen on that.  I think it's useful to keep 
Quills' footprint in this area as small as possible - and requiring a 
specific workflow kind of goes against the spirit of QuillsEnabled, imho.

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?

> Just an idea.
> 
> (should anyone be interested in this approach: my LockingWorkflow
> - available from plone.org - works similar and could serve as
> an example of how to do that)
> 
>>> In the long run - by which I mean supporting arbitrary content
>>> as blog posts - I think the only way to avoid confusion will be
>>> to control general access and modification rights in the general
>>> Plone (aka workflow) way and let the assignment of a marker interface
>>> plus appropriate adapter (or whatever the idea is) determine what's
>>> part of the blog.
>> Unless I'm misunderstanding you, that's the way things are for 
>> QuillsEnabled right now - once I get it working again.
>>
> 
> Any specific problem there? - I mean other than lack of time ;-)

Kind of.  I'm slightly struggling to figure out what the appropriate 
interfaces are in the QuillsEnabled world...

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 :).


Tim