[Plone-developers] Rewrite old cpt forms to new technology like z3cform

37 views
Skip to first unread message

Jean-Michel FRANCOIS

unread,
Mar 12, 2012, 4:37:20 PM3/12/12
to plone-de...@lists.sourceforge.net
Hi,

Before writing a PLIP on this I would like to have your opinion on it. I have forms done with CMFFormController.

I would like to move forms from CMFFormController to formlib or z3cform.

It's very old technology and doesn't play well with ZCA, browser views, ... 

I have already reported a bug that concern every CPT when using linguaplone (navigationroot)  https://dev.plone.org/ticket/12265

Plus we have many forms technologies:
* z3cform + plone.autoform (based on it but still an other one)
* zope.formlib
* CMFFormController

I really would like to get ride of any CMFForm from Plone.

Regards
JeanMichel FRANCOIS


Martin Aspeli

unread,
Mar 12, 2012, 4:42:32 PM3/12/12
to Jean-Michel FRANCOIS, plone-de...@lists.sourceforge.net
On 12 March 2012 20:37, Jean-Michel FRANCOIS <tou...@gmail.com> wrote:
Hi,

Before writing a PLIP on this I would like to have your opinion on it. I have forms done with CMFFormController.

I would like to move forms from CMFFormController to formlib or z3cform.

+1 - long overdue IMHO.

Martin

Eric Steele

unread,
Mar 12, 2012, 4:51:36 PM3/12/12
to Jean-Michel FRANCOIS, plone-de...@lists.sourceforge.net
Oh, please. Yes. This.

Elizabeth Leddy

unread,
Mar 12, 2012, 4:52:32 PM3/12/12
to Jean-Michel FRANCOIS, plone-de...@lists.sourceforge.net
On Mar 12, 2012, at 1:37 PM, Jean-Michel FRANCOIS wrote:

Hi,

Before writing a PLIP on this I would like to have your opinion on it. I have forms done with CMFFormController.

I would like to move forms from CMFFormController to formlib or z3cform.

FWIW, I think z3c is better supported than formlib these days...


It's very old technology and doesn't play well with ZCA, browser views, ... 

I have already reported a bug that concern every CPT when using linguaplone (navigationroot)  https://dev.plone.org/ticket/12265

Plus we have many forms technologies:
* z3cform + plone.autoform (based on it but still an other one)
* zope.formlib
* CMFFormController

I really would like to get ride of any CMFForm from Plone.

Me to! my only concern is that it is still difficult to replicate some of that functionality as a plone developer.  Even though its esoteric at least I know how to make a form in HTML, write a validator, and redirect to a finish page.  If I get shoehorned into using z3c (or gabillions of browser views) for everything I will turn into angry plone developer and smash things.

Liz


Regards
JeanMichel FRANCOIS


------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2_______________________________________________
Plone-developers mailing list
Plone-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plone-developers

Martin Aspeli

unread,
Mar 12, 2012, 4:56:34 PM3/12/12
to Elizabeth Leddy, plone-de...@lists.sourceforge.net
On 12 March 2012 20:52, Elizabeth Leddy <elizabe...@gmail.com> wrote:


On Mar 12, 2012, at 1:37 PM, Jean-Michel FRANCOIS wrote:

Hi,

Before writing a PLIP on this I would like to have your opinion on it. I have forms done with CMFFormController.

I would like to move forms from CMFFormController to formlib or z3cform.

FWIW, I think z3c is better supported than formlib these days...


It's very old technology and doesn't play well with ZCA, browser views, ... 

I have already reported a bug that concern every CPT when using linguaplone (navigationroot)  https://dev.plone.org/ticket/12265

Plus we have many forms technologies:
* z3cform + plone.autoform (based on it but still an other one)
* zope.formlib
* CMFFormController

I really would like to get ride of any CMFForm from Plone.

Me to! my only concern is that it is still difficult to replicate some of that functionality as a plone developer.  Even though its esoteric at least I know how to make a form in HTML, write a validator, and redirect to a finish page.  If I get shoehorned into using z3c (or gabillions of browser views) for everything I will turn into angry plone developer and smash things.

More than anything, I think we just need more/better examples of 'good' z3c.form practice. It doesn't have to be hard. I imagine many of the CMFFormController views will be replaced with z3c.form forms with custom .pt templates, for example, which is something a lot of people don't know how to do.

Martin 

David Glick (GW)

unread,
Mar 12, 2012, 5:03:12 PM3/12/12
to Elizabeth Leddy, plone-de...@lists.sourceforge.net

On Mar 12, 2012, at 1:52 PM, Elizabeth Leddy wrote:



On Mar 12, 2012, at 1:37 PM, Jean-Michel FRANCOIS wrote:

Hi,

Before writing a PLIP on this I would like to have your opinion on it. I have forms done with CMFFormController.

I would like to move forms from CMFFormController to formlib or z3cform.

FWIW, I think z3c is better supported than formlib these days...


It's very old technology and doesn't play well with ZCA, browser views, ... 

I have already reported a bug that concern every CPT when using linguaplone (navigationroot)  https://dev.plone.org/ticket/12265

Plus we have many forms technologies:
* z3cform + plone.autoform (based on it but still an other one)
* zope.formlib
* CMFFormController

I really would like to get ride of any CMFForm from Plone.

Me to! my only concern is that it is still difficult to replicate some of that functionality as a plone developer.  Even though its esoteric at least I know how to make a form in HTML, write a validator, and redirect to a finish page.  If I get shoehorned into using z3c (or gabillions of browser views) for everything I will turn into angry plone developer and smash things.


There are a couple directions we could go for modernizing our CMFFormController forms.

One is quite simple: move the logic of the form's scripts into the __call__ method of a BrowserView, and move the form's template to be the template of that view.

A much bigger project would be to rewrite all the forms to be schema-based. I don't think we should do that unless there's a clear benefit, which I'm not sure there is. (There would be benefits, like making it possible to have a standard way of extending all forms in Plone. But they'd be offset by the tradeoffs of making these forms less hackable and the usual risks associated with bugs introduced during refactoring.)

David

 

David Glick
Web Developer
david...@groundwire.org
206.286.1235x32

The NPO Engagement Party 2012. So much more fun than the wedding reception.


Eric Steele

unread,
Mar 12, 2012, 5:29:36 PM3/12/12
to Jean-Michel FRANCOIS, plone-de...@lists.sourceforge.net
Also, I'll point out https://dev.plone.org/ticket/10359 which was closed for lack of Hanno. It can certainly be reopened and picked up again.


