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.

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.

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.)

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.

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.

Re: Rewrite old cpt forms to new technology like z3cform

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.

Re: Rewrite old cpt forms to new technology like z3cform

>> 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? :)

Re: Rewrite old cpt forms to new technology like z3cform

> 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.

>> 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? :)

Re: Rewrite old cpt forms to new technology like z3cform

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).

Re: Rewrite old cpt forms to new technology like z3cform

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 ?

Re: Rewrite old cpt forms to new technology like z3cform

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
> [hidden email]> https://lists.sourceforge.net/lists/listinfo/plone-developers

Re: Rewrite old cpt forms to new technology like z3cform

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.

Re: Rewrite old cpt forms to new technology like z3cform

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.

Re: Rewrite old cpt forms to new technology like z3cform

On 13 March 2012 11:52, Wichert Akkerman <[hidden email]> 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:

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).

Re: Rewrite old cpt forms to new technology like z3cform

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