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
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 trave
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, ma
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 "
> 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 necessaril
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
Am Mittwoch, den 16.07.2008, 16:24 +0200 schrieb Daniel Nouri:
> 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 cop
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 typ
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 addf
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 C
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 sequ
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
> porta
Summary of messages to the cmf-tests list.
Period Tue Jul 15 11:00:00 2008 UTC to Wed Jul 16 11:00:00 2008 UTC.
There were 9 messages: 9 from CMF Tests.
Tests passed OK
---
Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux
From: CMF Tests
Date: Tue Jul 15 21:41:22 EDT 2008
URL: htt
Hi Martin!
The discussion seems to go into the right direction. Just a few notes:
Martin Aspeli wrote:
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'
Here
Am Mittwoch, den 16.07.2008, 11:33 +0200 schrieb Robert Niederreiter:
> 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'
> >
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
Hi,
Having thought about this a bit more ...
I don't really see why you need a traverser *unless* you're trying to
have a single add form implementation that covers multiple types.
i.e. if you have one content type, i.e. a folder, but you want to use
exactly this type with different workflows,
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/+/' looks much prettier than
> the URLs needed with my approach:
>
> >>
18 matches
Mail list logo
