Re: [fw-general] New Zend_Form Proposal
Today I've been working on updating the proposal by writing documentation on how to use my current implementation. Unfortunately the Wiki was (and is) down, so I couldn't update the proposal itself. Hopefully the documentation will give some more insight on how I want the _Form to work. The documentation, together with the (working :) implementation, can be found in this SVN repo: http://tools.assembla.com/svn/zfcomponents/ Jurriën On 08 Aug 2007, at 09:51, Simon Mundy wrote: Hi Jurriën At first glance I can see some immediate improvements over mine and Ralf's proposal. One thing particularly that interested me was the idea of an MVC helper that could be responsible for telling a form what data it has received by interacting with the Request object - this would address a concern that Martel had about performance and properly separating the logic from the presentation, rule processing and filtering. However as a long-term proposition I think that the Form should allow population and creation by means other than just integration - it should be able to stand alone. I'm not a huge fan of the factory - I think we'd lose a lot of the graceful class extension by forcing a factory class upon it and then supply user paths, prefixes, etc. that could be avoided by inheritance. I am still a big fan of the Zend_Db_Table approach, whereby methods such as 'init()', 'preDispatch', 'postDispatch' etc could be leveraged to allow a self-contained 'static' class (i.e. the logic is hardcoded into the Form Model) or to build a dynamic form from a config file. I'd like to flesh out these ideas in my head a little - I started trying to recode my original proposal but a) time got away and b) wanted to get the component leaders to respond as well so we can, as you say, get some good community feedback. Look forward to the email ping-pong Jurriën! :) Cheers Hi all, A few days ago I posted a new Zend_Form proposal. It takes a somewhat different approach than Simon & Ralf's proposal. It has been discussed a few times on #zftalk, but I feel that it could really use some community input. Please read it and comment on it at: http://framework.zend.com/wiki/pages/viewpage.action?pageId=36061 Thanks! Jurriën -- Simon Mundy | Director | PEPTOLAB """ " "" "" "" "" """ " "" " " " " "" "" " 202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000 Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 9654 4124 http://www.peptolab.com
Re: [fw-general] New Zend_Form Proposal
Matthew Weier O'Phinney wrote:
No. 5.2.0 introduced a BC break in property overloading with previous
PHP versions, as well as shipped a broken version of ArrayObject. The
Right.
5.2.1 fixes things somewhat, in that ArrayObject now works. However, you
still cannot overload to arrays unless they are public properties, and
even then, you still cannot create arrays using a notation such as:
$o->foo[] = 23; // Will not create an array
From what I am witnessing, 5.2.1 works perfectly, but only when you
force the return by reference on __get().
Essentially this:
public function __get($name) {}
becomes
public function & __get($name) {}
This is the notation that should be used moving forward for all
implementations of classes that expect to emulate the stdClass when it
comes to storage of arrays and objects.
Keep in mind, Zend_Session does not save to a public property since the
only place it has as an option to save to is the $_SESSION superglobal.
This works b/c it forces the 5.2.*+ series (not including 5.2.0) to
return by reference [since __get is called implicitly by
__set($name,$value) on complex datatypes as $name]. This ALSO works for
the 5.1.* series since returning by reference is essentially redundant
since that is what it was doing anyway.
Thus, 5.2.0 is the only bad egg.
See the tests here:
http://framework.zend.com/issues/browse/ZF-1743
-ralph
Re: [fw-general] New Zend_Form Proposal
-- Jurriën Stutterheim <[EMAIL PROTECTED]> wrote (on Wednesday, 08 August 2007, 11:07 AM +0200): > Is the issue from 5.2.0 relevant for later versions of PHP? No. 5.2.0 introduced a BC break in property overloading with previous PHP versions, as well as shipped a broken version of ArrayObject. The end result was that it was impossible to have an overloaded array property. 5.2.1 fixes things somewhat, in that ArrayObject now works. However, you still cannot overload to arrays unless they are public properties, and even then, you still cannot create arrays using a notation such as: $o->foo[] = 23; // Will not create an array if using both __get and __set, even if __set() creates public properties. > As for the ZFI and chains, I feel like it is a shame to reproduce > existing code. Although I have to agree ZFI might be overkill and/or > not suited for combining with the Zend_Form API, I do believe the > Zend_Filter and Zend_Validate chains can be extremely usefull for > Zend_Form. > > Cheers, > > Jurriën > > > On 08 Aug 2007, at 09:51, Kevin McArthur wrote: > > >This is very similar to the syntax I posted previously. It's a > >solid approach. > > > >The only issue I came along trying to mock this up is the > >implementation details (see the previous thread about Zend_Session > >and php 5.2.0) as well as wether or not the component starts a-new > >or layers on top of Zend_Filter_Input and the concept of chains. > > > >K > >- Original Message - From: "Jurriën Stutterheim" > ><[EMAIL PROTECTED]> > >To: "Zend Framework General" > >Sent: Wednesday, August 08, 2007 12:49 AM > >Subject: [fw-general] New Zend_Form Proposal > > > > > >Hi all, > > > >A few days ago I posted a new Zend_Form proposal. It takes a somewhat > >different approach than Simon & Ralf's proposal. > >It has been discussed a few times on #zftalk, but I feel that it > >could really use some community input. > >Please read it and comment on it at: > > > >http://framework.zend.com/wiki/pages/viewpage.action?pageId=36061 > > > > > >Thanks! > > > > > >Jurriën= > > > -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] New Zend_Form Proposal
Hi Kevin, Thank you for that syntax. As you can see I made use of it :) Is the issue from 5.2.0 relevant for later versions of PHP? As for the ZFI and chains, I feel like it is a shame to reproduce existing code. Although I have to agree ZFI might be overkill and/or not suited for combining with the Zend_Form API, I do believe the Zend_Filter and Zend_Validate chains can be extremely usefull for Zend_Form. Cheers, Jurriën On 08 Aug 2007, at 09:51, Kevin McArthur wrote: This is very similar to the syntax I posted previously. It's a solid approach. The only issue I came along trying to mock this up is the implementation details (see the previous thread about Zend_Session and php 5.2.0) as well as wether or not the component starts a-new or layers on top of Zend_Filter_Input and the concept of chains. K - Original Message - From: "Jurriën Stutterheim" <[EMAIL PROTECTED]> To: "Zend Framework General" Sent: Wednesday, August 08, 2007 12:49 AM Subject: [fw-general] New Zend_Form Proposal Hi all, A few days ago I posted a new Zend_Form proposal. It takes a somewhat different approach than Simon & Ralf's proposal. It has been discussed a few times on #zftalk, but I feel that it could really use some community input. Please read it and comment on it at: http://framework.zend.com/wiki/pages/viewpage.action?pageId=36061 Thanks! Jurriën=
Re: [fw-general] New Zend_Form Proposal
Hello, I am working just now with some forms and i would like to have some possibility to work with Javascript on forms maybe somehow (may be possible through Ajax too in a different way). Sample form: 1. Combo box with couple of items 2. A textarea If combobox is selecting option 0 to te able somehow to make textarea read-only. If is selected other option then textarea to be made write allow. Not sure if it fits what's now, i just put here a common case i guess... Best regards, Cristian Bichis www.zftutorials.com | www.zfforums.com | www.zflinks.com | www.zftalk.com Hi Simon, One of the things I tried to accomplish with this Zend_Form setup is flexibility. -- Best regards, Cristian Bichis www.zftutorials.com | www.zfforums.com | www.zflinks.com | www.zftalk.com
Re: [fw-general] New Zend_Form Proposal
Hi Simon,
One of the things I tried to accomplish with this Zend_Form setup is
flexibility. Seeing as form handeling is a delicate subject, I wanted
developers to be able to use Zend_Form as much or as little as they
would like.
The usage of helpers is therefore completely optional. :)
The factory approach wasn't my initial choice either, but it makes
the usage of Zend_Form a lot easier and saves many lines of code.
After a days work of refactoring I made a clean cut between the
Zend_Form factory class and the real form "pages".
Again, this made the factory approach optional. I'll give an example:
$form = Zend_Form::get('myForm', Zend_Form::DATASOURCE_POST);
could be rewritten as:
$form = new Zend_Form_Page();
$form->setName('myForm');
$form->setAction('/request/uri');
$form->setInputData($_POST);
Or, if you have a custom form page class (with name and action
already setup):
/** class My_Form extends Zend_Form_Page */
$form = new My_Form();
$form->setInputData($_POST);
The flexibility of the Zend_Form isn't documented well enough in the
proposal yet (time...). I personally see this flexibility as a major
plus to this approach, but it also brings complexity.
I'd be interested to see how a Zend_Db_Table approach would work for
Zend_Form. I touched this sort of implementation briefly, but then I
started a massive refactoring spree. ;)
There is a link to a SVN repo in the proposal by the way, if you like
to have a look at what's been done so far.
Cheers!
Jurriën
On 08 Aug 2007, at 09:51, Simon Mundy wrote:
Hi Jurriën
At first glance I can see some immediate improvements over mine and
Ralf's proposal. One thing particularly that interested me was the
idea of an MVC helper that could be responsible for telling a form
what data it has received by interacting with the Request object -
this would address a concern that Martel had about performance and
properly separating the logic from the presentation, rule
processing and filtering. However as a long-term proposition I
think that the Form should allow population and creation by means
other than just integration - it should be able to stand alone.
I'm not a huge fan of the factory - I think we'd lose a lot of the
graceful class extension by forcing a factory class upon it and
then supply user paths, prefixes, etc. that could be avoided by
inheritance. I am still a big fan of the Zend_Db_Table approach,
whereby methods such as 'init()', 'preDispatch', 'postDispatch' etc
could be leveraged to allow a self-contained 'static' class (i.e.
the logic is hardcoded into the Form Model) or to build a dynamic
form from a config file.
I'd like to flesh out these ideas in my head a little - I started
trying to recode my original proposal but a) time got away and b)
wanted to get the component leaders to respond as well so we can,
as you say, get some good community feedback.
Look forward to the email ping-pong Jurriën! :)
Cheers
Hi all,
A few days ago I posted a new Zend_Form proposal. It takes a
somewhat different approach than Simon & Ralf's proposal.
It has been discussed a few times on #zftalk, but I feel that it
could really use some community input.
Please read it and comment on it at:
http://framework.zend.com/wiki/pages/viewpage.action?pageId=36061
Thanks!
Jurriën
--
Simon Mundy | Director | PEPTOLAB
""" " "" "" "" "" """ " "" " " " " "" "" "
202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000
Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3
9654 4124
http://www.peptolab.com
Re: [fw-general] New Zend_Form Proposal
I'm not a huge fan of the factory - I think we'd lose a lot of the graceful class extension by forcing a factory class upon it and then supply user paths, prefixes, etc. that could be avoided by inheritance. The logic behind this is that with a factory, you may fetch a persisted form (session, cache) which contains some data (like previous post info or error messages). I am still a big fan of the Zend_Db_Table approach, whereby methods such as 'init()', 'preDispatch', 'postDispatch' etc could be leveraged to allow a self-contained 'static' class (i.e. the logic is hardcoded into the Form Model) or to build a dynamic form from a config file. This pushes things like redirection into the model. Conventional thought on MVC is that the controller layer handles things like redirection and user input whereas models handle computation. K Hi all, A few days ago I posted a new Zend_Form proposal. It takes a somewhat different approach than Simon & Ralf's proposal. It has been discussed a few times on #zftalk, but I feel that it could really use some community input. Please read it and comment on it at: http://framework.zend.com/wiki/pages/viewpage.action?pageId=36061 Thanks! Jurriën -- Simon Mundy | Director | PEPTOLAB """ " "" "" "" "" """ " "" " " " " "" "" " 202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000 Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 9654 4124 http://www.peptolab.com
Re: [fw-general] New Zend_Form Proposal
Hi Jurriën At first glance I can see some immediate improvements over mine and Ralf's proposal. One thing particularly that interested me was the idea of an MVC helper that could be responsible for telling a form what data it has received by interacting with the Request object - this would address a concern that Martel had about performance and properly separating the logic from the presentation, rule processing and filtering. However as a long-term proposition I think that the Form should allow population and creation by means other than just integration - it should be able to stand alone. I'm not a huge fan of the factory - I think we'd lose a lot of the graceful class extension by forcing a factory class upon it and then supply user paths, prefixes, etc. that could be avoided by inheritance. I am still a big fan of the Zend_Db_Table approach, whereby methods such as 'init()', 'preDispatch', 'postDispatch' etc could be leveraged to allow a self-contained 'static' class (i.e. the logic is hardcoded into the Form Model) or to build a dynamic form from a config file. I'd like to flesh out these ideas in my head a little - I started trying to recode my original proposal but a) time got away and b) wanted to get the component leaders to respond as well so we can, as you say, get some good community feedback. Look forward to the email ping-pong Jurriën! :) Cheers Hi all, A few days ago I posted a new Zend_Form proposal. It takes a somewhat different approach than Simon & Ralf's proposal. It has been discussed a few times on #zftalk, but I feel that it could really use some community input. Please read it and comment on it at: http://framework.zend.com/wiki/pages/viewpage.action?pageId=36061 Thanks! Jurriën -- Simon Mundy | Director | PEPTOLAB """ " "" "" "" "" """ " "" " " " " "" "" " 202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000 Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 9654 4124 http://www.peptolab.com
Re: [fw-general] New Zend_Form Proposal
This is very similar to the syntax I posted previously. It's a solid approach. The only issue I came along trying to mock this up is the implementation details (see the previous thread about Zend_Session and php 5.2.0) as well as wether or not the component starts a-new or layers on top of Zend_Filter_Input and the concept of chains. K - Original Message - From: "Jurriën Stutterheim" <[EMAIL PROTECTED]> To: "Zend Framework General" Sent: Wednesday, August 08, 2007 12:49 AM Subject: [fw-general] New Zend_Form Proposal Hi all, A few days ago I posted a new Zend_Form proposal. It takes a somewhat different approach than Simon & Ralf's proposal. It has been discussed a few times on #zftalk, but I feel that it could really use some community input. Please read it and comment on it at: http://framework.zend.com/wiki/pages/viewpage.action?pageId=36061 Thanks! Jurriën=
