yuppie wrote:
Rob Miller wrote:
thinking about it now, though, i'd say perhaps the zcml should support only
including a source version, with the setup tool persisting the id of each
upgrade step when it is run. then the UI would show an upgrade step as
needing to be run if a) the loaded
Maurits van Rees wrote:
Hi,
I wonder what the best way is of specifying the source number of a
GenericSetup upgrade step.
---SNIP a bunch of stuff about how using versions to mark GS upgrade steps is
annoying---
yes, as you discovered, using source and destination versions to mark when
yuppie wrote:
Hi!
Tres Seaver wrote:
I would like to get a 1.5 release of GenericSetup out over the holidays.
Here is what I have on the roadmap:
- Clean up the sphinx docs for the package, incorporating / updating
Rob Miller's excellent tutorial on GS (Rob has already blessed the
hi all,
currently, on the 1.4 branch of GenericSetup, there is what i consider to be a
bug in the component registry import code. the issue is that when you re-run
the import step, even if you are not in purge mode, then any utilities that
are registered with the given site manager will be
Rob Miller wrote:
hi all,
i've got a GenericSetup branch called 'ra-depends-tag' with a working
implementation of a genericsetup:upgradeDepends ZCML tag. this tag
can be used anywhere that you could use a genericsetup:upgradeStep tag
(i.e. either standalone, or nested within
hi all,
i've got a GenericSetup branch called 'ra-depends-tag' with a working
implementation of a genericsetup:upgradeDepends ZCML tag. this tag can be
used anywhere that you could use a genericsetup:upgradeStep tag (i.e. either
standalone, or nested within a genericsetup:upgradeSteps). in
Maurits van Rees wrote:
Tres Seaver, on 2008-08-03:
I created satellite versions of the 2.1.1 eggs for the remaining CMF
products this morning:
- CMFDefault
- CMFTopic
- CMFActionIcons
- CMFCalendar
- CMFUid
- DCWorkflow
Source distributions for the 2.1.1 versions are now available
Maurits van Rees wrote:
Rob Miller, on 2008-05-20:
it's maybe worth mentioning here that i _have_ recently started
using GS's upgrade machinery, and have been quite happy with it.
the one thing that i've missed, which i'd like to add to the GS core
if there's no strong objection, is the ability
Tres Seaver wrote:
Maurits van Rees wrote:
Note that for GS upgrade steps you do not really need upgrade
profiles. That was just my understanding/expectation of how to do
upgrade steps at the time.
Sees reasonable, although I should say that I don't use the upgrade
machinery in GS at all.
yuppie wrote:
Hi!
Can we please deprecate the 'version' argument of registerStep?
This is the interface description:
quote
o 'version' is a string for comparing versions, it is preferred to
be a /mm/dd-ii formatted string (date plus two-digit
ordinal). when comparing two
robert rottermann wrote:
Charlie Clark schrieb:
Dear all,
a simple question with hopefully a simple answer! How do I access
objects from an object's context or hierarchy? Specifically I'd like to
be able to access a ZopeDA connection for a site.
I
if you know the id of the object you are
Lennart Regebro wrote:
On 9/25/07, Maurits van Rees [EMAIL PROTECTED] wrote:
When you want to remove an index or column you can do that by editing
the profile and adding remove=True to that index or column. So this
upgrade can be represented as a profile edit. But applying the
profile will
Maurits van Rees wrote:
Hi,
I've been on vacation I took my time answering.
Rob Miller, on 2007-09-06:
okay, here's where things get off track. in GenericSetup, there is no such
thing (yet, perhaps) as an upgrade profile. it's possible to define an
extension profile and to USE it as part
Maurits van Rees wrote:
Hi,
I am having problems understanding how the new upgradeStep
functionality of GenericSetup works. Maybe the most important
question: is there a product that already uses this, so I can look at
its code as an example?
don't think so, except for CPS, from which the
Raphael Ritz wrote:
---SNIP---
And now? What are those add-on authors (e.g. David Convent for
ATBiblioStyles or Mike Gabriel for ATBiblioTopic) supposed to do?
Include the ATExtensions and CMFBib profiles in their products
as well? Leave them out and explain in their README (which those
who
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Hi guys,
After a lot of is-this-a-bug type discussions with Rob and Wichert,
I've come to feel pretty strongly about the following:
When you load an extension profile for the first time in GS, it looks to
Charlie Clark wrote:
Hi,
I making my first stab at browser views for my iCal support having
finally come up with some templates that seem to produce files that work
with most calendar programs.
I have a couple of questions:
1) should I implement them as BrowserViews calling templates or
Maurits van Rees wrote:
Rob Miller, on 2007-06-21:
Wichert Akkerman wrote:
The new GS looks very nice, but from the ZMI UI I can no longer see how
I can import only selected steps of an extension profile. I hope that is
still possible; it can be extremely useful. It looks like the import
Maurits van Rees wrote:
Maurits van Rees, on 2007-06-23:
2. What needs to happen on the import tab now on trunk? We want a
drop down that lists all extension profiles. When I select one of
those extension profiles, should I get a list of only those steps
for which this profile has an
Maurits van Rees wrote:
Rob Miller, on 2007-06-25:
all of the steps for a profile will be loaded into the setup tool
the first time you run any of the steps for that profile. what's
missing is the option of loading all of the steps from a profile
WITHOUT actually running them, so that you
yuppie wrote:
Hi Rob!
Rob Miller wrote:
yuppie wrote:
- Why is it necessary to use version numbers from VERSION.txt? AFAICS
it does not make much sense to keep profile version numbers in sync
with product version numbers. New profiles should have an explicit
version in metadata.xml, old
Wichert Akkerman wrote:
The new GS looks very nice, but from the ZMI UI I can no longer see how
I can import only selected steps of an extension profile. I hope that is
still possible; it can be extremely useful. It looks like the import and
export tab only act on the base profiels now.
hmm...
yuppie wrote:
Rob Miller wrote:
Jens Vagelpohl wrote:
Just merge and I'll take it from there.
done. sorry for the delay.
I still did not manage to look at all the changes, but I have some
questions regarding metadata.xml:
- Why is it necessary to use version numbers from VERSION.txt
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20 Jun 2007, at 06:59, Rob Miller wrote:
Jens Vagelpohl wrote:
Tres reminded me that we should have a real branch and release tags
for GenericSetup to match up with the CMF 2.1-branch and the
releases. I need
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres reminded me that we should have a real branch and release tags
for GenericSetup to match up with the CMF 2.1-branch and the releases. I
need to determine the current state:
Has the BBQ Sprint branch at
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jens Vagelpohl wrote:
Tres reminded me that we should have a real branch and release tags
for GenericSetup to match up with the CMF 2.1-branch and the
releases. I need to determine the current state:
Has the BBQ Sprint branch at
Tres Seaver wrote:
yuppie wrote:
BTW: Are there any unit tests for the upgrade steps feature?
I'll defer to Rob: he was porting the code from the CPS add-on.
okay, i've gotten things to a reasonable place, committed on the
tseaver-bbq_sprint branch. there are tests for the upgrade step
Alec Mitchell wrote:
On 4/11/07, yuppie [EMAIL PROTECTED] wrote:
Hi!
Kapil Thangavelu wrote:
On Tue, 10 Apr 2007 09:09:27 -0400, Jens Vagelpohl
[EMAIL PROTECTED]
wrote:
On 10 Apr 2007, at 10:30, yuppie wrote:
Currently non-five.lsm site managers don't work in CMF, see this
thread:
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
yuppie wrote:
Jens Vagelpohl wrote:
On 5 Apr 2007, at 16:07, Wichert Akkerman wrote:
Previously Tres Seaver wrote:
There may be a better solution in place already on the branch we worked
on at the BBQ Sprint:
Raphael Ritz wrote:
Rob Miller schrieb:
Spanky wrote:
Greetings!
I'm just getting started with GenericSetup, and I feel like I'm
missing something simple. Hope you can help :)
My goal is to get some default content exported as XML so I can use
it as part of the GS profile for my new site
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Just like CMF 1.4, I have now put CMF 1.5 in community maintenance
mode That means the release manager won't make any more releases and
developers don't need to backport fixes, but other community members may
do so if they
Martin Aspeli wrote:
Hi,
I realise this isn't entirely kosher (and that yuppie has much better
long-term ideas), but I am wondering if it's possible to invoke some
GenericSetup handler code during a more traditional Extensions/Install.py
install.
This is purely for convenience - but if I need
i've written a detailed GenericSetup tutorial, available here:
http://plone.org/documentation/tutorial/understanding-and-using-genericsetup-in-plone
it's tailored to a Plone audience, but most of what's there isn't at all
Plone-specific, would probably be valuable to anyone wanting to learn
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
yuppie wrote:
Hi Rob!
Modified: GenericSetup/trunk/PageTemplates/exportimport.py
===
--- GenericSetup/trunk/PageTemplates/exportimport.py2006-05-15
13:59:50
yuppie wrote:
Hi Rob!
hi back!
Rob Miller wrote:
i've been doing a bit of Plone-related hacking around in GenericSetup
recently, and have hit a bit of a snag because the current export
mechanism seems to be pretty tightly married to the idea that a single
object in the ZODB is going
yuppie wrote:
Rob Miller wrote:
Tres Seaver wrote:
yuppie wrote:
--SNIP--
I'm trying to understand that checkin.
I don't think it is generally a good idea to limit exports to specific
meta_types. I just did that in the FolderXMLAdapter to make sure there
is no overlapping with the content
i've been doing a bit of Plone-related hacking around in GenericSetup
recently, and have hit a bit of a snag because the current export mechanism
seems to be pretty tightly married to the idea that a single object in the
ZODB is going to only produce a single file in the exported profile.
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23 Apr 2006, at 21:07, Wichert Akkerman wrote:
On the 1.6 branch you have both in place: the _initIndexes method on
the CatalogTool, but also the GenericSetup-based way of index
creation. So instead of reverting your
when running the unit tests after porting my content import stuff to 2.0
and the trunk, with a week-or-so-old Z2.9 checkout, i get 1 failure and
28 errors. i reverted my changes and verified that the failures were
there already, so i'm still going to commit.
i don't have time to dig in to
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
i've committed this on the 1.6 branch.
Rob, I didn't get any commit message email and a quick look at
svn.zope.org doesn't show any recent changes on the 1.6 branch in the
last 3 weeks?
that's what happens when you try
Rob Miller wrote:
Jens Vagelpohl wrote:
There's a bug filed already: http://www.zope.org/Collectors/CMF/404
I have asked Tres to look at it since he did most of the
content-related stuff but haven't heard from him. If you know a
solution, by all means, go for it.
okay, i've got
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 29 Mar 2006, at 11:09, Rob Miller wrote:
this changes some unit test results, and i need to write another test
or two, but it's time for bed. if this seems a reasonable approach
i'll finish it up and commit the changes
hi all,
i'm picking up a thread from january that sort of petered out...
yuppie wrote:
Tres Seaver wrote:
Florent Guillaume wrote:
Because the current base profile id is not stored, there's no way to
do detect the change to a different base profile. Should I store that
property to allow for
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm working on CMFCalendar and running the tests out of the instance
home like this:
bin/zopectl test -m CMFCalendar -vv
This runs tests, according to the output, but apparently not how or
where I think it should. No .pyc
hi,
i'm trying to use GenericSetup to add tool-like objects to my site at
creation time. i say tool-like because the objects in question (RAM and
HTTP cache managers) act as tools, but they have constructors that require
additional arguments... the current tool.py importer assumes that the
On Wed, 22 Feb 2006 22:05:53 +0100, Olivier Grisel wrote:
Rob Miller a écrit :
hi,
i'm trying to use GenericSetup to add tool-like objects to my site at
creation time. i say tool-like because the objects in question (RAM
and HTTP cache managers) act as tools, but they have constructors
On Fri, 03 Feb 2006 07:04:30 +0100, robert rottermann wrote:
rob,
we German native speakers are used to word our opinions much more directly
that Americans.
I believe for a German speaker there is not a trace of insult in what jens
expressed.
understood. i'm sorry for overreacting. i guess
hi all,
i'm wondering if it's not time to rethink the entire idea of members as
they currently exist in CMF. members were originally a necessary evil,
because the user folder implementation of users didn't allow for enough
flexibility to support CMF's needs. now, however, PAS makes it possible
On Thu, 02 Feb 2006 23:33:49 +, Jens Vagelpohl wrote:
On 2 Feb 2006, at 23:01, Rob Miller wrote:
On Thu, 02 Feb 2006 18:14:15 +, Jens Vagelpohl wrote:
It does sound interesting, unless the user folder all of a sudden gets
overloaded with all kinds of APIs that it doesn't need
On Fri, 03 Feb 2006 00:38:07 +, Jens Vagelpohl wrote:
On 3 Feb 2006, at 00:31, Rob Miller wrote:
I mean sticking Plone-only stuff onto something that's a simple user
folder and should be completely agnostic of how it is used.
oh, i see. did i imply that Plone-only behaviour should
hi all! and great document, florent... thanks!
yuppie wrote:
Tres Seaver wrote:
The use case was that, over time, an import step might be updated. If
you
had installed your site before the update, then your configuration might
also need to be updated.
I first was confused by these
Florent Guillaume wrote:
It seems that an extension profile can't add actions to an action
provide in CMF 1.6. Or, rather, if you do it all previous actions are
erased.
The actions exportimport code has:
def _initProviders(self, node):
...
# delete any actions that
Martin Aspeli wrote:
The broader point is we wouldn't really need it yet - we don't have any
code that actually uses these new features, and plenty of code that may
be broken by changes in CMF 2. All in good time - of course, if you
want to help work on CMF 2.0 compatability for the 2.5
i'm -1 for expending extra effort to get this working on Zope 2.8. new
features should arrive w/ new versions. Plone 2.5 will require CMF-1.6,
which will work w/ both Z2.8 and Z2.9. those who want this feature can
run Plone on Z2.9, no prob.
i'd much rather see us focus our efforts on
Lennart Regebro wrote:
this makes sense. i'm -1 on the final CMFonFive piece landing in CMF
1.6 itself, though. the original scope for CMF 1.6 was CMF 1.5 +
GenericSetup, i don't see a compelling reason to complicate things by
expanding that scope. if CMFonFive stays separate, then you can
Lennart Regebro wrote:
And CMF 1.6 already has more changes that just GenericSetup, some of
which are already causing me other headaches.
which are these? the most significant changes are in the TypesTool, and
this was done in order to achieve more parity btn the 1.6 and 2.0 site
creation
Lennart Regebro wrote:
On 1/4/06, Rob Miller [EMAIL PROTECTED] wrote:
urgh. this isn't ideal for Plone. i'm assuming you've hit some
specific problems w/ getting the current CMFonFive code to support both
2.8 and 2.9? can you provide a little more detail re: the compatibility
issues
Jens Vagelpohl wrote:
On 20 Dec 2005, at 19:53, yuppie wrote:
The intention was to make things consistent. CMF 1.5 and CMF 2.0 have
different ways to register custom type info classes. Before that
change both machineries were broken on the 1.6 branch because they
were merged in an insane
howdy,
in trying to get Plone working against the 1.6 branch i've come across
some problems w/ the way that CMFDefault.File.File is working since the
base classes have been reordered.
the biggest problem has to do w/ the default view lookup. when
OFS.Image.File was the first base class,
Florent Guillaume wrote:
Rob Miller wrote:
- need to readd the PortalGenerator portal creation mechanism for
CMFDefault.Portal, for backwards compatibility
this is done. the unit test is still failing, however. for some
reason, in CMFDefault.tests.test_Portal.CMFSiteTests,
globals
i sent this message about 12 hours ago, via gmane, but i haven't seen it
come through yet, am resending. apologies if it shows up twice.
Florent Guillaume wrote:
Tres Seaver wrote:
Note that the current breakage on the 1.6 branch is the kind of stuff
that made me reluctant to borrow the
Rocky Burt wrote:
I forgot to mention that I'm trying to get started with CMFSetup in CMF
1.5 as my current deployment platform happens to be Plone 2.1.1.
Hopefully most of CMFSetup's (from CMF 1.5) functionality is migratable
into CMF 2.0.
the CMF 1.5 CMFSetup spellings will work on CMF
yuppie wrote:
Hi Rob!
Rob Miller wrote:
yuppie wrote:
2.) Please set svn:keywords Id on new python files.
/me reads svn docs to learn about svn:keywords.
The easiest way to make sure they are set is to modify your svn config.
You might need something like this::
[miscellany
yuppie wrote:
Hi Rob!
Rob Miller wrote:
i managed to get the lion's share of the GenericSetup-based
installation backported to the 1.6 branch tonight. the unit tests
need to be fixed up, and i haven't done anything with the CMFTopic
extension profile yet, but it is possible to add
Florent Guillaume wrote:
Rob Miller wrote:
1.) Please subscribe to the CMF-checkins list. This way your checkins
will show up in that list and additional eyes can see them.
urgh. i have to subscribe? i use gmane to follow all of the lists...
*sigh*
You can subscribe and then change
Raphael Ritz wrote:
Rob Miller wrote:
[..]
to be fair, AT's (un)indexing code is a mess... i tried to change the
BaseFolderMixin manage_(after|before)* methods so they explicitly call
the PortalFolder implementations and was still ending up w/ subobject
orphans left in the catalog after
Jens Vagelpohl wrote:
On 14 Nov 2005, at 22:28, Rob Miller wrote:
okay, i've created a CMF-1.6 branch that has branched everything from
CMF-1.5 with the exception of CMFSetup and GenericSetup, which are
svn:externals from the CMF trunk.
note that i've haven't actually started any
yuppie wrote:
I would not like to do this work on different branches, but if
GenericSetup is a SVN external or if someone else does the merging I'm
fine with creating the 1.6 branch earlier. Anyway I don't think 1.6 can
be released before 2.0.
okay, i've created a CMF-1.6 branch that has
Jens Vagelpohl wrote:
On 12 Nov 2005, at 09:04, yuppie wrote:
A CMF 1.6 release that requires Zope 2.8 and essentially bundles CMF
1.5 with GenericSetup 2.0 (and compatible CMF setup handlers) might
be a good idea.
Yes, that's a good idea. It certainly can't go directly in the
Florent Guillaume wrote:
+1 on branching CMF 1.6 soon, with the goal of:
- dropping support for Zope 2.7
- allowing Five 1.2 events activated to work, even if it doesn't
*require* Five 1.2 events
- be closer to CMF 2.0 w.r.t. setup.
this is perfect for us. there doesn't really need
hi all,
those of us planning out the next Plone releases are in a bit of a bind.
we really want to make use of GenericSetup's newer Z3-interface-based
means of defining import and export handlers, so that we can start work
on rewriting our migration engine to use XML import and export, and
sidnei has written an excellent product called Flon (i.e. Five for
Plone) which provides a user interface for examining the Z3 interfaces
that an object may have, and for assigning marker interfaces to
particular content instances. whit morriss has written a PLIP
Jens Vagelpohl wrote:
On 2 Aug 2005, at 13:27, Florent Guillaume wrote:
Tres Seaver [EMAIL PROTECTED] wrote:
I think the discussion around Archetypes, in particular, ended up
stalled over the question of whether to code generation design
should be preferred over configuration-based design
73 matches
Mail list logo
