Am Mittwoch, den 16.07.2008, 15:57 + schrieb Martin Aspeli:
Daniel Nouri [EMAIL PROTECTED] writes:
Robert Niederreiter writes:
Am Mittwoch, den 16.07.2008, 16:24 +0200 schrieb Daniel Nouri:
Where would we need overrides.zcml?
in the case where ICMFAddForm is no longer
Am Mittwoch, den 16.07.2008, 15:24 + schrieb Martin Aspeli:
it's not that big architectual change. everything else discussed is
possible anyway. i would rather call it a feature than a design change
(since the change happens anyway).
I think it's a fairly big shift to assume that the
Charlie Clark wrote:
Am 15.07.2008 um 23:38 schrieb Martin Aspeli:
Actually, that's interesting... what purpose does 'initial view' serve
in a world with add forms?
The same as it ever has - you redirect to the initial view from the
add form because the add form is actually registered for
Am 17.07.2008 um 12:41 schrieb Laurence Rowe:
I'd be interested to hear what you are using this for (other than to
redirect to the default view of the newly created object).
Not a lot if the truth be told apart from the fact that sometimes you
might want to go to the metadata form, other
Am 16.07.2008 um 17:24 schrieb Martin Aspeli:
I think it's a fairly big shift to assume that the FTI has knowledge
of the
schema of the type. It's not necessarily a *bad* idea (at least I
don't think
so, since this is basically how Dexterity works :-), but right now,
FTI doesn't
have any
Am Donnerstag, den 17.07.2008, 13:03 +0200 schrieb Charlie Clark:
Am 16.07.2008 um 17:24 schrieb Martin Aspeli:
I think it's a fairly big shift to assume that the FTI has knowledge
of the
schema of the type. It's not necessarily a *bad* idea (at least I
don't think
so, since this
Am 17.07.2008 um 13:12 schrieb Robert Niederreiter:
class Addform(AddformBase)
fields = form.Fields(ISchema)
and registering it then like:
browser:page
for=*
name=myfactoryname
class=.foo.Addform
allowed_interface=Procucts.CMFCore.browser.interfaces.ICMFAddForm
Am 15.07.2008 um 23:38 schrieb Martin Aspeli:
Actually, that's interesting... what purpose does 'initial view'
serve in a world with add forms?
The same as it ever has - you redirect to the initial view from the
add form because the add form is actually registered for the container
Am Dienstag, den 15.07.2008, 22:34 +0100 schrieb Martin Aspeli:
Daniel Nouri wrote:
Daniel Nouri writes:
Robert Niederreiter writes:
yuppie writes:
I like pretty URLs, and 'foo/+/MyPortalType' looks much prettier than
the URLs needed with my approach:
Hi,
So, let me try to summarise what I think we're saying here:
- My type has a form like:
class MyAddForm(CMFBaseAddForm):
fields = form.Fields(IMyType)
portal_type = 'My type'
- The base form knows to look at self.factory_name to look up the
factory when it does the
yuppie [EMAIL PROTECTED] writes:
class MyAddForm(CMFBaseAddForm):
fields = form.Fields(IMyType)
portal_type = 'My type'
Here you are mixing up content type with portal type. We can't hardcode
the portal type if we want to use the add form for renamed/derived
portal types as
Robert Niederreiter [EMAIL PROTECTED] writes:
+/-
i would provide a default add form anyway. consider how archetypes
works.
Not necessarily an example to follow, though, is it. :)
you never write an addform (especially because there are
none :)). for most of the usecases default sequencial
Martin Aspeli writes:
If we want to be true to the tradition of Zope 3 and its simplified content
types metaphor, then I think we should assume that a type consists of:
- a class
- a schema interface
- an add form/view
- an edit form/view
plus the FTI to install it into the CMF site.
Am Mittwoch, den 16.07.2008, 13:04 + schrieb Martin Aspeli:
Robert Niederreiter [EMAIL PROTECTED] writes:
+/-
i would provide a default add form anyway. consider how archetypes
works.
Not necessarily an example to follow, though, is it. :)
you never write an addform
Robert Niederreiter writes:
2 more properties on the fti (addforminterface, schemainterface), both
are optional, but provide then the discussed and requested flexibility
for different type implementations.
If you copy a FTI, you can probably reuse the add and edit forms
available for the type
Robert Niederreiter writes:
Am Mittwoch, den 16.07.2008, 16:24 +0200 schrieb Daniel Nouri:
Where would we need overrides.zcml?
in the case where ICMFAddForm is no longer my interface to look up. then
i have to overwrite the traverser.
Why would ICMFAddForm no longer be the interface to look
it's not that big architectual change. everything else discussed is
possible anyway. i would rather call it a feature than a design change
(since the change happens anyway).
I think it's a fairly big shift to assume that the FTI has knowledge of the
schema of the type. It's not necessarily a
Previously Martin Aspeli wrote:
it's not that big architectual change. everything else discussed is
possible anyway. i would rather call it a feature than a design change
(since the change happens anyway).
I think it's a fairly big shift to assume that the FTI has knowledge of the
Wichert Akkerman [EMAIL PROTECTED] writes:
Possibly related: I have often had a desire to be able to annotate or
extend the FTI. In Plone (and to a lesser degree CMF) we have lots of
settings that change a portal type's behaviour that are stored in
various places: versioning settings, markup
Daniel Nouri [EMAIL PROTECTED] writes:
Robert Niederreiter writes:
Am Mittwoch, den 16.07.2008, 16:24 +0200 schrieb Daniel Nouri:
Where would we need overrides.zcml?
in the case where ICMFAddForm is no longer my interface to look up. then
i have to overwrite the traverser.
Why
Martin Aspeli writes:
Daniel Nouri [EMAIL PROTECTED] writes:
Robert Niederreiter writes:
Am Mittwoch, den 16.07.2008, 16:24 +0200 schrieb Daniel Nouri:
Where would we need overrides.zcml?
in the case where ICMFAddForm is no longer my interface to look up. then
i have to overwrite
hi martin,
Am Montag, den 14.07.2008, 21:31 +0100 schrieb Martin Aspeli:
Hi Robert,
maybe it's a little late to join this discussion. i read the thread and
want to point some of my thoughts here.
imo its a bad idea to depend on static zcml configuration for factory
types. martin
Hi Robert,
imo its a bad idea to depend on static zcml configuration for factory
types. martin did a nice approach in his portlets engine with a name
traverser when calling a generic adding view.
I'm not quite sure I follow here. The portlets machinery just looks up
the add view in a utility
Am 14.07.2008 um 12:37 schrieb yuppie:
Add links are just special 'actions', they should be integrated with
CMF's action machinery. Based on the information in the type infos
we should be able to create normal IActionInfo objects. (IActionInfo
defines the non-persistent wrapper around
Am 14.07.2008 um 12:17 schrieb yuppie:
CMF 2.1 was released with some formlib based edit forms. I don't
think it was a mistake, because at that time z3c.form wasn't
available in the Zope 2 world.
It certainly wasn't a mistake in fact I think it was great. To me it
seems reasonable at
Hi,
Am Dienstag, den 15.07.2008, 08:53 +0100 schrieb Martin Aspeli:
Hi Robert,
imo its a bad idea to depend on static zcml configuration for factory
types. martin did a nice approach in his portlets engine with a name
traverser when calling a generic adding view.
I'm not quite sure I
Am Dienstag, den 15.07.2008, 12:43 +0200 schrieb yuppie:
Robert Niederreiter wrote:
i took this idea and the
adding mechanism of devilstick works this way as well and depends on the
fti too. so a call of foo/add/portal_type returns an add view for
requested type.
How's that different
Hi Martin!
Martin Aspeli wrote:
CMF trunk uses events instead of _finishConstruction.
Ah, nice. Do you think it'd be feasible to backport this, i.e. copy
the event handler somewhere in Plone so long as Plone's still using
an older version of CMF? Or does the new event handler rely on other
Robert Niederreiter wrote:
Your proposal has some advantages. On the other hand this requires to
create CMF specific code and patterns in a place where a more generic
solution also works.
it does not if you call a formfactory inside the traverser, so it's
hoohable for CMF, Plone or whatever
Robert Niederreiter writes:
Am Dienstag, den 15.07.2008, 12:43 +0200 schrieb yuppie:
Robert Niederreiter wrote:
i took this idea and the
adding mechanism of devilstick works this way as well and depends on
the
fti too. so a call of foo/add/portal_type returns an add view for
Daniel Nouri writes:
Robert Niederreiter writes:
yuppie writes:
I like pretty URLs, and 'foo/+/MyPortalType' looks much prettier than
the URLs needed with my approach:
foo/AddViewName?form.portal_type=MyPortalType
Your proposal has some advantages. On the other hand this requires
yuppie wrote:
Robert Niederreiter wrote:
Your proposal has some advantages. On the other hand this requires to
create CMF specific code and patterns in a place where a more generic
solution also works.
it does not if you call a formfactory inside the traverser, so it's
hoohable for CMF, Plone
Daniel Nouri wrote:
Daniel Nouri writes:
Robert Niederreiter writes:
yuppie writes:
I like pretty URLs, and 'foo/+/MyPortalType' looks much prettier than
the URLs needed with my approach:
foo/AddViewName?form.portal_type=MyPortalType
Your proposal has some advantages. On the other
Charlie Clark wrote:
Am 14.07.2008 um 12:37 schrieb yuppie:
Add links are just special 'actions', they should be integrated with
CMF's action machinery. Based on the information in the type infos
we should be able to create normal IActionInfo objects. (IActionInfo
defines the
Hi,
maybe it's a little late to join this discussion. i read the thread and
want to point some of my thoughts here.
imo its a bad idea to depend on static zcml configuration for factory
types. martin did a nice approach in his portlets engine with a name
traverser when calling a generic adding
Hi!
Martin Aspeli wrote:
Charlie Clark wrote:
Am 13.07.2008 um 20:21 schrieb Martin Aspeli:
Thus, if CMF hasn't yet picked a form library in a release, then you
could try to learn from Plone's mistakes and not jump on a sinking
ship. :)
CMF 2.1 was released with some formlib based edit
Hi Martin!
Martin Aspeli wrote:
# check preconditions
checkObject(container, name, content)
I doubt constraints based on __setitem__ and __parent__ work in Zope 2.
Well, they do in the sense that if you have them and we have this code,
we'll get an exception. They don't
Daniel Nouri wrote:
I just relicensed and moved plone.z3cform to the Zope repository:
http://svn.zope.org/plone.z3cform/trunk/
Great! Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See
Hi Yuppie,
I doubt constraints based on __setitem__ and __parent__ work in Zope 2.
Well, they do in the sense that if you have them and we have this code,
we'll get an exception. They don't work generally, tough, so this may be
YAGNI. It was copied from Five's Adding implementation, so I
Hi Robert,
maybe it's a little late to join this discussion. i read the thread and
want to point some of my thoughts here.
imo its a bad idea to depend on static zcml configuration for factory
types. martin did a nice approach in his portlets engine with a name
traverser when calling a
Hi Yuppie,
Martin Aspeli wrote:
I see that Yuppie has been experimenting with add forms. From what I can
tell, he's using a custom formlib base class and registering views as
e.g. addFile.html. It also look as if he's registering that view as an
action in portal_actions, in the 'folder'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Hi folks,
I see that Yuppie has been experimenting with add forms. From what I can
tell, he's using a custom formlib base class and registering views as
e.g. addFile.html. It also look as if he's registering that view as
Am 13.07.2008 um 14:08 schrieb Martin Aspeli:
Thanks for restarting the discussion and thanks to Yuppie for his
implementation. We've been using it with the changes I outlined the
other week to good effect for the last couple of months.
Bah, I hate these discussions. I'm sure Daniel Nouri
Hi Martin!
Martin Aspeli wrote:
Martin Aspeli wrote:
It's also worth noting that z3c.form (via plone.z3cform, which should
be plain CMF compatible, though you may want a different default
template) has support for such views in quite a generic way. The
CMF version of that looks like this:
Charlie Clark wrote:
This is probably necessary anyway. I'm not sure whether it's right to
try and go straight to z3c.form. My understanding is that there isn't
a great deal of difference between the two libraries so hopefully an
implementation could live with both. I don't think that
Hi Tres,
Putting the policy in the typeinfo objects seems like a much saner place
to keep this stuff than embedding it in a component registry.
+1, at least if we're talking about persistent configuration (which I
guess we are).
Do you have a preference for what shape this should take?
-
Hi Yuppie,
Ok. I added some comments to the 'add' method of plone.z3cform:
Thanks for that!
def add(self, object):
container = aq_inner(self.context)
content = object
name = self.contentName
chooser = INameChooser(container)
#
Am 13.07.2008 um 20:21 schrieb Martin Aspeli:
I doubt that formlib will be replaced by z3c.form. Rather, it just
seems that everyone prefers to work with the latter and so the
former is becoming less relevant.
I wonder who everyone is? When I asked Maartijn Faassen as
Europython he
Charlie Clark wrote:
Am 13.07.2008 um 20:21 schrieb Martin Aspeli:
I doubt that formlib will be replaced by z3c.form. Rather, it just
seems that everyone prefers to work with the latter and so the
former is becoming less relevant.
I wonder who everyone is? When I asked Maartijn Faassen as
Martin Aspeli writes:
Yuppie writes:
but in general that's the way to go. Since z3c.form became the
standard in the Zope 3 world I'd like to see Zope 2 and CMF moving
in the same direction. Unfortunately using plone.z3cform is no
option for CMF because it has a different license and
Daniel Nouri wrote:
Martin Aspeli writes:
Yuppie writes:
but in general that's the way to go. Since z3c.form became the
standard in the Zope 3 world I'd like to see Zope 2 and CMF moving
in the same direction. Unfortunately using plone.z3cform is no
option for CMF because it has a different
Hi Martin!
Martin Aspeli wrote:
I see that Yuppie has been experimenting with add forms. From what I can
tell, he's using a custom formlib base class and registering views as
e.g. addFile.html. It also look as if he's registering that view as an
action in portal_actions, in the 'folder'
52 matches
Mail list logo