Elizabeth Leddy

unread,
Mar 12, 2012, 5:33:34 PM3/12/12
to Martin Aspeli, plone-developers@lists. sourceforge. net developers, Tom Kapanka
This is the real problem, yes. I will make sure to bring this up at the cioppino sprint. A general "how to make real world forms in plone" section with the preferred easy options detailed would be awesome. 

Liz



Martin 

Roberto Allende

unread,
Mar 12, 2012, 11:22:47 PM3/12/12
to plone-de...@lists.sourceforge.net
El 12/03/12 17:37, Jean-Michel FRANCOIS escribió:

> Hi,
>
> Before writing a PLIP on this I would like to have your opinion on it. I
> have forms done with CMFFormController.
>
> I would like to move forms from CMFFormController to formlib or z3cform.
>

Hello

I'm looking ideas for a GSoC project and thanks to Jon Stahl, who
suggested me to read Plone's roadmap, I found one titled: "R12
Standardise on z3c.form for all generated forms", which seems to include
what you're suggesting.

Quoting roadmap:

*R12 Standardise on z3c.form for all generated forms*

*Rationale*
Forms in Plone currently use a mixture of CMFFormController,
zope.formlib and z3c.form. The latter is most modern and forms the basis
for Dexterity and tiles.

*Description*
Rewrite existing forms in Plone core using CMFFormController and
zope.formlib to use z3c.form and deprecate the other libraries.

*Status*
Some work has been done by various contributors, but needs a champion
and a PLIP.

----

I was studying it futher, in fact i was making a list with all the forms
in Plone, but since this subject came up on the list I thought it was
better to share it.

So, I'd like to ask some questions:

1. May I join to the task and would it make sense to think a GSoC
project still ?

2. Any suggestion about defining scope of it ?. If we could have this
conversation in "real world" I would ask to do a brainstorming because
there are a lot of knowledge about this subject.

Any questions, comments or suggestions are very welcome!

Kind Regards
Roberto Allende

--
http://robertoallende.com
http://menttes.com

--
http://menttes.com

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!


The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!

http://p.sf.net/sfu/learndevnow-d2d

Malthe Borch

unread,
Mar 13, 2012, 1:30:53 AM3/13/12
to Roberto Allende, plone-de...@lists.sourceforge.net
On 13 March 2012 04:22, Roberto Allende <ro...@menttes.com> wrote:
> 1. May I join to the task and would it make sense to think a GSoC
> project still ?

It's a bit broad in scope and difficult in execution – perhaps we
could limit it to the login sequence and associated functionality:

- log in
- log out
- forget and reset password
- change e-mail

In an ideal situation, the last two involve sending out an e-mail with
a time-limited token, then on the way in present the user with a form
to complete the action.

For an alternative scope, there's also the forms in "/skins/plone_forms".

\malthe

Yuri

unread,
Mar 13, 2012, 3:25:27 AM3/13/12
to plone-de...@lists.sourceforge.net
Il 12/03/2012 21:52, Elizabeth Leddy ha scritto:
>> I really would like to get ride of any CMFForm from Plone.
>
> Me to! my only concern is that it is still difficult to replicate some
> of that functionality as a plone developer. Even though its esoteric
> at least I know how to make a form in HTML, write a validator, and
> redirect to a finish page. If I get shoehorned into using z3c (or
> gabillions of browser views) for everything I will turn into angry
> plone developer and smash things.
>
> Liz
>
>

+1

Or, at least, make form easy.

BTW, Archetype edit is all based on CMFFormController, how would you get
rid of it? :)

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!

The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!

http://p.sf.net/sfu/learndevnow-d2d

Luca Fabbri

unread,
Mar 13, 2012, 4:30:32 AM3/13/12
to Yuri, plone-de...@lists.sourceforge.net
On Tue, Mar 13, 2012 at 8:25 AM, Yuri <yu...@alfa.it> wrote:
> Il 12/03/2012 21:52, Elizabeth Leddy ha scritto:
>>> I really would like to get ride of any CMFForm from Plone.
>>
>> Me to! my only concern is that it is still difficult to replicate some
>> of that functionality as a plone developer.  Even though its esoteric
>> at least I know how to make a form in HTML, write a validator, and
>> redirect to a finish page.  If I get shoehorned into using z3c (or
>> gabillions of browser views) for everything I will turn into angry
>> plone developer and smash things.
>>
>> Liz
>>
>>
>
> +1
>
> Or, at least, make form easy.
>
> BTW, Archetype edit is all based on CMFFormController, how would you get
> rid of it? :)
>

You get the point Yuri, this is the same fear I have... I think this
will be difficult until Archetypes will not be anymore the main
framework.

For all other element I think can be simpler


--
-- luca

twitter: http://twitter.com/keul
linkedin: http://linkedin.com/in/lucafbb
blog: http://blog.keul.it/

Jean-Michel FRANCOIS

unread,
Mar 13, 2012, 5:38:34 AM3/13/12
to Yuri, plone-de...@lists.sourceforge.net
I don't want to get ride of Archetypes if this is the question :)

But I don't want to have any forms done with CMFFormController in Plone.

Archetypes is a framework that depends on CFC and it works. This is not the case with reset password and some others. 

Regards
JeanMichel FRANCOIS


Jens W. Klein

unread,
Mar 13, 2012, 5:50:35 AM3/13/12
to plone-de...@lists.sourceforge.net
On 12.03.2012 22:03, David Glick (GW) wrote:
> [...]

> One is quite simple: move the logic of the form's scripts into the
> __call__ method of a BrowserView, and move the form's template to be the
> template of that view.

A big +1 for this approach. As some of you may know I hate z3cforms
because of its unnecessary complexity (even if I may be almost alone
with this opinion in the Plone universe).

> [...]

Jens
--
Klein & Partner KG, member of BlueDynamics Alliance


------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!

The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!

http://p.sf.net/sfu/learndevnow-d2d

Jean-Michel FRANCOIS

unread,
Mar 13, 2012, 6:07:03 AM3/13/12
to David Glick (GW), plone-de...@lists.sourceforge.net


 
There are a couple directions we could go for modernizing our CMFFormController forms.

One is quite simple: move the logic of the form's scripts into the __call__ method of a BrowserView, and move the form's template to be the template of that view.


