Note that Plone does this all over the place, and we probably won't change
it for 2.1. 2.1.1 maybe...
Martin
Hi Jens. It clearly says 'parameter' as you have pointed out. Must be
tired, sorry. I'll look for these products and make the changes. Many
thanks.
Regards,
David
On
Trying-not-to-sound-patronizing-ly,
Stefan
Liar. :)
Martin
--
(muted)
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
The general mindset of most Plone developers, as I perceive it from the
CMF side, seems to be one of I'm in Plone code, and I know what to do
here, and I don't need to look beyond my world. Very few developers
have a broader view and even think of pushing generic functionality or
even
Hi all,
First of all, a couple of apologies: for the cross-post, but I think this
concerns all these groups; for my ignorance: I'm only starting to scratch
the surface of Z3, via Five, coming from Plone; and for dragging this out
again. However, I think this is important.; and maybe for
It's a lot looser than knowing the whole DOM. You just need to know
the IDs. And in some cases, only when an id is used in multiple
places, you will need to know the id of its parent. That's the only
mental model you need. You don't need to have any idea what
the tags are or how the page
Hi,
The following checkin on the 1.6 branch, which looks like a pure cleanup
item, completely breaks Plone 2.1 and up on CMF 1.6. I assume that was
not the intention.
http://svn.zope.org/CMF/branches/1.6/CMFCore/TypesTool.py?
rev=40364r1=40360r2=40364
Do you know how it breaks Plone,
That CMFDynamicViewFTI doohickey (no idea what that is, really, but
Plone needs it for some reason) tries to import typeClasses from
CMFCore.TypesTool and add information about itself to it. See fti.py
module.
Ah. :)
CMFDVFTI (say that ten times fast, would'ya) is what powers the
Unless someone fixes that CMFDynamicsomethingFTI thing (or the CMF 1.6
branch) people cannot even attempt to run Plone 2.1 or 2.2 against CMF
1.6. This is like a stalemate. Can you suggest how to add a new kind of
factory information class similar to appending it to that typeClasses
Jens Vagelpohl wrote:
I think this brings up the need for a slightly more formalized planning
and release process. Given the requisite backing by at least the main
developers (meaning their agreement that they would actually use such a
thing) I'd like to set up a release plan page on
On Mon, 09 Jan 2006 14:29:06 -, Rocky Burt
[EMAIL PROTECTED] wrote:
Hi all,
Sorry about the cross post, but I thought this topic concerned CMF,
Plone, and Archetypes equally.
I had a discussion with Alec Mitchell recently where we talked about the
components that made up Archetypes and
On Wed, 11 Jan 2006 18:42:08 -, Tres Seaver
[EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
First, many thanks to all who have contributed toe the CMF 2.0 effort!
I'd like to review the current status of a number of the CMF 2.0 roadmap
items, and ask for feedback
So let's play with the idea of using plone_schemas instead of Archetypes
for a moment. How does it compare? Off the top of my head, how does it
support:
... I really don't know why Opera has taken to posting my messages thre
times (at least it shows up three times here), but there you
On Fri, 13 Jan 2006 20:56:21 -, Rocky Burt
[EMAIL PROTECTED] wrote:
- Ability to make custom views easily
Customizing views happens with overrides.zcml today. No plone_schemas
required. This should work for widget customizations as well.
Obviously as we've all discussed this needs a
Hi Alec,
I see that plone_schemas covers most of what I was asking about, which is
great :)
I took a look at plone_schemas' example type. I can't get it to install
(Zope won't start, some conflict of versions, I'm sure), but looking at
the code, I notice that you
- Derive from
Hi,
On Wed, 11 Jan 2006 18:42:08 -, Tres Seaver
[EMAIL PROTECTED] wrote:
I'd like to review the current status of a number of the CMF 2.0 roadmap
items, and ask for feedback from the community on how they fit into a
near-term release of a beta for CMF 2.0. In fact, I would like to
On Mon, 16 Jan 2006 11:41:23 -, Martijn Faassen [EMAIL PROTECTED]
wrote:
How urgent is it that all of this works with Zope 2.8? I guess it's
urgent if you want to sell it to the Plone community, which will only
switch to Zope 2.9 or beyond by next year or so, I expect. How much more
On Mon, 16 Jan 2006 15:50:44 -, whit [EMAIL PROTECTED] wrote:
In actuality, the number of products that anyone depends on will not be
using this in 2.8, but making it available to 2.8 will give people an
opportunity to use this and familiarize themselves. for example, Plone
will be on
On Mon, 16 Jan 2006 14:37:41 -, Rocky Burt [EMAIL PROTECTED] wrote:
I think there are two reasons Plone 2.5 is targetting CMF 1.6 (instead
of just going to CMF 2.0)
1) the risk that CMF 2.0 wouldn't be ready when plone -- and I'm
pretty sure the 6 month release rule has already been
Hi guys,
I'm writing some migration code that needs to force a workflow state. That
is, a given content item has a workflow with states A, B and C, and
depending on some external state, I need to force it to be in state B,
including having B's security settings.
I've had a look at the
Hi Jens,
On Tue, 24 Jan 2006 19:58:14 -, Jens Vagelpohl
[EMAIL PROTECTED] wrote:
You'll probably have to construct the dictionary that describes the
state/comment/transition time etcyourself and then append it at the end
of the workflow history. At least that's what we've been doing
Hi,
Just trying to get an overview - are there any plans or code (CMF 2?) to
make it possible to use Z3 content types as first-class citizens in CMF?
That is, make them available in add menus, make actions/tabs appear on
them, let them use method aliases, make them catalog aware and so on,
Chris Withers [EMAIL PROTECTED] writes:
Martin Aspeli wrote:
Alec Mitchell's plone_schemas product lets you use such types in Plone,
though he derives from CMF's PortalContent (as I recall) and manually
constructs an FTI.
FWIW, I think this is an exceptionally bad idea.
I'd much
yuppie [EMAIL PROTECTED] writes:
The underlying question is whether we want to drop support for TTW
development. I don't want that. So I prefer to keep portal types and
Actions until we have a suitable Z3 replacement.
In my own opinion, there are three levels of TTW development:
1. TTW
On Wed, 15 Feb 2006 14:16:26 -, Jens Vagelpohl
[EMAIL PROTECTED] wrote:
On 15 Feb 2006, at 14:12, Florent Guillaume wrote:
Jens Vagelpohl wrote:
There's one specific item that I couldn't find enough information on
to make a comment, which is events support. Florent, what is the
On Tue, 28 Feb 2006 23:37:24 -, Bradly Bernier
[EMAIL PROTECTED]
wrote:
So there isnt a way of doing this just with the CMF? I have looked at
plone and it doesn't seem to offer the exact requirments. All I want to
make is a site where my clients can edit the body of 1 or 2 pages and
Bradly Bernier [EMAIL PROTECTED] writes:
Yah Plone seemed to be just as difficult as the CMF when I looked at it.
Plone has way to many options that it scares me which I know would never
work for my very computer illiterate clients.
Well, Plone is built on top of the CMF so it has exactly all
yuppie [EMAIL PROTECTED] writes:
If someone figures out what's necessary to use CPSSkins V3 with
CMFDefault we might be able to add the necessary hooks in CMF.
I have no idea how hard this would be, but I think it would be a very nice thing
to have integrated at the CMF level. There was some
Hi Jens,
Congratulations! :-)
- pluggable TypeInformation objects
- new-style Actions
Where would I look to find more details on how these work? They sound like
the may be useful for Plone going forward. :)
Martin
--
(muted)
___
Hi Jens,
CMF 2.0.0 is now out the door and I have made some updates to the
roadmap document. Please take a look and give me some feedback on the
dates (well, the only dates we have set are the dates for CMF 2.1) and
the description of 2.1:
On Tue, 25 Apr 2006 16:33:01 +0100, David Pratt
[EMAIL PROTECTED] wrote:
Hi Jens. Z3 has it own uid facilities. I guess folks could pick this up
through five could they not? Its all moving in that direction in any
case.
Plone doesn't have UID, but Archetypes does. This is used primarily
On Tue, 25 Apr 2006 20:21:09 +0100, Martin Aspeli
[EMAIL PROTECTED] wrote:
On Tue, 25 Apr 2006 16:33:01 +0100, David Pratt
[EMAIL PROTECTED] wrote:
Hi Jens. Z3 has it own uid facilities. I guess folks could pick this up
through five could they not? Its all moving in that direction in any
On Sat, 03 Jun 2006 12:16:06 +0100, Jens Vagelpohl
[EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This checkin seems to have broken Zope 2.8-compatibility:
http://svn.zope.org/GenericSetup/trunk/tests/common.py?
rev=68391r1=41338r2=68391
Specifically, the line
On Sat, 03 Jun 2006 12:34:53 +0100, Jens Vagelpohl
[EMAIL PROTECTED] wrote:
BTW: Next week I plan to land ZCML support and non-Products package
support for registering profiles. Don't know if new features like that
should be shipped with CMF 1.6 or if we need a maintenance branch for
yuppie wrote:
Since CMF 1.5.1 CMFSetup/GenericSetup supports extension profiles. They
are quite useful, but their current format has some fundamental issues:
I posted something in a similar vein to this on plone-developers last
night, about using GenericSetup profiles for product
yuppie-2 wrote:
GenericSetup uses a completely different approach than
CMFQuickInstaller. It is focused on states, not on changes.
Indeed. From having used it recently, it just seems to be an easier way of
working, so I'm trying to find out how we can meet the use cases that CMFQI
meets
yuppie-2 wrote:
GenericSetup uses a completely different approach than
CMFQuickInstaller. It is focused on states, not on changes.
Indeed. From having used it recently, it just seems to be an easier way of
working, so I'm trying to find out how we can meet the use cases that CMFQI
meets
The concept of import steps is confusing because it was invented before
extension profile support was added. Originally an import step
represented a piece of the profile. The handler property just provided
the information which handler to use for this piece of the profile. That
did no
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 a more traditional
Rob Miller wrote:
maybe i'm missing something, but is there a reason why you wouldn't want
to simply make your profile active and then import specific steps
programmatically from within your install method, rather than invoking
the import adapters manually?
Because in this case I wouldn't
yuppie-2 wrote:
def install(self):
wftool = getToolByName(self, 'portal_workflow')
# create empty workflow
obj_id = 'myWorkflow'
wftool._setObject(obj_id, DCWorkflowDefinition(obj_id))
obj = getattr(wftool, obj_id)
# create import context
environ
yuppie-2 wrote:
If you write a new XML body to adapted.body the settings of the workflow
are changed. The body is not stored as a string, it is stored as object
tree. (So yes, the workflow is 'initialized' with the settings defined
in the XML file.) If you modify the object tree TTW
Hi guys,
yuppie wrote:
Ok. Wrote a prototype for you.
And it worked great! :)
I've used this here now:
http://svn.plone.org/svn/collective/borg/trunk/examples/charity/
See especially
http://svn.plone.org/svn/collective/borg/trunk/examples/charity/Extensions/Install.py
and
Hi guys,
philiKON pointed out something interesting to me the other day - we
could actually register the existing tools as local utilities as of Zope
2.10. That way, you could do this:
actions = getUtility(IActionsTool)
as another spelling for
actions = getToolByName(context,
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10 Sep 2006, at 14:53, Rocky Burt wrote:
This sounds fine, but we'd probably want to wait until we have a CMF
version that does require 2.10, right? HEAD says Zope = 2.9. Unless
we want to work with indirections that know
I am experimenting with that right now, but my z3/Five-Fu ran low
again ;) My problem: calls to zope.component.getUtility
(interface_class) never return anything. Here's the top part (the
bottom is just the old way) of my CMFCore.utils.getToolByName:
Yay!
def
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am I right in thinking that DCWorkflow does not send any Zope 3
events? I'm not terribly familiar with that code, but some grepping
suggests so.
Do you agree this would be useful? (I've got a pretty strong need for
it for
Jens Vagelpohl wrote:
You need to provide full patches and find someone who has the time - I'm
afraid I don't. The best solution would be for you to get in touch with
Jim and get a contributor agreement going. That's not rocket science.
This turned out to be easier than I feared. I've put a
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27 Dec 2006, at 16:16, Tres Seaver wrote:
Rocky Burt wrote:
On Wed, 2006-27-12 at 11:46 +0100, Jens Vagelpohl wrote:
P.S.: I _hate hate hate_ doctests ;)
Why?
I won't speak for Jens, but I find they have two serious
Tres Seaver wrote:
Looks farily good overall. I think one useful extension would be useful
to provide access to the same information currently exposed via
Products.DCWorkflow.Expression.StaTeChangeInfo (these are what the
guard expressions use):
- The workflow object itself.
- The
Tres Seaver wrote:
Looks farily good overall. I think one useful extension would be useful
to provide access to the same information currently exposed via
Products.DCWorkflow.Expression.StaTeChangeInfo (these are what the
guard expressions use):
- The workflow object itself.
- The
Jens Vagelpohl wrote:
The testbrowser tests tend to be the worst when it comes to failures
early on and then spewing out never-ending messages because the browser
ist messed up at that point.
Yes, this is true - they can be pita when you have complex pages (like
Plone).
Martin
Hi Tres,
Looks farily good overall. I think one useful extension would be useful
to provide access to the same information currently exposed via
Products.DCWorkflow.Expression.StaTeChangeInfo (these are what the
guard expressions use):
- The workflow object itself.
- The transition
Sidnei da Silva wrote:
Something that strikes me, by looking at this code is that we also
want events that map to 'notifySuccess' and 'notifyException' too (ie,
ITransitionSuccessEvent and ITransitionFailureEvent), not only
'before'/'after'. (see _invokeWithNotifications).
Those could be fired
Sidnei da Silva wrote:
On 12/27/06, Martin Aspeli [EMAIL PROTECTED] wrote:
I don't think I fully understand the use case or usage of
notifySuccess() and notifyException(). They are called by
portal_workflow, on the workflow definition. They don't seem to be used
in the current code at least
Sidnei da Silva wrote:
On 12/27/06, Martin Aspeli [EMAIL PROTECTED] wrote:
I agree that maybe this refactoring is lower priority, I'm just making
sure it's not forgotten just because the main workflow used is
DCWorkflow, and maybe clarifying some not-so-clear use cases beyond
DCWorkflow's
Sidnei da Silva wrote:
On 12/27/06, Martin Aspeli [EMAIL PROTECTED] wrote:
Right - that was the question I was asking. *Is* this an event that's
useful outside the framework?
I believe so. For example, a subscriber that wants to know if an
action has succeeded, no matter where/when, so it can
Hanno Schlichting wrote:
Yep, you are wrong ;)
Fair enough. Out of curiosity, does the object have a __parent__?
In any case, I think your original suggestion is a good one. Let's take
this opportunity to diagnose the problem and not the symptom: True
tools should be singletons and act
Hanno Schlichting wrote:
PhiliKON some time ago suggested that Five should wrap the utilities
eventually but nobody followed up on that idea.
Philipp also has some ideas (not too far off completion, I believe) that
may remove some of the acquisition intermingling. I'm not sure they'd
apply
Hanno Schlichting wrote:
The idea is to use a specialized persistent component registry, that
does the needed AQ-wrapping.
This will however only give us AQ-wrapped local utilities, whereas those
registered with the global component registry wouldn't be wrapped. I
think this might be an
Okay, spoke to Philipp on IRC and he asked me to relay his opinions on
some of this:
- CMF tools ought not to depend on acquiring things from 'self' if at
all possible.
- TTW code will need aq contexts for security. However, it makes sense
for getToolBy(Interface)Name() to handle this.
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6 Jan 2007, at 23:03, Martin Aspeli wrote:
In light of what we're seeing here, and because there is *so* much
third party code using getToolByName(), perhaps a
DeprecationWarning (and worse, speedy deprecation) is a bit
Hi Jens,
A warning is a warning is a warning, there's no lower level, and
people won't see anything if it isn't in their faces. The usage of
something like a debug error message is unprecedented,
counterintuitive and will not compel anyone to fix their product. We
finally have a
Hanno Schlichting wrote:
Maybe a compromise would be to only return those utilities back
acquisition wrapped that where registered as tools?
That sounds sensible to me; most new local utilities wouldn't really
behave the same way, I'm guessing.
Jens added a new function to CMFCore.utils
Dieter Maurer wrote:
- It's an explicit declaration of support
As is the definition of __of__.
Well, not in a formal sense. I could have some non-Zope python object
that I wanted to register as a local utility (to override a global one,
say) that could have __of__() for some other
Tres Seaver wrote:
Or, to paraphrase the Beatles: All you need is __of__ ... DAH dah,
dadda dum... __of__ is all you need.
LOL! :)
Knock yourselves out, I don't feel as strongly about this as I like a
good argument. ;)
Martin
___
Zope-CMF
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7 Feb 2007, at 00:36, Martin Aspeli wrote:
Eggs make your life easier, especially if you want to use tools
like workingenv.py or zc.buildout.
Well, for simple work with the CMF like setting up a quick instance
Charlie Clark wrote:
Am 07.02.2007 um 00:36 schrieb Martin Aspeli:
Why? Is it the ability to specify sensible version restrictions?
Have multiple versions of the same package as different
dependencies for different dependents? Automatic downloading of
dependencies where possible/desired
Jens Vagelpohl wrote:
I won't grace the uncalled-for sarcasm with an answer. You
misunderstand my point. I simply don't want the existing dead-simple
way of creating quick sandboxes be replaced by some mechanism where I
need to start writing configuration files or learn some
Jens Vagelpohl wrote:
Let's get this discussion back from generic pie-in-the-sky to the
simple situation where we just need this one package integrated into
CMF 2.1, and quickly.
+1
Wichert wants a Plone 3 beta very very soon, there is no time to
switch the CMF to any other
Jens Vagelpohl wrote:
I'm not convinced that anything which is this tightly coupled to Zope
needs to be a package, rather than a product. I don't think the
package zealots get the fact that purity is not a win if we have to
distort the rest of the application to satisfy it.
Amen to that.
I
yuppie-3 wrote:
Jens Vagelpohl wrote:
On 22 Feb 2007, at 09:03, Wichert Akkerman wrote:
Hey Rocky, any progress? Haven't heard and loud yelling from Wichert
yet, but I think he's getting close to the Plone 3.0 beta by now...
I'm hoping for upcoming monday..
Merging the branch into
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23 Feb 2007, at 00:39, Rocky wrote:
So... what's next?
Figuring out how to deal with existing sites that need to be modified
on the fly somehow so they don't break completely.
Does CMF core not have any kind of
Jens Vagelpohl wrote:
After reading Phillip's book I really like Zope 3 generations, but I
have no idea if that mechanism could be used at all.
I had a look at it and started thinking about a CMFish version. The main
challenge is that generates just get the app root as a handle, so you
yuppie wrote:
Hi Rocky!
Rocky wrote:
Done. five.localsitemanager is now included with CMFCore on the jens
branch. There aren't any CMF specific tests in place for any of this,
but the CMFCore tests all run fine with sys.path stuff setup (they
failed when I misconfigured things).
So...
Philipp von Weitershausen wrote:
Rocky wrote:
On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote:
yuppie wrote:
Maybe I'm missing something. But wasn't a major goal of
five.localsitemanager to return acquisition wrapped tools?
That was my understanding, too. I thought this would
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26 Feb 2007, at 17:03, Martin Aspeli wrote:
To get to the portal root / CMF site, I suggest a pattern that is
sometimes used in Zope3: We register the CMF site object as a utility
providing ICMFSite (or whatever
Philipp von Weitershausen wrote:
Martin Aspeli wrote:
Philipp von Weitershausen wrote:
*sigh* Chapter XYZ in my book explains the process :). Whenever you
traverse over a site, its site manager becomes the active component
registry. So if you haven't traversed over that site yet
Kapil Thangavelu wrote:
A few of us (Alec Mitchell, Godefroid Chapelle, Balazs Ree, Rocky Burt,
Daniel Nouri, Rob Miller, Vincenzo Di Somma, and myself) have been
discussing this in depth at the Sorrento Sprint. We've reached consensus
on how we hope to resolve the issues arising from the
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
Hanno Schlichting wrote:
I would say that all of Acquisition is dark implicit magic and something
I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2
I also expect
Balazs Ree wrote:
Acquisition is raping Zope3, it seems.
That must surely be quotation of the month. :)
Martin
___
Zope-CMF maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug
Dieter Maurer wrote:
Alec Mitchell wrote at 2007-4-12 06:59 -0700:
...
... deprecation of getToolByName ...
which is that there's no practical reason other than
aesthetics to deprecate getToolByName at this point.
A very good point: let's deprecate deprecations done just for
aethetical
Rob Miller wrote:
i'll add yet another me too to this chorus. removing getToolByName has
become considerably more trouble than it's worth. currently, i see basically
two options being suggested:
- adding (and then living with) yet more code in Five, which changes the
behaviour of clean,
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Kapil Thangavelu wrote:
On Thu, 12 Apr 2007 06:16:23 -0400, yuppie [EMAIL PROTECTED]
wrote:
Hi!
Philipp von Weitershausen wrote:
yuppie wrote:
Kapil's also right when he says that utilities
Alec Mitchell wrote:
On 4/15/07, Martin Aspeli [EMAIL PROTECTED] wrote:
Dieter Maurer wrote:
Alec Mitchell wrote at 2007-4-12 06:59 -0700:
...
... deprecation of getToolByName ...
which is that there's no practical reason other than
aesthetics to deprecate getToolByName at this point.
A very
Rocky wrote:
On Apr 19, 12:52 pm, Martin Aspeli [EMAIL PROTECTED] wrote:
-1 to relying on five.localsitemanager, especially if it means other site
managers somewhere inside the CMF site will need to be five.lsm aware.
Not sure what relying on five.lsm means... because if we don't use
Tres Seaver wrote:
Before we look at optimizing the use of the product dispatch mechanism,
I'd like to propose deprecating it in favor of the factory-utility
mechanism: leaving the 'product' field blank in an FTI, and having the
'factory' field be the name of a utility registered for
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alexander Limi wrote:
On Wed, 02 May 2007 10:03:39 -0700, Martin Aspeli
[EMAIL PROTECTED] wrote:
+1, but I don't think the two need to be mutually exclusive.
Amen.
At present, Archetypes-based content types cannot be used
Charlie Clark-3 wrote:
Am 03.05.2007 um 00:50 schrieb Alexander Limi:
At present, Archetypes-based content types cannot be used with a
factory (I
tried hard, but there are some acquisition-related/factory related
reasons);
I'd like to refactor this, but we can't for Plone 3.0
Hi Yuppie,
This proposal is now implemented on CMF and five.localsitemanager trunk.
Everything *seems* to work, but maybe I'm missing something. This might
be a good time to review and test the changes - any feedback is welcome.
Well done - great work! :)
Done:
-
There are 10 tools in
yuppie wrote:
Well. The 2.1 changes are based one the assumption that we switch
quickly and completely to utilities, making all tools work as utilities.
The roadmap proposed by Tres means it will take several years and we'll
have to work with tools and utilities side by side for a long time.
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
see if it has any import steps (in import_steps.xml) that are not
already known. If
Hanno Schlichting wrote:
One example where the current behavior makes sense is when you write an
add-on product which wants to install itself into a standard Plone site
and change the settings of the Archetypes tool. The import handler for
the Archetypes tool is only specified in the extension
yuppie-3 wrote:
Hi!
The proposed solution doesn't work:
The ImportStepRegistry is not only used for imports - it is also used
for creating new 'import_steps.xml' files for exports.
Exported profiles are always base profiles, they have to specify *all*
import handlers used for
Tres Seaver wrote:
I think it's wrong :) The export functionality suffers from the same
problen as the import functionality: the export steps defined in
extension profiles are only used if they have been selected once.
In other words: it is just as unpredictable.
What is
yuppie-3 wrote:
For an import operation, you run:
- All steps that came from the current base profile
- All steps that came from explicit, transitive dependencies of the
current
base profile (provided we get support for declaring profile dependencies)
???
Base profiles have
Tres Seaver wrote:
'importVarious' is a brutal hack: better to focus efforts on making it
disappear. The entire point of the tool is to externalize configuration
as declarative data in the profile; accomodating imperative
configuration is not something I care to support.
I think
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andreas Jung is in the process of getting the regular Zope 2 issue
collector moved onto Launchpad. He said the Launchpad guys could move
other collectors like the CMF collector at the same time. The
question is, do we
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
yuppie wrote:
Hi!
Right now there are two versions of CMFCore and GenericSetup:
Products.GenericSetup and GenericSetup
Products.CMFCore and CMFCore
wichert is currently working on GenericSetup/trunk, tseaver stitched
today
Tres Seaver wrote:
Worse, an import is potentially destructive. I am now of the opinion
that content import / export should be treated as a separate
application, not built into the profile.
From a design perspective, I'd tend to agree. I've always felt that the
'structure' import step sat a
Andreas Jung wrote:
--On 28. Februar 2008 20:35:09 +0100 Dieter Maurer [EMAIL PROTECTED]
wrote:
Andreas Jung wrote at 2008-2-28 07:13 +0100:
--On 27. Februar 2008 21:59:58 + Maurits van Rees
[EMAIL PROTECTED] wrote:
greenman, on 2008-02-27:
So, for the catalog.xml importer, why
1 - 100 of 157 matches
Mail list logo
