[Zope-CMF] RE: Zope-CMF Digest, Vol 2, Issue 22
Norfleet, Sheppard S.
sheppard.norfleet at ngc.com
Thu Sep 25 13:36:25 EDT 2003
Dietur,
Thanks for your help, I think I tracked down the issue.
I did not realize that CMFStaging was overriding an important function
"getHistoryOf" in WorkflowTool, the workflow history is instead being stored
in a workflow repository.
Thanks again for all your help.
Regards,
Sheppard Norfleet
-----Original Message-----
From: zope-cmf-request at zope.org [mailto:zope-cmf-request at zope.org]
Sent: Thursday, September 25, 2003 12:04 PM
To: zope-cmf at zope.org
Subject: Zope-CMF Digest, Vol 2, Issue 22
Send Zope-CMF mailing list submissions to
zope-cmf at zope.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.zope.org/mailman/listinfo/zope-cmf
or, via email, send a message with subject or body 'help' to
zope-cmf-request at zope.org
You can reach the person managing the list at
zope-cmf-owner at zope.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Zope-CMF digest..."
Today's Topics:
1. FW: [Zope-CMF] Replication And Workflows - "Nightmare of CMF
Stre et" (Norfleet, Sheppard S.)
2. Re: Re: DCWorkflow export (Florent Guillaume)
3. Problem adding CMF Topics with quickinstaller
(matt.bartolome at uniontrib.com)
4. RE: Replication And Workflows - "Nightmare of CMF Stre et"
(Norfleet, Sheppard S.)
5. RE: Replication And Workflows - "Nightmare of CMF Stre et"
(Dieter Maurer)
6. Re: Re: Using CMF metadata in ZPT pages - why are thes e two
different? (Chris Withers)
7. MORE PHOTOS FROM MY PHOTOSHOOT-TAKEN BY A PROFESSOR
(seeexoninlineskates55)
8. RE: Replication And Workflows - "Nightmare of CMF Stre et"
(Norfleet, Sheppard S.)
----------------------------------------------------------------------
Message: 1
Date: Wed, 24 Sep 2003 09:05:46 -0700
From: "Norfleet, Sheppard S." <sheppard.norfleet at ngc.com>
Subject: FW: [Zope-CMF] Replication And Workflows - "Nightmare of CMF
Stre et"
To: "'zope-cmf at zope.org'" <zope-cmf at zope.org>
Message-ID:
<D0E2FFEB4052DC47BAE3D2D189A2ADDD01055457 at xcgva046.ngtascsd.it.northgrum.com
>
Content-Type: text/plain; charset="iso-8859-1"
Dieter,
Its actually pretty straightforward, When a user sets an object to be
mirrored: the object, a stagemap, a version repository, and some metadata
about the object are put into a transaction object, which is then pickled
and placed as a BLOB into an ORACLE table which is picked off by an external
replication engine. (This heavy weight approach is only used on initial
mirroring, otherwise lightweight incremental changes are sent [like you care
;) ]).
Anyway, all the zope mirror sites employs a replication product I developed
which is placed in the top level staging directory. When the transaction
arrives, the meta data is analyzed and appropriate action takes place. in
the case of "create" transaction, its a slightly more complex matter which
includes checking to make sure the parent object exists, then a check to
make sure the ID is not already being used. I add the version history to
the version repository, which gives me a new history_id. then I cycle
through the stages using my stagemap, determining which version of the
object goes to what stage. The Review and production stages get versions
out of the version history (if they exist), and the development stage gets
the object out of the transaction object (obviously other bookkeeping takes
place not mentioned). I use the _setObject method on the parent object and
it seems to work fine except the workflow_history attribute keeps
disappearing.
Based on what I am hearing, I am wondering if I should be using the
_setObject method, as it might be messing with it, with some
manage_afterNonsense. I have tried to do just a plain setattr but it doesnt
seem to work, and ideas?
Regards,
Sheppard Norfleet
-----Original Message-----
From: Dieter Maurer [mailto:dieter at handshake.de]
Sent: Wednesday, September 17, 2003 3:45 PM
To: Norfleet, Sheppard S.
Cc: 'zope-cmf at zope.org'
Subject: Re: [Zope-CMF] Replication And Workflows - "Nightmare of CMF
Street"
Norfleet, Sheppard S. wrote at 2003-9-16 12:23 -0700:
> I am having a heck of a time with my application level replication. I am
> able to recreate the object, but apparently the workflow_history
attribute
> does not seem to travel with the object its tied to.
You did not tell us how your "application level replication" works...
The workflow tool maintains the workflow state in an ordinary
attribute ("workflow_history"). It is very unlikely
that it would not travel along with the object.
It might be reset at the the destination. But a breakpoint
(--> debugging) in "CMFCore.WorkflowTool.WorkflowTool.notifyCreated"
to check whether it is called and what does it.
Dieter
------------------------------
Message: 2
Date: Wed, 24 Sep 2003 19:28:29 +0200
From: Florent Guillaume <fg at nuxeo.com>
Subject: Re: [Zope-CMF] Re: DCWorkflow export
To: jtk at yahoo.com
Cc: zope-cmf at zope.org
Message-ID: <20030924172829.GA16524 at dev2.in.nuxeo.com>
Content-Type: text/plain; charset=us-ascii
> I'm not sure if it was my post that you were remembering, but I did a
> hand-written serialization example of DCWorkflow to XML, just to see what
> it would look like. My ambition at the time was to try an SVG workflow
> editor, but I lacked for motivation as built-in SVG support lost momentum
> in mainstream browsers.
>
> Anyhow, the original post was:
> http://mail.zope.org/pipermail/zope-cmf/2001-July/008205.html and the
> sample XML still lives at:
> http://cmf.zope.org/Members/JeffK/dcworkflow.xml/view
Yes thanks, that must be what I had in mind.
I'll study what you did -- from a quick look at it, I'll have to add the
state permission mappings at least.
Florent
--
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87 http://nuxeo.com mailto:fg at nuxeo.com
------------------------------
Message: 3
Date: Wed, 24 Sep 2003 11:12:39 -0700
From: matt.bartolome at uniontrib.com
Subject: [Zope-CMF] Problem adding CMF Topics with quickinstaller
To: zope-cmf at zope.org
Message-ID: <AA7A72A46469D411B8B300508BE329500D37FEF6 at desi2>
Content-Type: text/plain; charset=iso-8859-1
I have an Install.py script in an archetypes product that adds CMF Topics
(using portal_quickinstaller). Everything appears to install correctly
except that the criteria is not being recognized in the topics when viewing
them through the web. The criteria are shown in the topic interface, they
just don't work. When I click "save" in the criteria tab in plone the
criteria are suddenly recognized. Weird.
from Products.Archetypes.public import listTypes
from Products.Archetypes.Extensions.utils import installTypes,
install_subskin
from Products.CMFCore.utils import getToolByName
from Products.Classifieds.config import *
from StringIO import StringIO
def install(self):
out = StringIO()
portalroot = getToolByName(self, 'portal_url').getPortalObject()
for topicid in TOPIC_MAPPINGS.keys():
id = str(topicid[0]) + '-' + str(topicid[1])
try:
portalroot.invokeFactory(id=id,type_name='Topic')
except:
pass
topic_o = portalroot._getOb(id)
topic_o.edit(acquireCriteria=None
, title=TOPIC_MAPPINGS[topicid]
, description=None )
field = 'Section'
criterion_type = 'Integer Criterion'
topic_o.addCriterion(field=field, criterion_type=criterion_type)
criteria_o = topic_o.getCriterion(field)
range = str(topicid[0] - 1) + ' ' + str(topicid[1] + 1)
criteria_o.edit(range,direction='min:max')
for rec in topic_o.listCriteria():
crit = topic_o.getCriterion(rec.id)
command = {}
for attr in crit.editableAttributes():
tmp = getattr(rec, attr, None)
if tmp is None:
tmp = getattr(rec, '%s__%s' % (attr, rec.id), None)
command[attr] = tmp
crit.apply(command)
installTypes(self, out,
listTypes(PROJECTNAME),
PROJECTNAME)
install_subskin(self, out, GLOBALS)
print >> out, "Successfully installed %s." % PROJECTNAME
return out.getvalue()
------------------------------
Message: 4
Date: Wed, 24 Sep 2003 11:51:34 -0700
From: "Norfleet, Sheppard S." <sheppard.norfleet at ngc.com>
Subject: RE: [Zope-CMF] Replication And Workflows - "Nightmare of CMF
Stre et"
To: 'Dieter Maurer' <dieter at handshake.de>
Cc: "'zope-cmf at zope.org'" <zope-cmf at zope.org>
Message-ID:
<D0E2FFEB4052DC47BAE3D2D189A2ADDD01055458 at xcgva046.ngtascsd.it.northgrum.com
>
Content-Type: text/plain; charset="iso-8859-1"
Dietur,
I think _setObject is not the problem after all. I am wondering if the
location of my replication product and the use of physical paths is causing
the problem.
(root/)
staging/
replicator_product
staging_tool
version_tool
lock_tool
versionrepository
Stages/
dev/
site/
review/
site/
prod/
site/
The page templates used in CMF acquire the replication product like
below:
document_edit.py
...
if form.mirror_item and not context.mirrored:
context.replicator.replicateCreate(context)
elif form.mirror_item and context.mirrored:
context.replicator.replicateModify(context)
elif not form.mirror_item and context.mirrored:
context.replicator.replicateRemove(context)
...
In the replication product I store the object as a physical path, which will
be unrestrictedTraversed to later using Moniker's bind (actually done in a
separate thread), from there the object will be replicated.
Well heres the deal, when I get the object originally, replicateCreate(), I
cannot see the workflow_history attribute, and later when I traverse to the
object's path and recover the object in a separate thread,
checkReplicationQueue(), I still cant see the workflow_history attribute;
yet , through the web I can as I changed WorkflowTool to print (to the
console) the workflow_history attribute when it retrieves it.
So now I am sure its not _setObject, but something in the acquisintion
engine is preventing me from accessing the attribute, and the only thing I
can see funny about it is that it uses a PesistantMapping attribute as
opposed to standard dictionary {} attribute.
Thanks so much for anything you can shoot my way.
Regards,
Sheppard
-----Original Message-----
From: Dieter Maurer [mailto:dieter at handshake.de]
Sent: Wednesday, September 17, 2003 1:53 PM
To: Tres Seaver
Cc: Norfleet, Sheppard S.; 'zope-cmf at zope.org'
Subject: Re: [Zope-CMF] Replication And Workflows - "Nightmare of CMF
Street"
Tres Seaver wrote at 2003-9-16 15:47 -0400:
> ...
> In earlier verisons of CMF, the workflow was notified that cloned
> objects had been created via the object's 'manage_afterAdd' method;
> more recent versions correct this to do the notification in
> 'manage_afterClone'. The symptom in those case was that objects would
> "revert" to the private workflow state when copied and pasted between
> folders.
>
> The behavior is apparently still not acceptable for some use cases. See:
>
> - http://collector.zope.org/CMF/176
>
> - http://collector.zope.org/CMF/184
>
> BTW, please don't reply-with-quoting to the entire digest!
In the plone-users mailing list, someone reported that imports
of complete Plone sites reset the workflow state after
he fixed "manage_afterClone" along some suggestion of mine.
I think, my fix to "manage_afterClone/manage_afterAdd/manage_beforeDelete"
should in some form go into the CMF code base:
The motivation: there should be no workflow change, no indexing
and no unindexing when an object is added/removed/cloned
as part of the *complete* CMF site.
This can be easily achieved for workflow notification:
def manage_afterClone(self,item):
workflowTool= getattr(self,'portal_workflow',None)
if workflowTool is not None:
portal= workflowTool.aq_inner.aq_parent
if item.aq_inContextOf(portal) and item != portal:
self.notifyWorkflowCreated()
....
For cataloging, it would be necessary to use CMF site relative
paths rather than physical paths in "portal_catalog"
in order to apply a similar
modification to "manage_afterAdd" and "manage_beforeDelete".
Dieter
------------------------------
Message: 5
Date: Thu, 25 Sep 2003 03:56:06 +0200
From: Dieter Maurer <dieter at handshake.de>
Subject: RE: [Zope-CMF] Replication And Workflows - "Nightmare of CMF
Stre et"
To: "Norfleet, Sheppard S." <sheppard.norfleet at ngc.com>
Cc: "'zope-cmf at zope.org'" <zope-cmf at zope.org>
Message-ID: <16242.19254.803615.39798 at gargle.gargle.HOWL>
Content-Type: text/plain; charset=us-ascii
Norfleet, Sheppard S. wrote at 2003-9-24 11:51 -0700:
> ...
> I think _setObject is not the problem after all. I am wondering if the
> location of my replication product and the use of physical paths is
causing
> the problem.
Very unlikely.
> ...
> In the replication product I store the object as a physical path, which
will
> be unrestrictedTraversed to later using Moniker's bind (actually done in
a
> separate thread), from there the object will be replicated.
>
> Well heres the deal, when I get the object originally, replicateCreate(),
I
> cannot see the workflow_history attribute, and later when I traverse to
the
> object's path and recover the object in a separate thread,
> checkReplicationQueue(), I still cant see the workflow_history attribute;
> yet , through the web I can as I changed WorkflowTool to print (to the
> console) the workflow_history attribute when it retrieves it.
Two ideas:
* I think Shane has a DCWorkflow variant that stores workflow
state outside the object.
Should you by chance use this variant?
* You mention separate threads.
Are you aware that a separate thread can easily read stale
data unless it plays well with the ZODB transaction
machinery?
Invalidation messages (caused by modification of objects)
are only handled at transaction boundaries.
Unless your separate thread commit/aborts the transaction
it is highly likely that it sees stale object state.
> ...
> So now I am sure its not _setObject, but something in the acquisintion
> engine is preventing me from accessing the attribute,
You can be sure this is not the case.
Dieter
------------------------------
Message: 6
Date: Thu, 25 Sep 2003 12:31:43 +0100
From: Chris Withers <chrisw at nipltd.com>
Subject: Re: [Zope-CMF] Re: Using CMF metadata in ZPT pages - why are
thes e two different?
To: Anton Hughes <Anton.Hughes at utas.edu.au>
Cc: zope-cmf at zope.org, "'grendelAI at msn.com'" <grendelAI at msn.com>
Message-ID: <3F72D21F.3040801 at nipltd.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Anton Hughes wrote:
> If I do this:
>
> <span tal:condition="here/Subject">Print this</span>
>
> here/Subject evaluates to nothing so 'Print this' never appears. *However*
> the following
>
> <span tal:replace="here/Subject">
>
> results in this
>
> ('Subject1',)
Are you saying the above happen even if the two <span>'s are next to each
other
in the same news_item_view template?
I find that pretty hard to believe...
Chris
------------------------------
Message: 7
Date: Thu, 25 Sep 2003 14:35:57 -0000
From: "seeexoninlineskates55" <seeexoninlineskates55 at yahoo.com>
Subject: [Zope-CMF] MORE PHOTOS FROM MY PHOTOSHOOT-TAKEN BY A
PROFESSOR
To: Zope-CMF at zope.org
Message-ID: <bkuugd+co1l at eGroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Last week I told you that I had posed for a photography class and then I
posed with some guys girlfriend while he took some photos of us together...
they were very artistic! HOnest. Anyway, I guess he turned them in as a
project and yesterday I got called to come to a photoshoot with his
Photography Professor.
He just sent me a link to the test shots and the and proofs for me to see...
I thought you would like to see how cute he made me look.
www.hotpersonalad.com/landing.asp?afl=TYHO
Just log on and search the photogallery and look for me dressed like a
catholic schoolgirl!!!
------------------------------
Message: 8
Date: Thu, 25 Sep 2003 08:34:00 -0700
From: "Norfleet, Sheppard S." <sheppard.norfleet at ngc.com>
Subject: RE: [Zope-CMF] Replication And Workflows - "Nightmare of CMF
Stre et"
To: 'Dieter Maurer' <dieter at handshake.de>
Cc: "'zope-cmf at zope.org'" <zope-cmf at zope.org>
Message-ID:
<D0E2FFEB4052DC47BAE3D2D189A2ADDD01055459 at xcgva046.ngtascsd.it.northgrum.com
>
Content-Type: text/plain; charset="iso-8859-1"
Dietur,
Thanks for getting back to me so quickly. I humbly submit I am still have a
lot to learn about Zope and CMF.
> * I think Shane has a DCWorkflow variant that stores workflow
> state outside the object.
>
> Should you by chance use this variant?
Yes I do use DCWorkflow, but I previously reviewed the code and my
impression was that it was for the workflow content items, not the workflow
tool, and its the workflow tool that seems to manage the workflow_history
attribute. I see where DCWorkflow makes calls to the WorkflowTool whenever
it needs state/history information. So if my impressions are right how can
it be managing the workflow_history outside of the object? I will look over
the code again...
> * You mention separate threads.
>
> Are you aware that a separate thread can easily read stale
> data unless it plays well with the ZODB transaction
> machinery?
>
> Invalidation messages (caused by modification of objects)
> are only handled at transaction boundaries.
> Unless your separate thread commit/aborts the transaction
> it is highly likely that it sees stale object state.
Yes, I defined a _p_independant function and bracketed transactions with
synchronization locks and have gotten rid of the ZODB conflict errors that
plagued me for a long while. I also refresh the DB connection on each pass
by the replication thread in the hopes that it might combat stale data, but
thats simply the tactics of a novice's mind.
Thanks Again,
Sheppard
-----Original Message-----
From: Dieter Maurer [mailto:dieter at handshake.de]
Sent: Wednesday, September 24, 2003 9:56 PM
To: Norfleet, Sheppard S.
Cc: 'zope-cmf at zope.org'
Subject: RE: [Zope-CMF] Replication And Workflows - "Nightmare of CMF
Stre et"
Norfleet, Sheppard S. wrote at 2003-9-24 11:51 -0700:
> ...
> I think _setObject is not the problem after all. I am wondering if the
> location of my replication product and the use of physical paths is
causing
> the problem.
Very unlikely.
> ...
> In the replication product I store the object as a physical path, which
will
> be unrestrictedTraversed to later using Moniker's bind (actually done in
a
> separate thread), from there the object will be replicated.
>
> Well heres the deal, when I get the object originally, replicateCreate(),
I
> cannot see the workflow_history attribute, and later when I traverse to
the
> object's path and recover the object in a separate thread,
> checkReplicationQueue(), I still cant see the workflow_history attribute;
> yet , through the web I can as I changed WorkflowTool to print (to the
> console) the workflow_history attribute when it retrieves it.
Two ideas:
* I think Shane has a DCWorkflow variant that stores workflow
state outside the object.
Should you by chance use this variant?
* You mention separate threads.
Are you aware that a separate thread can easily read stale
data unless it plays well with the ZODB transaction
machinery?
Invalidation messages (caused by modification of objects)
are only handled at transaction boundaries.
Unless your separate thread commit/aborts the transaction
it is highly likely that it sees stale object state.
> ...
> So now I am sure its not _setObject, but something in the acquisintion
> engine is preventing me from accessing the attribute,
You can be sure this is not the case.
Dieter
------------------------------
_______________________________________________
Zope-CMF maillist - Zope-CMF at zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
http://www.zope.org/Products/PTK/Tracker for bug reports and feature
requests
End of Zope-CMF Digest, Vol 2, Issue 22
***************************************
More information about the Zope-CMF
mailing list