I have already try this and it doesn't solve anything except adding complexity. In my case reset password will not work after that change. I already have tried this way and having more trouble than solutions:  you have to keep the cpt file validators, ... only the action can be moved to real python, but the vpy and cpy must be their. Performance will not be better, ...

-1 for this way.
 
 
A much bigger project would be to rewrite all the forms to be schema-based. I don't think we should do that unless there's a clear benefit, which I'm not sure there is. (There would be benefits, like making it possible to have a standard way of extending all forms in Plone. But they'd be offset by the tradeoffs of making these forms less hackable and the usual risks associated with bugs introduced during refactoring.)


Being schema based can be hard. Some forms depends on Plone configuration. In that case what is the best way ? Having a global schema and display/hide some fields according to the configuration ? or having many schema/forms and choosing the good one ?

Yuri

unread,
Mar 13, 2012, 6:16:00 AM3/13/12
to plone-de...@lists.sourceforge.net
Il 13/03/2012 11:07, Jean-Michel FRANCOIS ha scritto:
>
>
> There are a couple directions we could go for modernizing our
> CMFFormController forms.
>
> One is quite simple: move the logic of the form's scripts into the
> __call__ method of a BrowserView, and move the form's template to
> be the template of that view.
>
>
> I have already try this and it doesn't solve anything except adding
> complexity. In my case reset password will not work after that change.
> I already have tried this way and having more trouble than solutions:
> you have to keep the cpt file validators, ... only the action can be
> moved to real python, but the vpy and cpy must be their. Performance
> will not be better, ...

I think we should add support for browser view in CMFFormController.
CMFFormController can be very powerful as a tool, I would keep and
improve it.

About performance, nobody knows where (if?) the problem came from...

>
> -1 for this way.
>
> A much bigger project would be to rewrite all the forms to be
> schema-based. I don't think we should do that unless there's a
> clear benefit, which I'm not sure there is. (There would be
> benefits, like making it possible to have a standard way of
> extending all forms in Plone. But they'd be offset by the
> tradeoffs of making these forms less hackable and the usual risks
> associated with bugs introduced during refactoring.)
>
>
> Being schema based can be hard. Some forms depends on Plone
> configuration. In that case what is the best way ? Having a global
> schema and display/hide some fields according to the configuration ?
> or having many schema/forms and choosing the good one ?
>
>

> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!

> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!

> http://p.sf.net/sfu/learndevnow-d2d


>
>
> _______________________________________________
> Plone-developers mailing list
> Plone-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plone-developers

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!

The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!

http://p.sf.net/sfu/learndevnow-d2d

Wichert Akkerman

unread,
Mar 13, 2012, 6:52:15 AM3/13/12
to Jean-Michel FRANCOIS, plone-de...@lists.sourceforge.net
On 03/13/2012 11:07 AM, Jean-Michel FRANCOIS wrote:
A much bigger project would be to rewrite all the forms to be schema-based. I don't think we should do that unless there's a clear benefit, which I'm not sure there is. (There would be benefits, like making it possible to have a standard way of extending all forms in Plone. But they'd be offset by the tradeoffs of making these forms less hackable and the usual risks associated with bugs introduced during refactoring.)


Being schema based can be hard. Some forms depends on Plone configuration. In that case what is the best way ? Having a global schema and display/hide some fields according to the configuration ? or having many schema/forms and choosing the good one ?

It isn't about schemas. z3c.form has problems with a) far too many abstractions for any normal use case, b) no useful documentation. That makes it an typical example of the Zope software stack I suppose.. Recent form libraries such as WTForms, deform (to a lesser degree imho) and flatland (unfortunately no longer actively maintained) are all much more pleasant to use. You can use them within a Zope context as well.

Wichert.



Johannes Raggam

unread,
Mar 13, 2012, 7:06:10 AM3/13/12
to plone dev
On Tue, 2012-03-13 at 10:50 +0100, Jens W. Klein wrote:
> On 12.03.2012 22:03, David Glick (GW) wrote:
> > [...]
> > One is quite simple: move the logic of the form's scripts into the
> > __call__ method of a BrowserView, and move the form's template to be the
> > template of that view.
>
> A big +1 for this approach. As some of you may know I hate z3cforms
> because of its unnecessary complexity (even if I may be almost alone
> with this opinion in the Plone universe).

+1

z3cforms are a good example how to over-componentize code with the
result of good flexibility (if you exactly know where to hook something
in and are willing to write tons of code) and little flexibility (if you
don't find such a point to hook in) at the same time. i see the power of
z3cforms, but it's much too complicated and verbose for my taste. we
should start to avoid it - there are better solutions out there.

johannes

>
> > [...]
>
> Jens


--
programmatic web development
di(fh) johannes raggam / thet
python plone zope development
mail: off...@programmatic.pro
web: http://programmatic.pro
http://bluedynamics.com

signature.asc

Malthe Borch

unread,
Mar 13, 2012, 7:10:39 AM3/13/12
to Wichert Akkerman, plone-de...@lists.sourceforge.net
On 13 March 2012 11:52, Wichert Akkerman <wic...@wiggy.net> wrote:
> It isn't about schemas. z3c.form has problems with a) far too many
> abstractions for any normal use case, b) no useful documentation. That makes
> it an typical example of the Zope software stack I suppose.. Recent form
> libraries such as WTForms, deform (to a lesser degree imho) and flatland
> (unfortunately no longer actively maintained) are all much more pleasant to
> use. You can use them within a Zope context as well.

I agree with this.

It's hard to get it right with z3c.form. You quickly end up with > 100
lines for a non-trivial form – and if you care about your users, most
forms end up being non-trivial.

The solution might be to contribute to the z3c.form project itself –
with better and more expressive base classes, better widgets and more
flexible default patterns (i.e. "do what I probably mean"). It might
still simply be too complex for the typical Plone-developer.

I wrote a small form library a few years ago – and I'm going to link
to it here because it illustrates quite well how simple it can be:

http://pypi.python.org/pypi/repoze.formapi

There's a formatted introduction to the library on that page.

I don't think there's been much take-up of this particular library,
but there's definitely ideas in there that are sound, i.e.

- Simple is good
- Less is more
- It has to be fun
- HTML isn't an enemy

Chris McDonough has a different take on it in Colander:

http://pypi.python.org/pypi/colander

