Re: [Framework-Team] Re: PLIP 10359 for Plone 4.1 - Convert control panels to use z3c.form
On Mon, Mar 22, 2010 at 1:32 AM, Martin Aspeli optilude+li...@gmail.com wrote: David Glick wrote: So I guess it's not clear to me that there is one best practice, or at least not one that is best in all circumstances. To me at least, the idea that we pick an arbitrary context (the Plone site root) and then write a one-off adapter from that to some schema interface that happens to represent the fields we want (the schema is almost always form-specific, since we want to control fields, ordering, fieldset grouping etc), register it in the CA (even though it's going to be used only for the form) and then let the form framework look it up on a field-by-field basis seems entirely like CA abuse. It's also quite difficult to understand if you're reading the code. Ok, so there doesn't seem to be one obvious way to do it :( Once I get to actually coding this, I'll try both approaches and make an arbitrary decision based on what looks better ;-) Thanks for the input, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP 10359 for Plone 4.1 - Convert control panels to use z3c.form
Hanno Schlichting wrote: Hi there, I've written a new PLIP that I'll hope to submit for Plone 4.1 Convert control panels to use z3c.form available at http://dev.plone.org/plone/ticket/10359. I'll start the work on the PLIP shortly, so if anyone sees any major problems with it or has other suggestions, I'd welcome any early feedback. I'm glad you're moving this forward - I had a quite hard time dealing with zope.formlib in the control panels recently. :S Does z3c.form include a more intelligent password field? See https://dev.plone.org/plone/ticket/9689 -- israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP 10359 for Plone 4.1 - Convert control panels to use z3c.form
Hanno Schlichting wrote: Hi there, I've written a new PLIP that I'll hope to submit for Plone 4.1 Convert control panels to use z3c.form available at http://dev.plone.org/plone/ticket/10359. I'll start the work on the PLIP shortly, so if anyone sees any major problems with it or has other suggestions, I'd welcome any early feedback. I suggest we use the dict context (implement getContent() and return a dict) instead of all those adapters to get/set values as we do presently. Also, use trunk of z3c.form, plone.z3cform and plone.app.z3cform for the time being - important cleanups have happened. This PLIP is dependent on someone owning the general z3c.form / Plone integration PLIP (http://dev.plone.org/plone/ticket/9473) - I hope someone will be up to that task :) I can at least help, though I'll need to see closer to the actual deadline where I can own it. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP 10359 for Plone 4.1 - Convert control panels to use z3c.form
On Sun, Mar 21, 2010 at 2:26 PM, Martin Aspeli optilude+li...@gmail.com wrote: I suggest we use the dict context (implement getContent() and return a dict) instead of all those adapters to get/set values as we do presently. Ok. I'll have a look at that. Those adapters only exist, as the context of the form is the plone site root, but the settings come from many different places. Some of the forms redefine self.context, some of them use some property helpers to deal with portal_properties and value conversions. So there needs to be some form of intermediate layer in between, but I don't care what it is. Also, use trunk of z3c.form, plone.z3cform and plone.app.z3cform for the time being - important cleanups have happened. That's what I thought. This PLIP is dependent on someone owning the general z3c.form / Plone integration PLIP (http://dev.plone.org/plone/ticket/9473) - I hope someone will be up to that task :) I can at least help, though I'll need to see closer to the actual deadline where I can own it. Ah, you didn't fall for the obvious trap ;) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP 10359 for Plone 4.1 - Convert control panels to use z3c.form
On 3/21/10 7:40 AM, Hanno Schlichting wrote: On Sun, Mar 21, 2010 at 2:26 PM, Martin Aspeli optilude+li...@gmail.com wrote: I suggest we use the dict context (implement getContent() and return a dict) instead of all those adapters to get/set values as we do presently. Ok. I'll have a look at that. Those adapters only exist, as the context of the form is the plone site root, but the settings come from many different places. Some of the forms redefine self.context, some of them use some property helpers to deal with portal_properties and value conversions. So there needs to be some form of intermediate layer in between, but I don't care what it is. -1 on this, which feels like change just for change's sake -- unless it's really clear it makes the code more readable. David -- David Glick Web Developer Groundwire 206.286.1235x32 davidgl...@groundwire.org http://groundwire.org ONE/Northwest is now Groundwire! ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP 10359 for Plone 4.1 - Convert control panels to use z3c.form
On Sun, Mar 21, 2010 at 8:15 PM, David Glick davidgl...@groundwire.org wrote: On 3/21/10 7:40 AM, Hanno Schlichting wrote: On Sun, Mar 21, 2010 at 2:26 PM, Martin Aspeli optilude+li...@gmail.com wrote: I suggest we use the dict context (implement getContent() and return a dict) instead of all those adapters to get/set values as we do presently. Ok. I'll have a look at that. Those adapters only exist, as the context of the form is the plone site root, but the settings come from many different places. Some of the forms redefine self.context, some of them use some property helpers to deal with portal_properties and value conversions. So there needs to be some form of intermediate layer in between, but I don't care what it is. -1 on this, which feels like change just for change's sake -- unless it's really clear it makes the code more readable. Is that a -1 on Martin's dict context / getContent() suggestion? I'd like to have those forms be good examples of using z3c.form, so I'd like to use whatever is considered to be best practice. The use-case is having standalone forms which pull their data from a different place. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP 10359 for Plone 4.1 - Convert control panels to use z3c.form
On 3/21/10 12:21 PM, Hanno Schlichting wrote: Is that a -1 on Martin's dict context / getContent() suggestion? I'd like to have those forms be good examples of using z3c.form, so I'd like to use whatever is considered to be best practice. The use-case is having standalone forms which pull their data from a different place. Most z3c.forms I've seen use a pattern similar to formlib forms, where the form context is adapted to the interface a field came from, and then values are retrieved/set via attribute access. I've also done something akin to Martin's suggestion, where getContent() is responsible for retrieving all the values from the context (and then memoizing the result), and a custom form action takes care of writing the values back to the appropriate locations. The first way probably results in less code in cases where the context already provides the interface you're using for the form. The second way probably results in less code in other cases. The first way is easier to override, since the reading/writing is factored out to a separate component from the form. The second way is probably a bit easier for newbies to figure out what's going on. So I guess it's not clear to me that there is one best practice, or at least not one that is best in all circumstances. David -- David Glick Web Developer Groundwire 206.286.1235x32 davidgl...@groundwire.org http://groundwire.org ONE/Northwest is now Groundwire! ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP 10359 for Plone 4.1 - Convert control panels to use z3c.form
David Glick wrote: On 3/21/10 12:21 PM, Hanno Schlichting wrote: Is that a -1 on Martin's dict context / getContent() suggestion? I'd like to have those forms be good examples of using z3c.form, so I'd like to use whatever is considered to be best practice. The use-case is having standalone forms which pull their data from a different place. Most z3c.forms I've seen use a pattern similar to formlib forms, where the form context is adapted to the interface a field came from, and then values are retrieved/set via attribute access. I've also done something akin to Martin's suggestion, where getContent() is responsible for retrieving all the values from the context (and then memoizing the result), and a custom form action takes care of writing the values back to the appropriate locations. The first way probably results in less code in cases where the context already provides the interface you're using for the form. The second way probably results in less code in other cases. The first way is easier to override, since the reading/writing is factored out to a separate component from the form. The second way is probably a bit easier for newbies to figure out what's going on. So I guess it's not clear to me that there is one best practice, or at least not one that is best in all circumstances. To me at least, the idea that we pick an arbitrary context (the Plone site root) and then write a one-off adapter from that to some schema interface that happens to represent the fields we want (the schema is almost always form-specific, since we want to control fields, ordering, fieldset grouping etc), register it in the CA (even though it's going to be used only for the form) and then let the form framework look it up on a field-by-field basis seems entirely like CA abuse. It's also quite difficult to understand if you're reading the code. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
