Re: [PEPr] +1 for Structures::Structures_Form

From: Date: Mon, 17 Apr 2006 16:51:17 +0000
Subject: Re: [PEPr] +1 for Structures::Structures_Form
References: 1 2  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-42268@lists.php.net to get a copy of this message
On 4/17/06, Scott Mattocks <scott@crisscott.com> wrote: > Justin Patrin wrote: > > Justin Patrin (http://pear.php.net/user/justinpatrin) has voted +1 on the proposal for > > Structures::Structures_Form. > > > > This vote is conditional. The condition is: > > > > I'm not sure I like adding a mandatory requirement on reflection. How prevalent is > > reflection in peoples' installs? Could it be done using an assoc array perhaps instead of > > constructor params? > > Reflection is enabled by default. Has anyone turned it off? Thanks for the clarification. If this is on by default everything *should* be ok. This is only used for instatiating new classes, though....I'm still not sure that's the best way to do this, it seems like a hack. > > > > > It seems like the API here doesn't allow for recursive elements. It would be nice to > > have groups be just another element type which happens to hold other elements. > > > > It looks like the setValues() implementation makes this far less extendable than > > HTML_QuickForm. As far as I can see only element names which are arrays would work in sub-elements. > > See the element types I've added to FormBuilder for the types that I'd like to be able to > > create (subForm and elementTable). > > > > I'll take a look. What about the current group implementation seems > limiting? The example uses a simple group to organize the authentication > information. I haven't actually run any examples (sorry about that) but what i'm looking for is a way to allow arbitrary elements within any other element (or group). What I'm worried about is this: foreach ($values as $element => $value) { $this->setValue($element, $value)) { } This assumes (AFAICT) that an element will only use values which correspond to its name. This, for instance, limits elments in groups as they will always have to have the name of the group attached as an array. Ex: $form->addElement('frame', 'authentication', 'Authentication'); $form->addElementToGroup('username', 'authentication'); $form->addElementToGroup('password', 'authentication'); Ends up with 2 elements in the form, "authentication[username]" and "authentication[password]". What if I just wanted them to be named "username" and "password"? (This may not be how it's implemented in Gtk2, but this is how it would end up in HTML.) This would also preclude things like my ElementTable, at least in its current incarnation. The sub-elements would always have to have a name based on the group/parent element. > > > Use a static private for the errors rather than a global. Or use a static within a > > function to hide it from, say, print_r. > > > > I have no problem with this, but it seems inconsistent with other PEAR > classes. Some use a class var, some use globals. The main reason for using a global is to get around PHP4 not having static class vars. Since PHP5 does have static class vars this is how you should implement this. > > > Support for constant element values, as in QuickForm, would be nice. > > > > I think this can easily be done by adding a setConstant method to the > interface. Then an element base class (or individual elements for Gtk2 > stuff) can check a flag in the setValue method. > > > I don't understand quite why you're using class constants for the names of the > > interfaces and file names. I suggest using just the strings. > > > > To allow other classes to access the names and paths if needed. Probably > not entirely necessary. I can change it. > IMHO constants are overrated and a throwback to C/C++ style programming. I'd rather type the actual name than use a constant any day, especially for things like this which won't be able to change anyway. > > There may be other things as well, but I don't have time to look closer right now, > > this is a very large package. > > > > Yes it is. If anyone wants to lend a hand, I'd be more than happy to > have the help. > I may try to help, I'm very interested in this form package, especially as it will be useful for FormBuilder(2), but my time is limited... -- Justin Patrin

« previous php.pear.dev (#42268) next »