It's a lot like Zope's schema. The serialization logic is a little
daunting. It works well in practice, but it also breaks easily if you
try to do something that wasn't intended from the beginning (and this
is a very real scenario).

Note that Deform (mentioned by Wichert) uses Colander for
schema-support. It's a nice layered approach I think.

\malthe

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!

The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!

http://p.sf.net/sfu/learndevnow-d2d

Johannes Raggam

unread,
Mar 13, 2012, 7:25:04 AM3/13/12
to plone-de...@lists.sourceforge.net


let's add to this list:

http://pypi.python.org/pypi/yafowil

it's storage and framework independent, schema less, light weight easy
and flexible.

more: http://packages.python.org/yafowil/

,johannes

signature.asc

Laurence Rowe

unread,
Mar 13, 2012, 7:26:12 AM3/13/12
to Malthe Borch, plone-de...@lists.sourceforge.net, Wichert Akkerman
On 13 March 2012 11:10, Malthe Borch <mbo...@gmail.com> wrote:
> On 13 March 2012 11:52, Wichert Akkerman <wic...@wiggy.net> wrote:
>> It isn't about schemas. z3c.form has problems with a) far too many
>> abstractions for any normal use case, b) no useful documentation. That makes
>> it an typical example of the Zope software stack I suppose.. Recent form
>> libraries such as WTForms, deform (to a lesser degree imho) and flatland
>> (unfortunately no longer actively maintained) are all much more pleasant to
>> use. You can use them within a Zope context as well.
>
> I agree with this.
>
> It's hard to get it right with z3c.form. You quickly end up with > 100
> lines for a non-trivial form – and if you care about your users, most
> forms end up being non-trivial.
>
> The solution might be to contribute to the z3c.form project itself –
> with better and more expressive base classes, better widgets and more
> flexible default patterns (i.e. "do what I probably mean"). It might
> still simply be too complex for the typical Plone-developer.

While I agree that z3c.form has its problems, it is currently the best
choice for schema based forms in Plone. Switching form libraries would
involve a very large amount of effort in rewriting widgets to work
with the new system. I'd certainly encourage people to experiment with
integrating some of the newer form libraries with Plone and report
back on their experiences and create examples. Lets at least get rid
of formlib first!

But lets not detract from the very real benefits of getting rid of the
existing skin template/script based forms. Where those forms are
schema based or can easily be made so, then z3c.form is a good option
- it will be widely used in Plone for a long time yet, especially with
the adoption of dexterity.

Laurence

Davide Moro

unread,
Mar 13, 2012, 7:14:11 AM3/13/12
to plone-de...@lists.sourceforge.net
Il 13/03/2012 10:50, Jens W. Klein ha scritto:
> On 12.03.2012 22:03, David Glick (GW) wrote:
>> [...]
>> One is quite simple: move the logic of the form's scripts into the
>> __call__ method of a BrowserView, and move the form's template to be the
>> template of that view.
> A big +1 for this approach. As some of you may know I hate z3cforms
> because of its unnecessary complexity (even if I may be almost alone
> with this opinion in the Plone universe).

We should consider the complexity factor in such decisions: z3cform or
not z3cform it is not important, but in both cases I think we should
give to normal people a simple way to override simple things like simple
customizations.

For normal people I mean integrators, software selection guys, people
that knows a bit of zmi and zpt after a couple of days of training with
html/sql/basic programming skills.

For example I don't like what happened to
plone/app/users/browser/personalpreferences.py because now you should be
a Plone engineer in order to make some simple changes to registration or
preference form (instead a simple and well working cpt we have a formlib
mixed with old vpy validator if I remember well, every customization
costs a lot of unnecessary work).

Anyway, the risk is: if someone needs to make a simple customization in
order to evaluate Plone and he feels things too hard (translated: 2
hours or more of an expert Plone consultant just for customize a sendto
form), he may consider Plone too difficult to customize and abandomn it.

So the reponse could be: no more formlib and no changes just for moving
to newer technologies without keeping in mind these side effects

PS: I am a happy z3cform user.

Regards,

davide


--
Davide Moro
Technical Development Manager
http://linkedin.com/in/davidemoro82

Redomino Srl
http://redomino.com
HQ Largo Valgioie 14, Turin IT
Phone +39 0117499875

Jean-Michel FRANCOIS

unread,
Mar 13, 2012, 9:09:11 AM3/13/12
to plone-de...@lists.sourceforge.net
Quite a lot of people seems against z3cform because it's complex (yes it is, just look at s&d forms)

We have plone.autoform for simple schema based forms. It's great and used. I more often use this one than z3cform itself.

What we need is documentation here. Simple examples of custom forms done with z3cform but without custom widgets, or huge adapters.

Davide Moro

unread,
Mar 13, 2012, 10:18:25 AM3/13/12
to plone-de...@lists.sourceforge.net
Il 13/03/2012 14:09, Jean-Michel FRANCOIS ha scritto:
> Quite a lot of people seems against z3cform because it's complex (yes
> it is, just look at s&d forms)
>
> We have plone.autoform for simple schema based forms. It's great and
> used. I more often use this one than z3cform itself.
>
> What we need is documentation here. Simple examples of custom forms
> done with z3cform but without custom widgets, or huge adapters.

I am not against z3cform, I'm just telling that different use cases may
require different approaches depending on what you are going to build.

A better documentation would be great for developers but it doesn't
solve the problem because I'm discussing about a different target:
normal integrators that want to perform little customizations quickly
without having to write a whole plugin for a small change or became a
Plone expert for changing a sendto form.

We should build flexible, solid, easy to extend applications but also
provide some hooks for normal integrators, possibily TTW.

Nathan Van Gheem

unread,
Mar 13, 2012, 10:33:16 AM3/13/12
to Davide Moro, plone-de...@lists.sourceforge.net

I agree with this to an extent. We end up removing a lot of
functionality if we convert these to z3cforms as normal integrators
won't easily be able to edit any of these forms anymore.

However, I don't know how we are going to move plone forward if we
just indefinitely keep them around.

Perhaps we need the equivalent of portal_view_customizations for
z3cforms so users will still be able to easily customize things before
we can do this.


-Nathan

Jean-Michel FRANCOIS

unread,
Mar 13, 2012, 10:33:33 AM3/13/12
to Davide Moro, plone-de...@lists.sourceforge.net
I understand and I don't see an issue. It is possible to write a small customization. The macro provided by plone.z3cform show there are slots you can use before the form, before widgets, after widgets, after the form:

