Hi,
Thanks, that's really useful: I'll take a look at those.
snip
- Is this a generally useful thing to do?
Yes, but beware of migration.
I think this is kinda covered - unless you're alluding to a specific,
nasty experience that I am yet to encounter!
Miles
Miles wrote:
[..]
I suppose the slight deviation from BBB is that if someone is using a
custom catalog (for example a day-of-week-to-show flag to provide
random search results), they'll also need to provide some sort of
customisation when objects are fetched by uid to get the same thing to
Hi,
snip
From the standpoint of trying to prevent reinventing wheels all over
the place it sounds like a good idea to re-use a Zope 3 component.
However, beware of backwards-compatibility in terms of software and in
terms of persistent data generated by the existing version. Like Tres
Miles wrote:
Hi,
I was wondering if the CMFUid package could be replaced by a thin
wrapper around zope.app.intids. As (I think) one of the few users of
CMFUid, I'd like to replace it within something a little more robust and
this seemed like a possible way to do it.
Generally, I've found
Am 12.02.2008 um 17:55 schrieb Miles Waller:
Hi,
The subscribers are already wired up for anything IContentish in
CMFUid's event.zcml, provided the uid tools are also in your portal.
I think there are two things going on:
1. The events are only fired when the object is put into place in
Am 12.02.2008 um 17:39 schrieb Charlie Clark:
so the object is not aware of a UID if it has one. Is this wrong way
to create such an object or should I be asking Zope to give me the
UID? If I do depend on Zope to generate a UID for me then how I do
add them to a folder? I can't use
Hi Charlie,
Uids are wired up using the event machinery, so shouldn't need changes
to content classes.
By default, uids are applied for all content with the IContentish
interface so as long as AContentObject provides that interface, it
should get uids. You can see this in event.zcml.
