SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 38
  1. #1
    SitePoint Enthusiast
    Join Date
    Aug 2004
    Location
    leeds
    Posts
    58
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    MVC - How to integrate with designers?

    Hi,

    I've just been reading an example of an MVC pattern at http://www.phppatterns.com/index.php...leview/19/1/1/. I know some people are saying this isn't an exact MVC pattern but this doesn't really affect my question.

    I was hoping to get into design patterns etc to try and remove all of the PHP code out of my HTML pages etc etc to allow the designers at my company to hand me HTML files that could easily integrate with our code.

    From looking at this example all off the HTML output is generated from the 'view' class. This would make it even harder to integrate with the designers using this method. Is it possible using patterns to develop what is essentially a CMS that designers could supply the static HTML pages for and integrate easily?

    Thanks

  2. #2
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This would make it even harder to integrate with the designers using this method.
    In what manner? The View portion of the MVC pattern generates the web page it's self, based on what data is provided by a Model. How the actual implementation works, is upto yourself in that regard.

    In my view (and I know other members disagree with me) there shouldn't be any PHP within HTML at all... Is this the concern that you have, in regards to your designers I wonder? I don't specifically believe in putting PHP in an HTML template.

    What I do on the other hand, is to have a given tag, ie <body /> which is replaced with content as it is generated. Any specific presentation logic (for example, alternating rows of colour, putting negative numbers in red, etc) are handled by View Helpers, which return the generated HTML fragment back to a View class.

    As for a CMS, the guts of it would be based on MVC, but there still would need to be application specific responsibilities such as authentication, for example. Hope that helps, I'd be interested in knowing what your concerns/problems are though

  3. #3
    SitePoint Enthusiast
    Join Date
    Aug 2004
    Location
    leeds
    Posts
    58
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    You are kind of along what I was asking. Like you, I don't want any PHP within my HTML templates. That way the designers can update the templates etc without messing up the code. My concern was in the example I used above they generate the HTML from within PHP which would make things even more awkard.

    Without getting too complicated, is it possible using MVC to have an HTML template that is accessed from the PHP view controller and spat back out again?

    Thanks

  4. #4
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Code:
    From looking at this example all off the HTML output is generated from the 'view' class. This would make it even harder to integrate with the designers using this method. Is it possible using patterns to develop what is essentially a CMS that designers could supply the static HTML pages for and integrate easily?
    Actually it will be easier. As Dr Livingston says, the view can be a simple template handled by a template manager.

    A very good example, that I am using, is this:

    In the template I have something like this:

    Code:
    <DIV id="mydiv" runat="server">
       div content here....
    </DIV>
    And then, in the PHP script I parse the template and replace the DIV tag with whatever I choose.

    So, for the designers to do their job, all they have to do is to stay away from those runat="server" attributes. That's all.

  5. #5
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My concern was in the example I used above they generate the HTML from within PHP which would make things even more awkard.
    This isn't really a concern as much as you may think it is I ponder? The content that I replace for the most part is usually a DIV with some content. It is then upto the designer to style that given DIV via CSS.

    Looking deeper at the quote I think you're concerned with the HTML that you may have within a PHP function or class(es), from what I can gather? Well, as much as you shouldn't put PHP in HTML, you shouldn't put HTML in a function or class(es), for the exact same reasoning (as I see it anyways, again, some members will disagree with me).

    All HTML that I have are in a file, even something as simple as this,

    Code:
    <div>hello <user />, and welcome. Today is <timestamp />.</div>
    As you've noticed, if you have HTML with a function or class(es) you the developer, need to go back and make the changes, whereas the designer is inhibited in that respect that they can't (or won't).

    Another down side of the developer making the changes for HTML, is that it is time consuming, it's a distraction and also more to the point, it is a cause for introducing errors, not only in the markup but the class(es) as well.

  6. #6
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mammoo
    From looking at this example all off the HTML output is generated from the 'view' class. This would make it even harder to integrate with the designers using this method. Is it possible using patterns to develop what is essentially a CMS that designers could supply the static HTML pages for and integrate easily?
    This is interesting; assume we do as in this example, and generate the HTML output by assignments in PHP code. One problem this creates is that if keep the HTML/PHP mixture, but otherwise refactor it nicely, we will be more and more stuck with the mixture. The reason is that refactoring tends to create small classes and methods, so the HTML markup get more and more fragmented and harder to separate.

    The alternative for the ProductView classes in this example is to generate a data structure instead of the finished HTML code and feed that to a template. IMHO, the template engine needs looping and a simple conditional test, that's all.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  7. #7
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    IMHO, the template engine needs looping and a simple conditional test, that's all.
    The looping mechanism would be variable in this case, as would the conditioning. In this case, I'd proberly throw a View Helper at it. It is easily enough to script a View class to manage the generation process for a given request, but not so easily to maintain if the given View class has to manage all eventualities.

    By removing these eventualities (as View Helpers), you remove the dependencies. So if a set of conditions (on a certain resultset) change, you don't change the View class, but the given View Helper it's self... You swap one out, and have another one ready to replace it.

  8. #8
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    IMHO, the template engine needs looping and a simple conditional test, that's all.
    This is how it is:

    We need some presentation logic, period. Sometimes as simple as "replace this token with that value" or "write this content 15 times", and sometimes more complex, as "if the number is negative show it in 50-point bold red". That code has to go somewhere, and that can be either of:
    1. PHP (View)
    2. templating language
    3. transformation language (e.g. XSLT)
    4. some combination of the above
    That's it. It's up to the programmer whis approach to use.

  9. #9
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I tried to use XSLT with my current project and I became quite happy with it.

    If someone really wants to completelly separate PHP from the templates, XSLT is a very good option.

    There are 2 big problems though. It is not as easy to learn and in PHP4 there is no native support for XSLT parsing. But otherwise it's great.

    IMHO, the template engine needs looping and a simple conditional test, that's all.
    That's not true. You need something more complex than that. I have seen about a dozen template managers started because their creators wanted something simple, but they all winded up being, well ... Smarty like .

    The truth is a complex problem like this cannot have a simple answer.

  10. #10
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The truth is a complex problem like this cannot have a simple answer.
    In regards to Smarty and their like, this may be difficult or tedious to implement but just how complicated can it be to separate presentation logic from the business logic of generating the output?

    The feeling I get, is that (because) Smarty is well known, despite it's own failings, it's popular because for the vast majority of web sites, it's relatively easy to implement. The problem is when you have complex presentational logic to content with, and this is where Smarty falls down.

    A lot of people don't forsee this problem, and try to workaround it by thinking that they can in some way, build the complex presentational logic (via Smarty) into the template, and it just doesn't work. It doesn't work because you have to change the template to allow for change to the presentational logic, and in most cases, this will require you to change the script (Views) as well as one example.

    Smarty is a tool, and it has it's uses, but it's not the grand saviour it's all made out to be, in my view it has too many limitations to be used for anything more than semi-static web pages.

    I have my own thoughts, and I could put forward a few suggestions, but I'm sure regular members are now fed up with me pimping one solution though.

  11. #11
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    When I think about this some more, I think the better solution would be to move the thought process (of us developers) away from the 'Template Engine' mentality, and move towards the mentality of seeing the webpage, and it's structure as separate entities, ie

    They're all generated equally, and separately on their own plain. There is no convergence between the 'News Items', and the 'Todays Poll' structure sections. Each is equal, and equally separate in how they're generated, in the context of the MVC pattern.

    Going down that road, this gives you the ultimate flexibility and control, doesn't it?

  12. #12
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mammoo
    I was hoping to get into design patterns etc to try and remove all of the PHP code out of my HTML pages etc etc to allow the designers at my company to hand me HTML files that could easily integrate with our code.

    From looking at this example all off the HTML output is generated from the 'view' class. This would make it even harder to integrate with the designers using this method. Is it possible using patterns to develop what is essentially a CMS that designers could supply the static HTML pages for and integrate easily?
    I think it is been said already, but I just want to be clear that HTML templates and MVC have nothing to do with each other. Further a application using MVC has alll the same parts as any other application -- it just has specific separations and dependencies. MVC doesn't create a new type of application, it just organizes an application using some best practices.

    You can certainly use HTML templates with any PHP application.
    Christopher

  13. #13
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mammoo
    Is it possible using patterns to develop what is essentially a CMS that designers could supply the static HTML pages for and integrate easily?
    If you start from the designer's viewpoint, what do they want?

    They don't want lots of little html files. They want a complete page to edit, the way they're used to working. They can't see how everything will bounce off each other otherwise. Does that pale blue header really work with a tree-frog green body background?

    They want to be able to preview pages in an ordinary browser without having to run it through a server. They may not have one set up locally and they may not know how. They certainly don't want to upload files to a live site for each and every change. You make lots of little, fiddly changes when you're designing and have to preview them all.

    They don't know anything about programming. They're designers. They'll scream the house down if you expose them to the simplest of php code.

    Perhaps the best way to deal with that is to have two types of template: a designers version with no php code and a "compiled" version used to serve live pages.

    The designers want to write something like this:

    Code:
            <h2>account holder: mcgruff</h2>
            <p>balance: £2,000.00</p>
            <p>transactions:</p>
            <ul>
              <li>+£50.00</li>
              <li>+£23.00</li>
              <li>-£31.12</li>
            </ul>
    The php app has to provide the data, namely:
    - account holder name
    - total balance
    - a list of transactions

    Also, overdrawn balances should be shown in red so php will have to set a boolean flag and apply the style conditionally.

    The designer's template will need to add some (non-browser-printing) tags so that, later, the template compiler can replace chunks of html with php code. for example:

    Code:
             <h2>account holder: <name>mcgruff</name></h2>
             <p>balance: <total overdrawn_style="color: red;">£2,000.00</total></p>
            <p>transactions:</p>
             <ul>
               <transaction_item><li>+£50.00</li></transaction_item>
               <li>+£23.00</li>
               <li>-£31.12</li>
             </ul>
    Which provides all the information you need to compile:

    Code:
             <h2>account holder: <?php echo $name; ?></h2>
              <p>balance: 
              <?php
            		 if($account_is_overdrawn) {
     			 echo '<span style="color: red;">' . $total . '</span>';
            		 } else {
            			 echo $total;
            		 }
               ?>
            </p>
             <p>transactions:</p>
              <ul>
              <?php
            	  while(false !== ($transaction = $transactions->next())) {
            		  echo '<li>' . $transaction . '</li>';
            	  }
            </ul>
    As far as application layering goes, the php app just grabs a set of data and makes that available to the (compiled) template. In the compiled template, there is some simple, presentational code only.

  14. #14
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    This is how it is:
    We need some presentation logic, period. Sometimes as simple as "replace this token with that value" or "write this content 15 times", and sometimes more complex, as "if the number is negative show it in 50-point bold red".
    That does satisfy my criterion, since it's a simple if test. But in this case, for the sake of the Web designer, I probably wouldn't put that logic into the template. Instead I would generate a variable beforehand containing a CSS class name that indicated negative or positive. Something like this (arbitrary Smarty-like template language):
    Code:
    <td class="{$numberclass}">{$number}</td>
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  15. #15
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So your presentation logic is not in the template here, is it? IOW, if we reduce it to extreme, a template really needs nothing but simple variable placeholders, right?

  16. #16
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have participated at a couple of discussion allready on this forum and all degenerated into "What should a template manager be like"

    This is kind of funny actually.

    BTW: I haven't heard any thoughts on XSLT ! Haven't anyone tried it ? Or maybe everyone tried it and it is too awfull ? I just wanna know.

    Here is a XSLT example:

    Code:
       <td class="{$numberclass}">{$number}</td>
    
       will be in XSLT
    
       <td>
           <xsl:attribute name="class">
              <xsl:value-of select="numberclass" />
           </xsl:attribute>        
           <xsl:value-of select="number" />
       </td>
    Is that really that hard ?
    XSLT is platform independent, can do everything by itself without PHP support, and best of all, there are XSLT capable visual editors.
    With XSLT you can really say you have separated the presentation layer from the business objects.

  17. #17
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    These are actually two different beasts altogether. While most PHP templates follow the Template View pattern, XSLT is an example of the Transform View.

    The usual problem with XSLT is that most developers don't know it, and indeed it has a different philosophy than most languages. For most of them it's easier to apply Template View and put presentation logic in a language they are familiar with instead of learning a new language altogether.

    Having said that, I am well aware of the advantages of XSLT, and have used it many times. The lack of good support in PHP before version 5 has put me off of using it more extensively on server side, though.

  18. #18
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    So your presentation logic is not in the template here, is it? IOW, if we reduce it to extreme, a template really needs nothing but simple variable placeholders, right?
    Not quite. I want looping so I can show a list without a predefined number of elements. I also want if tests for something like an extra button that can only be seen by a privileged user.

    I'm not saying this is the only right way to do it; it's what seems to me like a reasonable minimum of program logic in a template.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  19. #19
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    If you start from the designer's viewpoint, what do they want?

    They don't want lots of little html files. They want a complete page to edit, the way they're used to working. They can't see how everything will bounce off each other otherwise. Does that pale blue header really work with a tree-frog green body background?

    They want to be able to preview pages in an ordinary browser without having to run it through a server. They may not have one set up locally and they may not know how. They certainly don't want to upload files to a live site for each and every change. You make lots of little, fiddly changes when you're designing and have to preview them all.

    They don't know anything about programming. They're designers. They'll scream the house down if you expose them to the simplest of php code.
    I agree 100%. That's why I like PHPTAL; it allows you to do this kind of thing. Here's your example (minus the red color just to keep it simple):

    Code:
    <h2>account holder: <span tal:replace="name">mcgruff</span></h2>
     <p>balance: <span tal:replace="balance">£2,000.00</span></p>
     <p>transactions:</p>
     <ul tal:repeat="item transactions">
       <li tal:content="item">+£50.00</li>
       <li tal:replace="">+£23.00</li>
       <li tal:replace="">-£31.12</li>
     </ul>
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  20. #20
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    These are actually two different beasts altogether. While most PHP templates follow the Template View pattern, XSLT is an example of the Transform View.
    You've got me here. What is the difference ? What is a template view and what is a transform view ?

  21. #21
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bonefry
    You've got me here. What is the difference ? What is a template view and what is a transform view ?
    That's http://www.martinfowler.com/eaaCatal...plateView.html vs. http://www.martinfowler.com/eaaCatal...sformView.html . And more on http://www.martinfowler.com/eaaCatalog/.

    For more details, I strongly recommend http://www.martinfowler.com/books.html#eaa

  22. #22
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bonefry
    Is that really that hard ?
    Yeah, it kinda is. The XSL syntax can be pretty damn ambiguous at times - plus, being XML, it's a horrible bloat, as you demonstrated yourself.
    XSLT is platform independent, can do everything by itself without PHP support, and best of all, there are XSLT capable visual editors.
    With XSLT you can really say you have separated the presentation layer from the business objects.
    Well, yeah, kinda. What bugs me is that afaik you need an actual XML file to transform, which is sub-optimal in numerous cases. Generating that XML is slow, and if you need to do it dynamically based on each request... ouch.

    Unless I'm horribly mistaken, that is.

  23. #23
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    What bugs me is that afaik you need an actual XML file to transform, which is sub-optimal in numerous cases. Generating that XML is slow, and if you need to do it dynamically based on each request... ouch.
    Note that you don't actually need to have an XML string -- a DOM representation of one, either parsed or built dynamically, is just fine.

  24. #24
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    So your presentation logic is not in the template here, is it? IOW, if we reduce it to extreme, a template really needs nothing but simple variable placeholders, right?
    There's a Java templating engine called StringTemplate, whose author strove for the strict minimum of logic. The language itself supports only four things:

    1. Attribute reference,
    2. Conditional includes,
    3. Template references, which can be recursive, and
    4. Aplying templates to multi-valued attributes.


    The last requires a bit of explanation. Say you want to output a list of users; to do that, you create a listItem template, and then within your page template, you call your listItem template with the syntax "$users:listItem()$". This then applies the listItem template to every single value of the users array, like using the array_map() function. This is a very simple example, there is additional functionality (like applying the results of a template to another template, or alternating between several templates) that allows you to build very complex structures.

    Using these four abilities, you can do everything a templating language needs to be able to do; anything it can't do is (in the author's opinion at least, but he presents his case very well) not presentation logic, and belongs somewhere else. To take care of things like escaping HTML, which doesn't belong in the model or controller layer either, you use an additional layer he cals the Renderer, which mostly takes care of converting data from the model into a format usable by the View.

    Unfortunately, there's no PHP version as of yet, but it's a project I've had on my mind for a while...

  25. #25
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    Using these four abilities, you can do everything a templating language needs to be able to do; anything it can't do is (in the author's opinion at least, but he presents his case very well) not presentation logic, and belongs somewhere else.
    I read the paper a while ago. It's extremely interesting and well worth reading, but I disagree with the idea that the template engine should enforce the model-view separation. I prefer to push even presentation logic out of the templates, to the extent that it's practical.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais


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
  •