I have used this to include an authenticator in a z3cform.

What do you mean by plugin ? egg/addon ? 

For easy use case like send form I'm don't want to code, I'm using PFG ^^.

Regards
JeanMichel FRANCOIS




Davide Moro

unread,
Mar 13, 2012, 10:57:37 AM3/13/12
to Jean-Michel FRANCOIS, plone-de...@lists.sourceforge.net
Il 13/03/2012 15:33, Jean-Michel FRANCOIS ha scritto:
> I understand and I don't see an issue. It is possible to write a small
> customization. The macro provided by plone.z3cform show there are
> slots you can use before the form, before widgets, after widgets,
> after the form:
> http://svn.zope.org/plone.z3cform/trunk/plone/z3cform/templates/macros.pt?rev=124036&view=markup
> <http://svn.zope.org/plone.z3cform/trunk/plone/z3cform/templates/macros.pt?rev=124036&view=markup>

No, I mean that it should be great providing something similar to a
robust and working portal_view_customizations.

Best regards,

Robert Niederreiter

unread,
Mar 13, 2012, 12:34:15 PM3/13/12
to Laurence Rowe, plone-de...@lists.sourceforge.net, Wichert Akkerman
Hi,

On 13.03.2012 12:26, Laurence Rowe wrote:
> While I agree that z3c.form has its problems, it is currently the best
> choice for schema based forms in Plone. Switching form libraries would
> involve a very large amount of effort in rewriting widgets to work
> with the new system. I'd certainly encourage people to experiment with
> integrating some of the newer form libraries with Plone and report
> back on their experiences and create examples. Lets at least get rid
> of formlib first!

What we currently have:

* formlib for portlets
* z3cform for DX
* good old archetypes schemas and it's widgets

As this is complicated enough, there are additional subordinate things,
like:

* widgets have no consistent layout
* widgets behave different for same usecases (i.e. schema.Tuple rendered
with formlib handles the selection vocab key/value pairs the other way
around than z3c.form)

there are probably lots more of issues once we start searching for it ;)

There already are attempts in altering form libraries for several usecases:

Using z3c.form for portlets:
http://stackoverflow.com/questions/5174905/can-i-use-z3c-form-on-plone-portlets-instead-of-zope-formlib

Patrick Gerken talked at plonekonf in munich about an approach of using
deform for dexterity types (would be great to see this code ;)).

Peter Holzer has written a tutorial about using yafowil in plone:
http://plone.org/documentation/kb/build-a-custom-search-form-with-yafowil (could
be simplified a lot)

There are all the fancy new formlibs out there, as mentioned in other posts.

I think we should figure out the centre of friction for the different
usage domains (content types, portlets, config forms, etc), and describe
clearly how to hook in __any__ formlib (the stackoverflow link to the
portlet base forms is already a good starting point for portlets i think).

I fear there's no consensus of which is "the right formlib" to use. Also
i think that (almost) every formlib has it's strength (while schema
based forms are good for content types, they suck for simple forms doing
anything but direct field to data mapping).

Refering the rewrite of CPT forms -> +1 from me to use browser pages
with __call__ as form processing function. there's still the ability to
customize the look and feel by z3c.jbot.

Robert

>
> Laurence
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Plone-developers mailing list
> Plone-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plone-developers


--
Robert Niederreiter

Squarewave Computing
Aflingerstraße 19
A-6176 Völs
Tel: +43 699 160 20 192
Web: http://www.squarewave.at

David Glick (GW)

unread,
Mar 13, 2012, 12:43:25 PM3/13/12
to Johannes Raggam, plone dev

On Mar 13, 2012, at 4:06 AM, Johannes Raggam wrote:

