best practices on Form Reuse - keeping all forms in a central location with validation

[eluser]Colin Williams[/eluser]
I'll just bow down to your greatness, Randy, cause you've flown over my head many occasions now, sending me scrambling to Wikipedia for clarification! Which reminds me why my I tell people I'm a "design and usability consultant" and not a "software engineer." I can imagine you've got some diagram floating around in your head (with pretty circles and arrows and labels) and I'm just wrecking the shit out of it every time I post a response!

I quit. I mean, if figuring out how to get a form to display on any page, validate in a central location, but still provide interaction between the form and validation results, so you can repopulate the form, yadda-yadda-yadda, is so extremely difficult that people can't sit down for 10 minutes and figure it out with a pencil and a notebook, then I'm not sure what good I can do here.

[eluser]chuckleberry13[/eluser]
Yeah I didn't follow the guard condition/state transitions talk either.

[eluser]JoostV[/eluser]
@chuckleberry:
A bit late, but no, in my example you don't have to alter the code in the library at all. The only thing you alter for every form is
-set up an an array in the controller
-initiate a new form object in the controller
-process the form, like below

Code:

if ($form->metadata['validated'] == true) {
    // process from using the values in associative array $form->form_results, e.g.
    // $this->db->set($form->form_results);
    // etc.
}
else {
    // Load view and pass $form->form_elements
}

In the view you will have an array of form inputs ($form->form_elements) that you can loop through for display. You can write a generic function for this display as well.

Works like a charm. And because the $form object has an ID you can use multiple forms in a single page, also widgets. All that you alter is an array in the controller and the code that you need to process the form.

[eluser]Randy Casburn[/eluser]
@Colin - @Chuckle -- OK off the deep end there a little...

So let me try a different way...

Let's say I'm building a Business Intelligence application with 12 data entry screens meant to collect a range of data from across an enterprise composed of finance, human capital, asset management, and provide an interface for imported data from other ERP systems.

While I'm not going to enumerate every form and field on every one of the 12 screens, we might imagine that we start to see Stores, and each Store has Inventory, and each Store and certain Financial Accounting to be done, and each Store has Human Resources to be paid, and maybe each Store is owned as a capital Asset. Now since each Store is in a Region each Region roles up the reporting of all the Stores in a Reqion and all the Regions get rolled up Nationally. All the data in the displayed on a central form screen where it can be sanitized before it is displayed to the Board of Directors.

If you think through this, you should come to the conclusion that a "financial form field" validation for a Store Accounting Page should work exactly the same way as a "financial form field" validation for a Human Resource payment calculation. Otherwise, you're duplicating your effort and you're going to create a separate validations for each of the 12 pages.

I hope this is clearer and less jargon like.

Randy

p.s. I have another question though. Where does all this "stuff" come from? Where does the definition of all this come from? Every form field for every form in every application you "design and make usable" "should" come from a data model (damn -- there I go again) that has been thought about in advance. The data model should be created from your form design mock up. Once you've eliminated all the duplication in your data model, you've removed all the duplication in your validation model! But hey...just sayin'

[eluser]chuckleberry13[/eluser]
@JoostV - Sorry I misunderstood your library then. I'll take a closer look .

@randy - Thanks that did make a lot more sense. The Business analogy was very clear as to the reason form elements need to be validated and not forms.

So you mentioned the data model should be the source for the form elements. This makes intuitive sense from the stand point that eventually forms fields will be sent to the data model to be saved into a db. But could you expound a little on how this should best be done?

Right now I take the $_POST array, iterate through it to clean up some of the number fields, make sure I only grab fields that were filled out (not blank) and then send that array to my data model which in turns saves it in the db. Are you saying the data model should have listed out each field, and the form is populated from that?

Thanks in advance Randy for taking your time to enlighten me and other newbies participating in the forums.

p.s. sidenote I just discovered ExtJS and saw in some other posts that you are familiar with it. This is off topic for this thread, but I would love to get some pointers from you on how to best work with ExtJS and CI. I currently use JQuery a lot, but nothing more than just including JS files in the header views and using an Ajax controller that handles some of the Ajax requests. I have an eerie feeling there is a better way .

[eluser]Randy Casburn[/eluser]
[quote author="chuckleberry13" date="1217119508"]So you mentioned the data model should be the source for the form elements. [/quote]

Darn it! -- there I go again. "Data model" was used in the context of a Requirements Engineering or Requirements Process terminology perspective. This is in contrast to implementing an MVC Model that actually moves HTTP REQUEST data from a POST array into a suitable format for storage. I did not mean to mislead you with that.

So a Requirements Data Model represents all the data needed by the User (actor) in the system that might show up in the UI. That doesn't mean all the data in the application, but certainly all the data in all the forms should be represented there. So your goal of consolidating forms/form elements/form validations etc. should really start with an understanding of all the data that is needed by the User in the UI interfaces. Hope this clarifies.


[quote author="chuckleberry13" date="1217119508"]p.s. sidenote I just discovered ExtJS and saw in some other posts that you are familiar with it. This is off topic for this thread, but I would love to get some pointers from you on how to best work with ExtJS and CI. I currently use JQuery a lot, but nothing more than just including JS files in the header views and using an Ajax controller that handles some of the Ajax requests. I have an eerie feeling there is a better way .[/quote]

Wrong thread. PM me and I'll discuss my heretic way with ExtJS that will also make sense to you. Simple, full architectural view without doing things that don't make sense on the server when only the client is needed.

Randy

[eluser]chuckleberry13[/eluser]
K, I see what you mean. Correct me if I am wrong, but basically what we are looking for is a data bank of all the possible data elements that could be requested in a form. That central data bank would then handle the validation and data prep functions.

I think the concept finally clicked. I thought of another reason why this would really be helpful. In my particular case I have tons and tons of form elements that are formatted in real-time with JavaScript to currency numbers (i.e. $10,000.00). Every time I store one of these elements in the db I have to clean them and strip them of their formatting (i.e. 100000). By having the data bank handle everything, I just need have it run those form elements through a comma stripping function every time that element is requested and submitted in a form and it doesn't care when or where the form is displayed. That would be sweet.

So JoostV's library has you create the array with the validation rules and everything in the controller and not storing the rules in a data bank like you are suggesting so that wouldn't work right? (@JoostV - seems like a great library and has given me some ideas already so I'm not saying anything negative about your library).

I went back and looked at your plugin and after our discussion I can now see more clearly what you are saying. One thing though, you said since you passed in the CI super object to your plugin, you can see what form elements are being included. How exactly do you do that? How do you search through the super object and see what form elements are being used?

[eluser]Randy Casburn[/eluser]
Glad it's clicking....and your example is great. Think "JS Spreadsheet" here...right?

How do you search through the super object and see what form elements are being used?

Now that you mentioned ExtJS, I can tell you that I rely on DOM query extensively for this type of "give me what's in the DOM" stuff.

Gotta Look....

Randy

[eluser]Colin Williams[/eluser]

How do you search through the super object

See for yourself:

Code:

print '<pre>'. htmlspecialchars(print_r($this, TRUE)) .'</pre>';

And I got where you were going, Casburn. Your suggestion fit your massive example perfectly. But the OP wondered:

I’m not sure how to go about this, is there an ideal way to reuse forms? I’d like to reuse a form (take a newsletter signup form), so I can include the form on multiple pages and have all the form and validation logic in 1 place.

is there an ideal way to reuse forms?

Yes. Put it in a View and $this->load->view() it where needed, when needed.

...validation logic in 1 place

That would be the Controller the form submits to.

If you really want to abstract your form generation and handling in a nice, tight system, I think you want to build a Form Controller that sits somewhere between the Front Controller and the requested Controller. And, how nice, there's a hook point for that!

[eluser]Randy Casburn[/eluser]
How nice...an observer pattern ;-) Exactly what every tidy MVC needs. Thanks Colin.

I think you're right about the wondering. And you're probably right about my making my example fit my stereotype. I can see that.

Randy