FuelPHP Forums

amrussell

How would you pass values from a database table into a form dropdown using $_properties ?
I.e. Something like this:

  .....
        'country_id' => array(
            'data_type' => 'varchar',
            'label' => 'Country',
            'form' => array('data_type' => 'select', 'options' => array()),
            'validation' => array('required'),
        ),
    .....

I have tried overwriting these detials into the constructor of the model but this doesnt seem to work.

static::$_properties['country_id']['form']['options'] = static::country_dropdown_list();

It is possible to populate the 'options' from the controller using the fieldset class, however the country_id can't be set inside $_properties which is not ideal.

$form->add('country_id', '', array('options' => $ops, 'type' => 'select'));

Are there any suggestions?

Harro

I populate them in a custom method, as I don't need them in normal use of the model, only if the model is used for CRUD operations.

// set the locale options with installed locales
static::$_properties['locale']['form']['options'] = \Config::get('exitecms.locales');

// set the country options
static::$_properties['country']['form']['options'] = \Lang::get('countries');

and this works fine. You should not use the constructor as that would mean you populate the options for every instantiation of the model. Which is not needed, the properties are static and thus global for all instances. Use the _init() method instead (altough I don't see why it would not work in the constructor).

Jelmer Schreuder

I have tried overwriting these detials into the constructor of the model but this doesnt seem to work. static::$_properties = static::country_dropdown_list();

Don't use the constructor, the constructor is only called upon object creation which is too late - at that point the properties have already been determined at the class level and it won't take another look. We have the _init() method for that reason, that's called right after the autoloader has loaded the class. Add "public static function _init() {}" and put it in there. Also you were using 'data_type' in the form setting, the data type is used at the property level to describe the property's data type. In the form settings you pass the input type, which uses just the key 'type'. To pupulate it after the form was created use:

$form->field('country_id')->set_option($ops)

amrussell

Excellent! Thanks guys. Is quite useful to see other projects built on Fuel. So looking through excitecms helped answer a few other questions that are not in the docs yet. Great work! ;-)

Harro

Can you give some feedback on that? We can use that to improve the documentation.

amrussell

It would be great to more publicly show the apps you guys (creators) have built with Fuel.
I have looked through a buch of code / packages which are great, but not much fully supports the ORM, or at least the more advanced bits such as the fieldset integration / relations.
There is a whole buch of other values that you are using in the the models in excitecms. These aren't documented anywhere, but sure they would be useful for some. :-)

Some of the bits regarding ORM docs:

        'gender' => array(
            'data_type' => 'varchar',
            'label' => 'Gender',
            'form' => array('data_type' => 'select', 'options' => array('m' => 'Male', 'f' => 'Female')),
            'validation' => array('required'),
        ),

Should be

        'gender' => array(
            'data_type' => 'varchar',
            'label' => 'Gender',
            'form' => array('type' => 'select', 'options' => array('m' => 'Male', 'f' => 'Female')),
            'validation' => array('required'),
        ),

It wasn't overly obvious why everything was a standard text filed.. Until I looked through the code... It would be useful to have the ORM data types documented, just for clarification...
I wasn't sure exactly what values it could handle, (enum, int unsigned, etc..), so maybe an explanation of level of support? Where is the best place to put form buttons? I guess in the _init() function. But not explained.. The _init() method isn't documents, and populating form values from a database is a fairly integral part of a form builders. ;-)

Here is some of my model, it might help someone: Here is a snippet from my $_properties array:

        'country_id' => array(
            'data_type' => 'char',
            'label' => 'Country ID',
            'validation' => array('required'),
            'form' => array(
                'type' => 'select',
                'options' => array(),
                'class' => 'xlarge',
            ),
        ),

And populating the country dropdown:

 public static function _init()
 {
  $countries = \Model_Country::find('all');

  foreach ($countries as $c)
  {
   $data[$c->id] = $c->country_name;
  }

  static::$_properties['country_id']['form']['options'] = $data;
 }

As always, thanks for sharing your code and thoughts. :-)

Harro

In general, you only keep the minimum in your models. Statically define the properties (like above), and add methods to the model to load data into the properties for the select options (which are only needed in crud operations on the model, there is no need to load them in all other uses of the model). All other form related stuff should be part of the fieldset, and belongs in the view (or viewmodel), as it is part of the presentation, and that imho includes "window dressing" like buttons, fieldsets, styling, custom field options, etc. This is also the place where I add extra fields to the fieldset, for fields that I need on the form but are no part of the model properties (for example 'confirm_password').

amrussell

hmmm.. Interesting. :-)

Statically define the properties (like above), and add methods to the model to load data into the properties for the select options (which are only needed in crud operations on the model, there is no need to load them in all other uses of the model).

How do you go about only loading the data for CRUD operations?

Harro

I have a Crud controller, which contains the basic code for the list, view, add, edit and delete actions. My controllers extend this controller, set the basic variables needed to operate, and some contain custom code in case the default actions are not sufficient. One of the variables set is $this->model, which is assigned a ORM Model instance using the forge() method of the model. In my Crud controller, in the edit action, I have a line:

method_exists($this->model, 'set_options') and $this-model->set_options();

which populates the select options at runtime. The Crud controller then creates a fieldset from the model, my controller may add custom fields to that, and passes the fieldset to a standard view which generates the form.

amrussell

It would be really interesting to have a look through some of the code relating to the above.
Do you have any public projects shared on github at all? (I dont believe all of what you suggest is in the current exitecms's code)
If not, would it be possible to share a few classes on scrapyrd or similar? Thanks again for your time.

Harro

The ExiteCMS code on github is only days old. I'll still working on the core. Getting the theme and widget engine running, being able to execute HMVC class to create widgets. Now that thats working I moved to crud operations, where the standard crud controller is nearing completion (it generates widgets like this: http://i.imgur.com/mHaQz.png). Most of this is already in the repo. I've now started with a crud controller for nested set tree structures, so you can store and maintain trees in the database, like page or folder structures. I just commit as I go along, and basically use the repo as a backup at the moment...

amrussell

Sounds good.
I look forward to having a snoop at your code once you push it. ;-)

As I said before, looking at how you guys use Fuel is useful to everyone. Maybe publish a page where these projects can be found easier?
In fact, do you know any other open projects written in Fuel that uses a substantial set of its codebase? Maybe a "Demo" or "Tutorial" application that uses ORM with relationships, auth, fieldsets, viewmodels, HMVC pattern, etc would be useful to some?
Might clear a few things up. I know this is a fair amount of work, and Phil has written some great tutorials on Net Tuts. But hey just a thought.. p.s. Go for post 1000! ;-)

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.

Howdy, Stranger!

Categories

In this Discussion