> On Tue, 2012-03-13 at 10:50 +0100, Jens W. Klein wrote:
>> On 12.03.2012 22:03, David Glick (GW) wrote:
>>> [...]
>>> One is quite simple: move the logic of the form's scripts into the
>>> __call__ method of a BrowserView, and move the form's template to be the
>>> template of that view.
>>
>> A big +1 for this approach. As some of you may know I hate z3cforms
>> because of its unnecessary complexity (even if I may be almost alone
>> with this opinion in the Plone universe).
>
> +1
>
> z3cforms are a good example how to over-componentize code with the
> result of good flexibility (if you exactly know where to hook something
> in and are willing to write tons of code) and little flexibility (if you
> don't find such a point to hook in) at the same time. i see the power of
> z3cforms, but it's much too complicated and verbose for my taste. we
> should start to avoid it - there are better solutions out there.
>

As the developer of the TTW content type configuration UI for Dexterity, I found z3c.form hard to learn initially…but since I've known it well, it's been a great tool to use for building a flexible, extensible UI.

For building a from-scratch, standalone product, I would probably want to look into other options. But for Plone, I think *consistency* in what form library we use is important, and I think z3c.form is the best candidate for what to standardize on among the options that are currently in widespread use. For those who feel differently, I can certainly understand that, and I would encourage you to prove that another alternative is more appropriate for being our standard by actually doing the work (on branches and with a PLIP) to convert all the old forms. As usual in Plone, those who do the work win.

I would like to work on some better introductory documentation on getting things done with z3c.form. What things have people found more difficult to figure out than they should be? Some things that come to mind are using a custom form template and writing a custom widget.


----------


David Glick
Web Developer
david...@groundwire.org
206.286.1235x32

The Engagement Party 2012. So much more fun than the wedding reception.

http://www.npoengagementparty.com

Patrick Gerken

unread,
Mar 13, 2012, 1:13:28 PM3/13/12
to Robert Niederreiter, plone-de...@lists.sourceforge.net, Wichert Akkerman

I've been promised interesting things for a blog post about generating
deform forms based on zope.schemas during one of the PloneKonf
parties.
Unfortunately this won't happen before the end of this month.
But yeah, it is possible already and I want to use this in my next project.

Best regards,

Patrick

Nathan Van Gheem

unread,
Mar 13, 2012, 1:25:48 PM3/13/12
to Patrick Gerken, plone-de...@lists.sourceforge.net, Wichert Akkerman
It seems a little silly to even contemplate adding another form
library to plone at this point. Let's get rid of at least 1 of our
current ones first.

Robert Niederreiter

unread,
Mar 13, 2012, 1:37:05 PM3/13/12
to plone-developers
On 13.03.2012 18:25, Nathan Van Gheem wrote:
> It seems a little silly to even contemplate adding another form
> library to plone at this point. Let's get rid of at least 1 of our
> current ones first.
whats the benefit of getting rid except breaking existing code?

imo its better to define and document "entry API's" and promote then one
formlib as default in plone docs.


--
Robert Niederreiter

Squarewave Computing
Aflingerstraße 19
A-6176 Völs
Tel: +43 699 160 20 192
Web: http://www.squarewave.at

------------------------------------------------------------------------------

Nathan Van Gheem

unread,
Mar 13, 2012, 1:41:37 PM3/13/12
to Robert Niederreiter, plone-developers
>> It seems a little silly to even contemplate adding another form
>> library to plone at this point. Let's get rid of at least 1 of our
>> current ones first.
> whats the benefit of getting rid except breaking existing code?
>
> imo its better to define and document "entry API's" and promote then one
> formlib as default in plone docs.

Perhaps you're right. I'm pretty sure z3cforms was the plone
communities answer to this same question years ago though so we'd just
probably end up adding to our current problem.

Jean-Michel FRANCOIS

unread,
Mar 13, 2012, 1:48:31 PM3/13/12
to Robert Niederreiter, plone-developers
because it doesn t work with some others code. simply try to use
navigationroot and you will hate cfc.

--
Regards / Cordialement
JeanMichel FRANCOIS

Jens W. Klein

unread,
Mar 13, 2012, 1:58:18 PM3/13/12
to plone-de...@lists.sourceforge.net
On 13.03.2012 18:48, Jean-Michel FRANCOIS wrote:
> because it doesn t work with some others code. simply try to use
> navigationroot and you will hate cfc.

Whats the problem with CMFFormController and INavigationRoot btw.?

Jens

--
Klein & Partner KG, member of BlueDynamics Alliance

Jens W. Klein

unread,
Mar 13, 2012, 2:02:22 PM3/13/12
to plone-de...@lists.sourceforge.net
On 13.03.2012 18:25, Nathan Van Gheem wrote:
> It seems a little silly to even contemplate adding another form
> library to plone at this point. Let's get rid of at least 1 of our
> current ones first.

+1 for getting rid of it _and_ adding a generic way to use a formlib of
your choice. otherwise we end up in three years thinking on how to get
rid of [NAME FORM LIBRARY HERE].

Jens

--
Klein & Partner KG, member of BlueDynamics Alliance

Laurence Rowe

unread,
Mar 13, 2012, 3:12:33 PM3/13/12
to Jens W. Klein, plone-de...@lists.sourceforge.net
On 13 March 2012 18:02, Jens W. Klein <je...@bluedynamics.com> wrote:
> On 13.03.2012 18:25, Nathan Van Gheem wrote:
>> It seems a little silly to even contemplate adding another form
>> library to plone at this point. Let's get rid of at least 1 of our
>> current ones first.
>
> +1 for getting rid of it _and_ adding a generic way to use a formlib of
> your choice. otherwise we end up in three years thinking on how to get
> rid of [NAME FORM LIBRARY HERE].

I don't think a form library is really something that can be usefully
abstracted, at least not without effectively writing yet another one.
That's not to say any particular form library should be tightly
coupled to the core, just that the individual forms used in the core
will be tightly coupled with that library. I think Plone has settled
on z3c.form for the time being, for consistency's sake we should try
to standardize on it. In Dexterity we have a TTW schema editor that
works with it. That could offer the possibility of customizing things
like the registration and user preferences forms much more easily than
today.

I do think it would be worth exploring ways to more easily customize
templates for individual forms (this is something that I believe is
being looked at for Dexterity now.) But I don't think we should make
it a blocker to moving away from old skin templates.

Laurence

Robert Niederreiter

unread,
Mar 14, 2012, 3:35:24 AM3/14/12
to Laurence Rowe, plone-de...@lists.sourceforge.net, Jens W. Klein
On 13.03.2012 20:12, Laurence Rowe wrote:
> I don't think a form library is really something that can be usefully
> abstracted, at least not without effectively writing yet another one.
i disagree. A senceful abstraction basically consists of a base add and
edit form. as long as this base add and edit forms follow a defined
interface, i.e. provide a ``render``, ``process`` and ``next`` function,
it does not count which lib is used 'inside'. and such an interface is
not a another form lib.

> That's not to say any particular form library should be tightly
> coupled to the core, just that the individual forms used in the core
> will be tightly coupled with that library.

yes, and thats completely fine.

I think Plone has settled
> on z3c.form for the time being, for consistency's sake we should try
> to standardize on it.

and i don't think we should force people using z3c forms for
*everything* since there are easier to use alternatives out there.

In Dexterity we have a TTW schema editor that
> works with it. That could offer the possibility of customizing things
> like the registration and user preferences forms much more easily than
> today.
>
> I do think it would be worth exploring ways to more easily customize
> templates for individual forms (this is something that I believe is
> being looked at for Dexterity now.) But I don't think we should make
> it a blocker to moving away from old skin templates.
>
> Laurence
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Plone-developers mailing list
> Plone-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plone-developers


--
Robert Niederreiter

Squarewave Computing
Aflingerstraße 19
A-6176 Völs
Tel: +43 699 160 20 192
Web: http://www.squarewave.at

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/

Timo Stollenwerk

unread,
Mar 14, 2012, 3:58:03 AM3/14/12
to plone-de...@lists.sourceforge.net, Kees Hink
Am 12.03.2012 22:29, schrieb Eric Steele:
> Also, I'll point out https://dev.plone.org/ticket/10359 which was closed
> for lack of Hanno. It can certainly be reopened and picked up again.

Kees and I also started to work on replacing formlib with z3cform in
plone.app.users:

https://dev.plone.org/ticket/12253

I might want to pick up Hanno's PLIP in the future if I find the time.

Cheers,
timo

Yuri

unread,
Mar 14, 2012, 4:58:26 AM3/14/12
to plone-de...@lists.sourceforge.net
Il 13/03/2012 15:33, Jean-Michel FRANCOIS ha scritto:
>
> For easy use case like send form I'm don't want to code, I'm using PFG ^^.
>

I paste html forms in tinyMCE :-)

The problem of z3c.form, for example, is that you cannot embed a form in
a middle of a page, you've to write a form that mimic a page!

It would be cool If I can put a z3c.form form in the middle of tinyMCE.

