SitePoint Sponsor

User Tag List

Results 1 to 15 of 15
  1. #1
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Validating form *code*

    Hello all,

    I've been thinking (with my TDD cap on) about forms, and how form code kind of gets left out of the refactoring process. I see how form validation tests the input that a user sends, and how integration tests test the code that handles the form. The actual form code, though, is another source for potential bugs. Just today, I had a designer rename one of my fields accidentally, and it appeared like my code wasn't uploading a thumbnail image, so I spend a good half hour debugging my code and finally figured out that I wasn't receiving an image in php because the input field was named "thumb2" instead of "thumb". Bugs I can think of in the past, I forgot to add a field for a client's form or I forgot to rename a field.

    So what if I could create a spec for this form, and run it before creating the form. It could say "missing fields 'field1', 'field2', 'field3'. If I ran it on this form I was just talking about, it could say "missing field 'thumb', unnecessary field 'thumb2'". I could also run it after receiving code from a designer, to make sure they included everything they needed.

    What do you think? Useful? I feel like it would take a little bit of the headache out of refactoring forms.

  2. #2
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    251
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think you should use a presentation model if you want to do these kinds of checks. Basically, in addition to all the details relevant to a particular view, the model provides the field names that the controller is expecting. So instead of designers doing this...

    PHP Code:
    <input name="thumb2" /> 
    They do this...

    PHP Code:
    <input name="<?php echo $data->thumbFieldName ?>" />
    You can then throw errors when bad field names come through or see which field names aren't being used with a simple include and some __get magic. This allows you to write unit tests around these templates.

    This is an especially good approach if you can get your designers to use PDT, since then they can take advantage of the code completion features. They simply type $data->... and they get a list of all the info available to them.

    Having said that, you can obviously use something more XMLish -- DTD and XML Schema come to mind.
    Last edited by cuberoot; Nov 1, 2008 at 03:33.

  3. #3
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Personally, I think forms are far too complex to allow a designer to modify them. They can styled the outputted html, but they need to stay the flip away from the code it generates as it can be integral to the business logic that acts on the data it sends to the server. I build my forms using a sub-classed Zend_Form to take advantage of its form validation and data filtering. A designer can modify all the html surrounding the form, but not the form itself. If the form needs changing, they have to come to me and have me change it.

  4. #4
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cuberoot View Post
    I think you should use a presentation model if you want to do these kinds of checks. Basically, in addition to all the details relevant to a particular view, the model provides the field names that the controller is expecting.
    That sounds like a good solution that does about the same thing, but I feel like it's a little too demanding on the designer. I'd rather not change their workflow at all, and instead just have a way of verifying that every form contains the correct code.

    Quote Originally Posted by imaginethis
    Personally, I think forms are far too complex to allow a designer to modify them. They can styled the outputted html, but they need to stay the flip away from the code it generates as it can be integral to the business logic that acts on the data it sends to the server. I build my forms using a sub-classed Zend_Form to take advantage of its form validation and data filtering. A designer can modify all the html surrounding the form, but not the form itself. If the form needs changing, they have to come to me and have me change it.
    Generally the designer gives me the forms already built, and I wrap it into our CMS. In this case, he was making some modifications on the comments, and accidentally overwrote a field name. It's understandable, and I do it myself on occasion. I'd rather have a test to back us both up, and verify the code is correct, instead of forcing some unnecessary constraint on my coworker.

  5. #5
    Coding and Breathing CoderMaya's Avatar
    Join Date
    Feb 2008
    Location
    Atlit, Israel
    Posts
    470
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You can see how it's done here if it helps..

    http://retro-framework.com/productions/forms/forms.html
    Learn about the new Retro Framework
    Code PHP the way it was meant to be coded!

  6. #6
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve View Post
    That sounds like a good solution that does about the same thing, but I feel like it's a little too demanding on the designer. I'd rather not change their workflow at all, and instead just have a way of verifying that every form contains the correct code.



    Generally the designer gives me the forms already built, and I wrap it into our CMS. In this case, he was making some modifications on the comments, and accidentally overwrote a field name. It's understandable, and I do it myself on occasion. I'd rather have a test to back us both up, and verify the code is correct, instead of forcing some unnecessary constraint on my coworker.
    That's not an unnecessary constraint. Realistically, the only thing a designer should ever have to modify is a css file and a few non integral html files. But they should never have to modify something that can intern affect business logic. If they can't fix something they break, they shouldn't be touching it. You wouldn't expect a nurse to be performing heart surgery.

  7. #7
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    So what if I could create a spec for this form, and run it before creating the form. It could say "missing fields 'field1', 'field2', 'field3'. If I ran it on this form I was just talking about, it could say "missing field 'thumb', unnecessary field 'thumb2'". I could also run it after receiving code from a designer, to make sure they included everything they needed.
    Actually I think thats a nice idea, I just tried it on Selenium IDE, you can make a real simple page that contains literally just the form elements, and this bit of feedback:
    PHP Code:
    <?php

    foreach( $_POST as $k=>$v )
    echo 
    $k .'='$v ;

    ?>
    <form action ="" method=post id=from>
    <input type=text id=thumb>

    //your other necessary elements here

    <input type=submit>
    </form>
    ?>
    Then create a Selenium script containing lines like this:
    Code:
    //look in source view to see lines like this
    <tr>
    <td>AssertTextPresent</td>
    <td></td>
    <td>thumb=test</td>
    </tr>
    I am pretty sure you could automate a lot of that, especially the tests, then just tell Selenium a different target url when they have ponced up the page.

    In fact you should be able to pass the responsibility of passing the Selenium tests over to them before you get the pages back - its such a simple thing.

    I wonder if that the kind of thing you could automate from say, an ini file in a shared location.
    Last edited by Cups; Nov 4, 2008 at 09:48. Reason: php tags

  8. #8
    SitePoint Guru Ize's Avatar
    Join Date
    Nov 2005
    Location
    The Netherlands
    Posts
    809
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by imaginethis View Post
    That's not an unnecessary constraint. Realistically, the only thing a designer should ever have to modify is a css file and a few non integral html files. But they should never have to modify something that can intern affect business logic. If they can't fix something they break, they shouldn't be touching it. You wouldn't expect a nurse to be performing heart surgery.
    I actually believe it's the other way around (I have worked both as a back- and front-end developer so don't consider this favouritism).
    A front-end developer should create ALL markup and accompany that with a stylesheet.
    Then a back-end developer should only fill in the blanks, convert my Lorem Ipsum to database-driven content.

    A front-ender is, after all, the front-end code expert. Certainly when it comes to CSS and how elements react to eachother a solid template should be used, which is tested by a front-ender and which will not be altered by the implementing back-end developer.

    And a form is just another piece of HTML. The specific elements used might be necessary because of some style rules. A back-end developer shouldn't have to care wether input fields are wrapped inside a list or inside a fieldset, for example, and therefore never edit the form code. On the HTML side there's really nothing complicated about a form, as long as the correct names are in place and the correct values sent to the server, but that's got nothing to do with who writes that markup code.

  9. #9
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ize View Post
    I actually believe it's the other way around (I have worked both as a back- and front-end developer so don't consider this favouritism).
    A front-end developer should create ALL markup and accompany that with a stylesheet.
    Then a back-end developer should only fill in the blanks, convert my Lorem Ipsum to database-driven content.

    A front-ender is, after all, the front-end code expert. Certainly when it comes to CSS and how elements react to eachother a solid template should be used, which is tested by a front-ender and which will not be altered by the implementing back-end developer.

    And a form is just another piece of HTML. The specific elements used might be necessary because of some style rules. A back-end developer shouldn't have to care wether input fields are wrapped inside a list or inside a fieldset, for example. On the HTML side there's really nothing complicated about a form.
    Exactly. And most designers understand that renaming fields is going to mess with business logic. Everybody makes mistakes, and I'd just like a way to know about those mistakes without having to go through all my php code only to find out it wasn't receiving the right type of input.

    Quote Originally Posted by Cups
    I am pretty sure you could automate a lot of that, especially the tests, then just tell Selenium a different target url when they have ponced up the page.
    You've got the right idea. I have never used Selenium or SimpleTest's browser tester, but is it possible to change a form's target url before submitting it?

  10. #10
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ize View Post
    I actually believe it's the other way around (I have worked both as a back- and front-end developer so don't consider this favouritism).
    A front-end developer should create ALL markup and accompany that with a stylesheet.
    Then a back-end developer should only fill in the blanks, convert my Lorem Ipsum to database-driven content.

    A front-ender is, after all, the front-end code expert. Certainly when it comes to CSS and how elements react to eachother a solid template should be used, which is tested by a front-ender and which will not be altered by the implementing back-end developer.

    And a form is just another piece of HTML. The specific elements used might be necessary because of some style rules. A back-end developer shouldn't have to care wether input fields are wrapped inside a list or inside a fieldset, for example, and therefore never edit the form code. On the HTML side there's really nothing complicated about a form, as long as the correct names are in place and the correct values sent to the server, but that's got nothing to do with who writes that markup code.
    A form is more than just another piece of HTML. It sends information back to the server that is integral to application processes. There are a few places where the line of demarcation between front-end and back-end code blur and forms are one of them. I work in an office with several non technical people who use dreamweaver for everything they do and hold the title of "Web Designer". Countless times, they have gone into template files and made changes to code that have sent me on hour long expedition through classes and functions trying to figure out what I did wrong.

    On another note, you should maintain your own personal back files if your not using some sort of revision control system. That way you can run a diff on the files o the server and the files on your local system and see the difference between the two set of files.

  11. #11
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by imaginethis View Post
    Countless times, they have gone into template files and made changes to code that have sent me on hour long expedition through classes and functions trying to figure out what I did wrong.
    So wouldn't you rather have a test that tells you when something is wrong in the templates before you even look at your classes and functions? And before you accuse someone with tampering with your precious business logic?

    Quote Originally Posted by imaginethis View Post
    you should maintain your own personal back files if your not using some sort of revision control system. That way you can run a diff on the files o the server and the files on your local system and see the difference between the two set of files.
    I use SVN, but in order to run a diff between the files, I have to know that there's something wrong with one of the files. A test will tell me when I don't even suspect something's wrong, or when I suspect the problem is in the wrong place.

  12. #12
    SitePoint Addict
    Join Date
    Jan 2008
    Posts
    203
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    actually i have a simple way around issues like this

    I dont POST my forms via usual form post submit

    instead, all the values from the form field data is checked by javascript on the clientside (once submit or whatever event fires) and then put into a JSON datastructure, this gets in turn sent to the server for further checking/processing via AJAX POST request


    the designer can change the text input names (for example) to his hearts content but when it comes to running tests i quickly notice that variable is missing from the input altogether or is blank

    this separation makes it very easy to run tests, as the controller expects nothing more than json encoded data of particular structure

  13. #13
    SitePoint Guru Ize's Avatar
    Join Date
    Nov 2005
    Location
    The Netherlands
    Posts
    809
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by imaginethis View Post
    A form is more than just another piece of HTML. It sends information back to the server that is integral to application processes. There are a few places where the line of demarcation between front-end and back-end code blur and forms are one of them. I work in an office with several non technical people who use dreamweaver for everything they do and hold the title of "Web Designer". Countless times, they have gone into template files and made changes to code that have sent me on hour long expedition through classes and functions trying to figure out what I did wrong.

    On another note, you should maintain your own personal back files if your not using some sort of revision control system. That way you can run a diff on the files o the server and the files on your local system and see the difference between the two set of files.
    Absolutely! A form and its workings can be technical and complex. I'm just saying: the HTML that marks up the form has got nothing to do with that.

    And maybe the problem in your situation does not lie with the separation of front- and back-end per se, but, with no offence, with non-educated people getting slapped on the title "Web designer" too easy...

    Quote Originally Posted by ionix5891 View Post
    actually i have a simple way around issues like this

    I dont POST my forms via usual form post submit

    instead, all the values from the form field data is checked by javascript on the clientside (once submit or whatever event fires) and then put into a JSON datastructure, this gets in turn sent to the server for further checking/processing via AJAX POST request


    the designer can change the text input names (for example) to his hearts content but when it comes to running tests i quickly notice that variable is missing from the input altogether or is blank

    this separation makes it very easy to run tests, as the controller expects nothing more than json encoded data of particular structure
    But do you write a fallback method for users with Javascript disabled?

  14. #14
    SitePoint Addict
    Join Date
    Jan 2008
    Posts
    203
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ize View Post
    But do you write a fallback method for users with Javascript disabled?
    users with no javascript (0.x%), bots get show different views, more conventional forms

  15. #15
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve View Post
    So wouldn't you rather have a test that tells you when something is wrong in the templates before you even look at your classes and functions? And before you accuse someone with tampering with your precious business logic?



    I use SVN, but in order to run a diff between the files, I have to know that there's something wrong with one of the files. A test will tell me when I don't even suspect something's wrong, or when I suspect the problem is in the wrong place.
    No one touches my classes but me or another PHP programer and my templates have nothing in them that anyone can foo bar. Not to mention files that I don't wanted edited are own by root so there's no way anyone can access application sensitive files.

    If your using SVN you can get a report of files that have changed... So I'm not sure how that is a problem.

    Ize, I'm not sure I understand what your saying. How can the complexity of a form have nothing to do with the HTML that marks it up? And yes, the lack education of co-workers is a problem.


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •