[Plone-developers] Rewrite old cpt forms to new technology like z3cform
Jean-Michel FRANCOIS
Martin Aspeli
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.
Eric Steele
Elizabeth Leddy
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/12265Plus we have many forms technologies:* z3cform + plone.autoform (based on it but still an other one)* zope.formlib* CMFFormControllerI really would like to get ride of any CMFForm from Plone.
------------------------------------------------------------------------------
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
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/12265Plus we have many forms technologies:* z3cform + plone.autoform (based on it but still an other one)* zope.formlib* CMFFormControllerI 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.
David Glick (GW)
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/12265Plus we have many forms technologies:* z3cform + plone.autoform (based on it but still an other one)* zope.formlib* CMFFormControllerI 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.
|
David Glick |
|
|
The NPO Engagement Party 2012. So much more fun than the wedding reception. | |
Eric Steele
Elizabeth Leddy
Martin
Roberto Allende
> 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
------------------------------------------------------------------------------
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
> 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
>> 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
> 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
Jens W. Klein
> [...]
> 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
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.)
Yuri
>
>
> 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
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 ?
Wichert.
Johannes Raggam
> 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
Malthe Borch
> 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
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
Laurence Rowe
> 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
> 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
Davide Moro
> 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
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
Davide Moro
> 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
No, I mean that it should be great providing something similar to a
robust and working portal_view_customizations.
Best regards,
Robert Niederreiter
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)
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
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
library to plone at this point. Let's get rid of at least 1 of our
current ones first.
Robert Niederreiter
> 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.
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
>> 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
navigationroot and you will hate cfc.
--
Regards / Cordialement
JeanMichel FRANCOIS
Jens W. Klein
> 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
> 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
> 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
> I don't think a form library is really something that can be usefully
> abstracted, at least not without effectively writing yet another one.
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
> 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
>
>
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
> 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
> 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
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
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
>
> 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
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
Martin Aspeli
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
Dylan Jay
replace formcontroller. But does anyone know how?
Dylan Jay
Technical solution manager
PretaWeb 99552830
David Glick
> My interpretation is that we fix z3cform to make it sinpler then
> replace formcontroller. But does anyone know how?
>
>
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
> 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
>
>
> 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
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
>
>
> 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)