But there are a lot of other cases. So, why don't look at what other
frameworks do? I mean popular frameworks. I bet they use plain html,
plus javascript and handle post of the form with a script...

PFG is great for simple forms, you can do the password reset, login form
etc etc with it. You can also embed it in a page using easytemplate (
{ portal.restrictedTraverse("myform/embedded")() }}, - need better
handling of the result when you submit the form...).

We have a lot of tool, each one aim at one use case.

What about a dumper from pfg to z3c.form? Given a PFG, we could write
something that create a python egg to create the same form using
z3c.form. Can this be useful? I don't know.

What we know is that forms (just think to html5) are better in html,
always. You can design them as you want. But what about validation? What
about "do something with the data"?

For validation, we just need a place to assign to every form input a
"type" and an "id". Then the validation machine can do its job. For what
to do, I don't care, because when we have the data, we're out of the
form problem.

Just read http://drupal.org/node/751826 to see how Drupal do this or
http://examples.typo3-formhandler.com/start/ for Typo3 ot this
http://ckforms.cookex.eu/index.php for Joomla.

They, mostly, do just the html part, and are designed to the use case "I
need a form HERE to do THIS" and nothing else.

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/

Dylan Jay

unread,
Mar 18, 2012, 8:51:49 AM3/18/12
to Robert Niederreiter, plone-developers
On 14/03/2012, at 4:37 AM, Robert Niederreiter wrote:

> On 13.03.2012 18:25, Nathan Van Gheem wrote:
>> It seems a little silly to even contemplate adding another form
>> library to plone at this point. Let's get rid of at least 1 of our
>> current ones first.
> whats the benefit of getting rid except breaking existing code?

Because the one thing plone is short on is new developers. Developers
are lazy and like to learn and little as possible. The less #
technologies in Plone the less a new developer has to learn and the
more likely they will stay and turn into a new Martin Aspeili. Cool
stuff ensues. Plone lives. Everybody's happy :)

---
Dylan Jay
Technical Solutions Manager
PretaWeb: Multisite Performance Support
P: +612 80819071 | M: +61421477460 | twitter.com/djay75 | linkedin.com/
in/djay75


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure

Dylan Jay

unread,
Mar 18, 2012, 8:52:43 AM3/18/12
to plone-developers developers
On 14/03/2012, at 4:25 AM, Nathan Van Gheem wrote:

> It seems a little silly to even contemplate adding another form
> library to plone at this point. Let's get rid of at least 1 of our
> current ones first.

+100

---


Dylan Jay
Technical Solutions Manager
PretaWeb: Multisite Performance Support
P: +612 80819071 | M: +61421477460 | twitter.com/djay75 | linkedin.com/
in/djay75


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure

Ross Patterson

unread,
Mar 22, 2012, 5:30:50 PM3/22/12
to plone-de...@lists.sourceforge.net
Jean-Michel FRANCOIS <tou...@gmail.com>
writes:

> Before writing a PLIP on this I would like to have your opinion on it.
> I have forms done with CMFFormController.
>
> I would like to move forms from CMFFormController to formlib or
> z3cform.

I'm +0.5 for this, mostly because I think giving our integrators
z3c.form may result in more anger. I love the discussion of other form
libraries out there but agree the z3c.form ship has sailed.

The one concern I have is whether we can do this with a minor release.
I don't think we'll be able too because it will break so many existing
customizations. I'm not saying we shouldn't do it, we definitely
should, just that we need to discuss the issue of existing *.cpt
customizations.

Ross

Nathan Van Gheem

unread,
Mar 22, 2012, 5:36:31 PM3/22/12
to Ross Patterson, plone-de...@lists.sourceforge.net
Also, no one is suggesting there is actually an alternative and no one
is saying that we can't improve z3cform at all.

Perhaps the best way forward is 1) better z3cform documentation(as
loads of people have already suggested) and 2) simplify z3cform
somehow...


-Nathan

Laurence Rowe

unread,
Mar 22, 2012, 6:47:45 PM3/22/12
to Ross Patterson, plone-de...@lists.sourceforge.net
On 22 March 2012 21:30, Ross Patterson <m...@rpatterson.net> wrote:
>
> Jean-Michel FRANCOIS <tou...@gmail.com>
> writes:
>
> > Before writing a PLIP on this I would like to have your opinion on it.
> > I have forms done with CMFFormController.
> >
> > I would like to move forms from CMFFormController to formlib or
> > z3cform.
>
> I'm +0.5 for this, mostly because I think giving our integrators
> z3c.form may result in more anger.  I love the discussion of other form
> libraries out there but agree the z3c.form ship has sailed.
>
> The one concern I have is whether we can do this with a minor release.
> I don't think we'll be able too because it will break so many existing
> customizations.  I'm not saying we shouldn't do it, we definitely
> should, just that we need to discuss the issue of existing *.cpt
> customizations.

Maybe we can ship the existing forms in a disabled by default
deprecated skin layer. But really, I think this work just needs doing.
We shouldn't get hung up on version numbers, if we decide that enough
changes warrant making a release 5.0 then we can just do that.

Laurence

Anthony Gerrard

unread,
Mar 23, 2012, 5:17:34 AM3/23/12
to Jon Stahl, plone-de...@lists.sourceforge.net, Ross Patterson
So what we're saying is not "Rewrite old cpt forms to new technology
like z3cform" but "Replace formlib with z3cform"? Or at least there's
a consensus we should do the latter but not the former

On 22 March 2012 23:37, Jon Stahl <jons...@gmail.com> wrote:
> This has been a really long and interesting thread. I think we've
> surfaced a lot of important information, so I'm going to try to take a
> shot at summarizing it.  Corrections welcome, I'm hardly an expert at
> this stuff.
>
> Plone currently uses three different form libraries (CMFFormController
> (many older Plone forms), Formlib (portlets) and z3c.form
> (Dexterity).)  Plus Archetypes is in some sense a form library as
> well.  This is a huge surface area for new developers and a lot of
> legacy code to haul around.  We'd like to find a path to simplifying
> it.
>
> z3c.form is baked into Dexterity and isn't going anywhere.  It's very
> powerful and flexible, but due to its high degree of abstraction and
> weak documentation, many people find it hard to approach.  There are
> opportunities to simplify z3c.form and to improve its documentation.
>
> While CMFFormController is old and not terribly well-designed, it may
> have the advantage of being fairly easy to work with, and suitable for
> forms that don't need to be schema driven.  At least some folks seem
> to think it should probably be kept around so that some of our
> simpler, frequently-customized forms can be easily customized without
> having to master the complexity of z3c.form.
>
> There seems to be fairly solid consensus that we should aspire to rid
> of formlib, and migrate existing formlib forms to z3c.form.
>
> This wasn't explicitly mentioned, but I'll also just throw in for the
> sake of completeness that PloneFormGen (based on Archetypes) is our
> current "best of breed" solution for TTW form building.  In the
> future, it may be replaced by something that shares (z3.form)
> technology with Dexterity's TTW schema editor.
>
> HTH,
> jon

