Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
ORM, Forms, Validation and DRY. Am I trying too hard?
  • I'm currently trying to rewrite a company web app using FuelPHP and am getting a bit flustered trying to determine how things can/should fit together. I think I may just be getting hung up with my DRY obsession. Sometimes separate but similar functionality needs to be tweaked in such a way that you're forced to repeat yourself, I'm trying to fight it at every angle but perhaps it's a losing battle. I'm starting on my first form that will POST to create a new database entry and decided to take the ORM route. Below is roughly the road I've taken to get where I am right now. First, I see that you can(should?) list all your columns in the $_properties array of your model. You can also add your form details and validation info, cool! I'll do just that then and let Fieldset::forge() figure out what to do. Wait, I don't want the dateCreated to show up on the creation form. I'll just set form type to false like the docs say. Hmm, label still shows without a field, I'll set the label to false and now it's gone. What if I want it to show in the future though for an edit form? Why does Fieldset still create empty table row HTML for fields that aren't displayed? OK, maybe that isn't a good route to go, I'll just manually specify every field I want for creation in its own separate function and pass that in with the add_model() call. That works, now to validate it. I should be able to populate a model instance with Model_mymodel::forge(Input::post()). OK, now to validate using all those validation rules I set in $_properties(). Check docs and online tutorials, everyone is manually adding each field to the validation instance. Alright, guess I can do that too. Surely I can just pass my populated module to the validation instance though. Not sure, in one of the tutorials listed here (http://www.trovster.com/blog/2011/03/fuelphp-forms-and-validation/), the author manually sets each property on his model while manually running validation on each input. Docs say you can pass a fieldset instance to Validation::forge(), so on the POST request, I have to first fill the fieldset with the values, then pass to validation, if it then passes, I can fill my model so I can run save()? At that point, why even bother with $_properties()? I'm trying to figure out as much as I can myself, often diving in to the source code of fuel to figure things out that aren't covered in the docs or tutorials but there's only so much I can get from there. I'd like to know how someone very familiar with the capabilities of the current Fuel framework would do this. Thanks.
  • Thanks for the info and sorry for the late reply. I have since upgraded to v1.1 and it has taken care of the extra table markup issue. Still outputs a bunch of linefeeds but I can live with that. I'd still appreciate direction regarding the issues in my first post. I think it mostly just comes down to knowing when I should expect Fuel to do things for me and when I should expect to have to roll things myself.
    Should I bother putting form formatting and validation in $_properites() if I'm going to use the same model for different forms (create/edit)?
    Are my DRY ambitions too big? Etc. Don't get me wrong, I'm not complaining against Fuel, despite the issues I've had learning I would overall say I still like it and wish to continue with it. As I've stated in a past thread, I've worked with PHP before but I've been out on all the framework development that has been going on. Thus I seem to keep getting hung up in the area of what I should expect a framework to provide for me and when I should just do things myself. Thanks.
  • Imho validation should be part of the properties. No matter where the data comes from, if your validation rules are different based on the source of the data, you have a design issue. As for formatting info, I don't think that should be part of the model properties. I keep mine to the minimum needed for the model to do it's work. As for the fieldset input (the "form" key of the property) I set the generic ones (including type if needed) and have specific methods for populating things like the select options, as I don't need those every time. The rest of the formatting, including generating the fieldset, happens in the view.
  • I agree with everything what WanWizard said. To remember when approaching a problem like this: only put data & functional descriptions in your model, there shouldn't be any markup settings in there.
    Thus you would put the form field type in there, as well as some other settings describing the field. But you don't put a key 'style' => 'width: 200px;' in there. Never. Seperate the concerns as in any decent usage of MVC. A model describes the data it works with and provides functionality to work with it. The model shouldn't know or care about the app logic (belongs in controller) or markup (belongs in view(model)).
  • Moved to the ORM forum, as this is mainly an ORM model related question.
  • I don't have time to go into everything but the following should have been fixed in 1.1 final:
    I'll just set form type to false like the docs say. Hmm, label still shows without a field, I'll set the label to false and now it's gone. What if I want it to show in the future though for an edit form? Why does Fieldset still create empty table row HTML for fields that aren't displayed?

    Are you still using RC1?
    You can also echo out individual field using $fieldset->field('name') instead of the full form.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion