SitePoint Sponsor

User Tag List

Results 1 to 13 of 13
  1. #1
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    1 Thread(s)

    HTML in Model Code.

    I've come across one instance where I think it's ok to continue to place html in the model code - hidden fields. The return of hidden fields in my models looks like this:

    PHP Code:
    public function formData$formid ) {
            return array(
    'hidden' => '<input id="'.$formid.'_'.$this->name.'" type="hidden" name="data['.$formid.']['.$this->name.']" value="'.$this->data.'">');
        } 
    Fields that have normal form data have this function instead which the one above overrides

    PHP Code:
        public function formData$formid ) {
            return 
    array_merge($this->form, array(
                
    'value' => $this->data,
                
    'id' => $formid.'_'.$this->name,
                
    'name' => '['.$formid.']['.$this->name.']',
                
    'type' => (isset($this->form['type'])) ? $this->form['type'] : $this->type,
                
    'errors' => $this->errors
            
    ));
        } 
    That data is sent via the controller to this view template for text fields.

    PHP Code:
    <div id="<?= $id ?>_frame" class="inputCell <? if(count($errors) > 0) echo 'error' ?>">
        <label for="<?= $id ?>"><?= $title ?></label>
        <input id="<?= $id ?>" name="data<?= $name ?>" type="text" class="fieldInput" value="<?= $value ?>">
        
        <? if(count($errors) > 0): ?>
        <div class="tooltip error">
            <div id="<?= $id ?>_error">
                <h1>Errors</h1>
                <ul>
                    <? foreach ($errors as $error): ?>
                    <li><?= $error ?></li>
                    <? endforeach ?>
                </ul>
            </div>
        </div>
        <? endif; if ($description): ?>
        <div class="tooltip">
            <div id="<?= $id ?>_desc">
                <h1><?= $title ?></h1>
                <?= $description ?>
            </div>
        </div>
        <? endif ?>
    </div>
    Other types of fields have different templates.

    I'm trying to think if there will ever be a time that I'd have trouble with doing the hidden fields this way but I haven't been able to think of any at all since they are ostensibly invisible elements of the page that the user doesn't interact with.

  2. #2
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You're assuming the view will be html like. You're also making an assumption the script which will process the form submission is php(or otherwise supports php's array syntax for request variables).

    I'm more asking the question though, is it ok for the model to make such assumptions? My mvc experience is very limited.

  3. #3
    Twitter: @AnthonySterling silver trophy AnthonySterling's Avatar
    Join Date
    Apr 2008
    Location
    North-East, UK.
    Posts
    6,111
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Airing on the side of caution here, but shouldn't the model ALWAYS return data only?
    @AnthonySterling: I'm a PHP developer, a consultant for oopnorth.com and the organiser of @phpne, a PHP User Group covering the North-East of England.

  4. #4
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by crmalibu View Post
    You're assuming the view will be html like. You're also making an assumption the script which will process the form submission is php(or otherwise supports php's array syntax for request variables).

    I'm more asking the question though, is it ok for the model to make such assumptions? My mvc experience is very limited.
    Uhm, the function is called 'formData'. It returns the HTML form data of the field. For hidden fields I might as well just get the fact that the field is hidden and the whole object - that never changes. Ever.

    If I need other forms of the data I'd call other functions.

    Quote Originally Posted by SilverBulletUK
    Airing on the side of caution here, but shouldn't the model ALWAYS return data only?
    This is one function of the model. The model is responsible for managing data flow to and from the database and packaging it in the form requested. The formData method above returns not only the data on the field, but the other information about the field needed by the view to properly construct the input object.

  5. #5
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    If I need other forms of the data I'd call other functions.
    The model should return data, which is interpreted later into a HTML format. The model shouldn't really return anything as HTML.

    I emphasise should because it's completely upto the author. For some systems, the normal MVC approach is less efficient or over-the-top for the requirements - for others, straying from by-the-book MVC will cause big problems later.

    Forms are tricky to use as an example because they are rarely used outside of HTML - but I'll stick to Forms for the sake of keeping on topic.

    Say you have a form which is mainly for outputting to the browser - so goes through the HTML view to output it for the browser. But, in the near future you decide that you also want to output the form information to an external application, e.g. a desktop application for the user.

    There are multiple ways of communicating with this application, the most popular is XML - so you could have an XML view to output application-readable data.

    Now, if you have used views to output the data, this is quite simple - it's just a case of copying and going through the view files and making required changes - once you've done that, your application will be accessable to another system at the click of a finger.

    However, what if your views did SOME of the output, but so did the models? You're going to have to make larger modifications to allow for the application to handle multiple formats and, even worse, you need to go through many MORE files to find possible output and make changes.

    Bottom line is, it's generally easier to let only the views have the say on output. That way, you always know the first place to look for issues and make modifications, and it's much easier to allow output in multiple formats.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  6. #6
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    1 Thread(s)
    So is the description of the field a part of the data or the view? I say the data - because it changes. The formatting of that data (view) doesn't change as often.

    In a typical website there might be dozens of text input fields for first name, last name, address, etc. But for design consistency those fields should look the same, work the same, be drawn from the same template -- view. Only their names and descriptions change - that's data. Especially since I'm writing an interface to change such labels without having to touch the code, and those labels will be stored in the database.

    As for this line of reasoning 'what about non-HTML apps' -- who cares? If the day actually arrives that I need the model class to output data in a new way I'll EXTEND THE CLASS. Duh.

    I'm not writing a framework or system that wants to do everything. I'm writing one to handle web pages and forms. Frankly, if I want to deal with desktop application integration PHP is the last language I would want to work with - the moment HTML integration goes out the door all PHP's advantages are moot and it's time to go to Java or Python which are far better languages for those tasks.

    Further as long as I keep the classes granular and follow the doctrine of '1 function - 1 action' I can extend the classes to deal with corner cases as they arrive rather than fuss and fidget about possibilities that may never arrive and either never get the code at hand done OR have something that is way more complicated than it needs to be to accomplish the task at hand.

  7. #7
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Again, it all depends what you're after. However, the main point of MVC is that the VIEW handles all of the output, the MODEL handles the data and the CONTROLLER controls the main processing - so by not sticking to that, you are shying away from a very powerful (and proven) method of logic.

    By posting this thread you've opened your code and logic up to comments, and that's what we're giving you. If you're going to respond to those comments in a negative way and stick to firm ground about your ideas, what's the point in even asking about it? If it works for you that's great - but by removing a key element of MVC it simply doesn't make sense to actually implement it.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  8. #8
    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)
    I'm no MVC giant either, but I always understood Models return data - so I'll be upfront about my prejudice.

    I cant imagine Unit Testing a model class that outputs html, but its easy to do and the imaginary MVC rules are there for you to break as you see fit.

    When I first read your post I thought, ah, he needs what I have seen termed as a "view helper".

    The View can be far more than a template, and not everyone grasps that although I am sure you knew that already.

    When I was looking for some of the good view helper threads I had, I found this one, where you participate at the end talking about having two controllers in your Framework.

    I wonder, is your decision to output html directly from the model a cause of the effect of using Ajax in the view?

    If so, I am interested because I developed/evolved a simple non-MVC Ajaxian framework of my own containing almost direct links between views and the model.

  9. #9
    SitePoint Wizard bronze trophy devbanana's Avatar
    Join Date
    Apr 2006
    Location
    Pennsylvania
    Posts
    1,736
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I agree with Cups. You need a view helper.

    The model should really never output HTML. It's not a model then. You are mixing class responsibilities. Now the model is responsible for the data as well as the output.

  10. #10
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You might want to peruse some MVC frameworks for their approach on view helpers and specifically form helpers ... it's really not a super-easy thing to do right, in my opinion at least.
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  11. #11
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    I actually had this issue a while back. I'm constantly writing new frameworks to try out different approaches, and my models did return HTML.

    However, it gave one hell of a headache when designing web-services which output XML - useful for AJAX, Flash and Desktop applications.

    In my latest framework, I've got subdirectories in the Views directory, one for each format. Each has an identical file structure, but with their format output instead. The specific format is requested by the file extension, i.e. /article/view/3.xml would output the data in an XML format (though, as the article is stored in the db as HTML, it would be xml-escaped and inserted into a 'content' tag), whereas /article/view/3 outputs it as the default, HTML (I tend to avoid the html extention).

    It means that I simply need to add another subdirectory to the views directory, e.g. 'pdf', and make the required changes to the files inside. I can then output the article as a pdf file (after parsing the HTML into PDF format). Likewise with a 'txt' directory, 'zip' directory and, if I really wanted to kill my server, a 'jpg' directory!
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  12. #12
    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)
    I always consider hidden elements to be belonging directly to the form, more in the way that the form contains, an action, method, id etc it could contain one or more hidden elements.

    Does a hidden field have more in common with the parent form element than its siblings?

    That could provide another way of thinking about it.

  13. #13
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    1 Thread(s)
    I'm guessing what I'll do is move the assembly of the input hidden field to the function that prints the forms. I hesitate to create a view file for the hidden file type because it would add an unnecessary file read to the process.


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
  •