0

I have the following in a config.ini file: (Zend_Form_Element)

site_status.name = "site_status"
site_status.type = "select"
site_status.label = "Status"
site_status.options.multiOptions.active.key = "Active"
site_status.options.multiOptions.active.value = "Active"
site_status.options.multiOptions.active.key = "Inactive"
site_status.options.multiOptions.active.value = "Inactive"

As you can see this is supposed to be a dropdown (select) box, however it is being rendered as a standard text box. What am I doing wrong?

--> Edit

Rather than tying the elements to a form, I am trying to tie them to a database: In my code it would look something like this:

[{tablename}] // the table name would represent a section in the ini
{column}.name = "{column_name/form_field_id}";
{column}.type = "{form_element_type}"
{column}.label = "{form_element_label}"
...

From there I would pull in the database table(s) that the form would represent data for (one or more tables as necessary). As far as the reasoning for this approach is that (down the road), I want to define (either by ini or some other storage method), a configuration file that would be a list of fields/elements that belong to a specific form (that a non-programmer type could easily edit), that the 'generic' form class would read, pull in the element info, and create the form on the fly.

I do realize however this poses another problem which I haven't yet figured out, and that is how to use table lookups for select elements (without coding the database retrieval of the lookup into the form, so that a non-user could easily just define it without any programming, purely configuration, but that is a whole other topic not part of my question here. (and I think I have viable ideas/solutions to that part of the problem anyhow) -- extra config entries and a generic routine pretty much.

I hope that clarifies my thought process and reason why I am doing it the way I am in the example above.

Aaron Murray
  • 1,920
  • 3
  • 22
  • 38
  • 1
    I don't immediately see why it's rendering as a text box. But as a side note, I suspect that your last two lines should reference `inactive` rather than `active`. – David Weinraub Aug 23 '11 at 08:50
  • @DavidWeinraub hah yes I did notice that a little while after I posted the question (good catch). I actually also came up with another note, no matter what 'type' I use (text, textarea, etc...), it always creates a text field. My code in the form is something like this: { $this->addElement(new Zend_Form_Element($config->site_status); } Another note: { $this->addElement(new Zend_Form_Element_Select($config->site_status); } Works, however somewhat defeats the purpose of putting this all in a configuration file. – Aaron Murray Aug 26 '11 at 04:33

1 Answers1

1

I have not yet played with using a Zend_Config to construct an instance of Zend_Form.

But a look at the code suggests that Zend_Form::addElement() doesn't directly take a Zend_Config instance as a param. Rather, it looks like you need pass your Zend_Config instance to the form constructor. It also seems that the config format needs to be a little deeper in order to map config keys to setXXX() calls.

In path/to/config/myForm.ini:

[myForm]

myForm.elements.site_status.name = "site_status"
myForm.elements.site_status.type = "select"
myForm.elements.site_status.label = "Status"
myForm.elements.site_status.options.multiOptions.active.key = "Active"
myForm.elements.site_status.options.multiOptions.active.value = "Active"
myForm.elements.site_status.options.multiOptions.inactive.key = "Inactive"
myForm.elements.site_status.options.multiOptions.inactive.value = "Inactive"

Then instantiating:

$formConfig = new Zend_Config_Ini('path/to/config/myForm.ini', 'myForm');
$form = new Zend_Form($formConfig);

Not tested, but looking at this example:

Using Zend_Form with Zend_Config - Andrew Vayanis

it feels like it should go something like the above.

Update

In view of the comments/feedback from @Aaron, two more approaches.

  1. We could extend Zend_Form, implementing a method called something like addElementByConfig in which we would pass the shallow Zend_Config instance that describes the element itself. In fact, we could even just override addElement(), taking a recursive approach: if the first param is an instance of Zend_Config, then call addElement() using the component data.

  2. If the atomicity and re-usability are the primary benefits we seek in using Zend_Config to describe an element, then perhaps we just make a custom element extending Zend_Form_Element. Then we could use these elements in any forms we wish.

David Weinraub
  • 14,144
  • 4
  • 42
  • 64
  • Most of the examples I googled showed that way, however my goal is not to tie an element to a form semantically speaking, but to pull in all the fields and choose the ones I want in each form (as some fields may belong to multiple forms). (continued...) – Aaron Murray Aug 27 '11 at 01:40
  • In your example above, I could create it that way (and though I have not tested it, it may actually work), and then pull the fields from a deeper depth. That wouldn't (I don't think) cause any speed or memory disadvantages, but it would break the semantic goals I am trying to accomplish. I will give an A+ for your reply, I probably should have explained that a bit better in my question description. – Aaron Murray Aug 27 '11 at 01:40
  • I will accept your answer as you have put a lot of effort into it, and have given me a few options to work with. It may not exactly fit what I am trying to accomplish, but at the same time, my goal is not to go against the grain of the framework, rather to utilise it's functionality 'out of the box' in most cases. Thank you for your efforts, I am re-examining and structuring my code with your alternatives in mind. (and I like both options in your update, granted not exactly out of the box concepts, still maintain the original goals rather well) -- Decision time – Aaron Murray Aug 30 '11 at 03:03