Jean-Michel FRANCOIS

unread,
Mar 23, 2012, 6:42:11 AM3/23/12
to Jon Stahl, plone-de...@lists.sourceforge.net, Ross Patterson
Thanks a lot for this nice sum up. 

I also like the idea to implement it in minor release with a deprecated skin layer that continue to ship the current CPT forms.
So people who want will be able to activate new forms.

Regards / Cordialement,
JeanMichel FRANCOIS




Martin Aspeli

unread,
Mar 23, 2012, 6:44:39 AM3/23/12
to Anthony Gerrard, plone-de...@lists.sourceforge.net, Ross Patterson
On 23 March 2012 09:17, Anthony Gerrard <anthony...@gmail.com> wrote:
So what we're saying is not "Rewrite old cpt forms to new technology
like z3cform" but "Replace formlib with z3cform"?  Or at least there's
a consensus we should do the latter but not the former

FWIW, I would *really* like to get rid of CMFFormController (and everything else in portal_skins). 

We have portal_view_customizations in terms of template customisations. Is that sufficient? Or is there a real use case for people to change the logic scripts (validation, actions) through the web as well? If there is, we should probably look at how to make this easier to do on the filesystem rather than cling on to a TTW model that we know is fundamentally broken.

Martin

Dylan Jay

unread,
Mar 23, 2012, 7:06:00 PM3/23/12
to Anthony Gerrard, plone-de...@lists.sourceforge.net, Ross Patterson
My interpretation is that we fix z3cform to make it sinpler then
replace formcontroller. But does anyone know how?

Dylan Jay
Technical solution manager
PretaWeb 99552830

David Glick

unread,
Mar 24, 2012, 12:01:29 AM3/24/12
to Dylan Jay, plone-de...@lists.sourceforge.net, Ross Patterson
On 3/23/12 4:06 PM, Dylan Jay wrote:
> My interpretation is that we fix z3cform to make it sinpler then
> replace formcontroller. But does anyone know how?
>
>
I know how to simplify widget configuration, creating custom widgets,
and using custom form templates; just haven't found time to write it up yet.
David


----------
David Glick
Web Developer
david...@groundwire.org
206.286.1235x32

The Engagement Party 2012. So much more fun than the wedding reception.

http://www.npoengagementparty.com

------------------------------------------------------------------------------

David Glick

unread,
Mar 24, 2012, 4:58:36 AM3/24/12
to Jean-Michel FRANCOIS, plone-de...@lists.sourceforge.net
On 3/24/12 1:49 AM, Jean-Michel FRANCOIS wrote:
> A question remains, do we create a plone.app.forms / p.a.commonforms
> package (ala skins/plone_forms , or plone.app.layout) to get all
> z3cforms for Plone ? or Do we use an existing package (and so which
> one ?) ?
>

Let's place them based on functionality rather than based on the fact
that they are forms, and avoid creating new packages if possible.

Based on the list you just posted to twitter, it looks like they fall in
to several groups:
- user/group management -- these belong in plone.app.controlpanel or
plone.app.users
- login -- probably also plone.app.users
- basic content management like delete, rename, etc -- these can
probably just go in CMFPlone's /browser dir

> I will be able to start a rewrite in two weeks.
>
Cool!

greetings from the Cioppino sprint,

Raphael Ritz

unread,
Mar 24, 2012, 7:21:06 AM3/24/12
to plone-de...@lists.sourceforge.net
On 3/23/12 11:44 AM, Martin Aspeli wrote:
>
>
> On 23 March 2012 09:17, Anthony Gerrard
> <anthony...@gmail.com

Warning: I've never used z3cform for any of the following.

Two real world use cases where I'm using the form controller
to implement custom logic/flow:

1. Instead of plain 'save' distinguish between 'save and continue
later' and 'save and submit' where the first does no validation
but the second does (and triggers a workflow transition plus a
redirect to something different from the items view).

2. The 'more' button of the RecordsField in ATExtensions to add
a further row of subfields to a list of structured entries on
the edit form. Here the FC makes it possible for me as an add-on
author to hook into the default edit flow without touching anything.

TTW or not isn't really a point for me here. Maybe for introspection
purposes but not so much for config (changes).

YMMV

Raphael


>
> Martin

Laurence Rowe

unread,
Mar 24, 2012, 7:47:58 AM3/24/12
to Raphael Ritz, plone-de...@lists.sourceforge.net

This is the sort of thing where z3c.form's 'everything is an adapter'
approach really shines. For most things it is possible to add
functionality to existing forms through component registrations.
Though for adding buttons to an existing form, it may currently be
lacking. Perhaps this code could be merged into z3c.form:
https://github.com/plone/plone.z3cformbuttonoverrides/blob/master/plone/z3cformbuttonoverrides/buttonoverrides.py

Laurence

Yuri

unread,
Mar 26, 2012, 3:41:49 AM3/26/12
to plone-de...@lists.sourceforge.net
Il 23/03/2012 11:44, Martin Aspeli ha scritto:
>
>
> On 23 March 2012 09:17, Anthony Gerrard <anthony...@gmail.com

move them to fs is easy with cmfformcontroller, using qPloneSkinDump and
moving them on you product skin directory.

portal_skin customization is good also for css/js customization, while
having them as browser resources can be difficult. You've always to
restart plone just to see if padding-left: 10px works :)

Also, Archetypes depends on cmfformcontroller, and you can associate
every button to an action (ttw).

I think someone should make some example on how to do this kind of
simple things without CMFFormController (without rewriting everything,
of course)

Martin Aspeli

unread,
Mar 26, 2012, 3:59:16 AM3/26/12
to Yuri, plone-de...@lists.sourceforge.net
You don't need to restart for browser resources to be refreshed. They are always served straight from the filesystem.
Reply all
Reply to author
Forward
0 new messages