SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 58
  1. #1
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Wink Awesome new PHP template engine

    While pondering Vincents comments on PHP templating systems, I was stuck by a flash of inspiration... A templating so good it would;

    - Have XML like tags in HTML for replaceable content.
    - Require no intermediate processing or specialised template language
    - Support loops, if:else etc.
    - Be incredibly easy for PHP developers to learn

    Here's what it looks like to use...

    PHP Code:
    <?php
    /* index.php */

    /* Include fictional data access class */
    include("classes/Dao.php");

    /* Connect to database */
    $dao=new Dao ("dbhost","dbname","dbuser","dbpass" );

    /* Include awesome template engine */
    include("classes/AwesomeTemplateEngine.class.php");

    /* Fire up template engine */
    $path "/home/user/www/templates/";
    $awesomeTemplateEngine= new AwesomeTemplateEngine($path);

    $dataObject=$dao->fetchObject("SELECT name, email, signature FROM users ORDER BY name");

    $awesomeTemplateEngine->parseTemplate($dataObject,"viewuser_template.php");
    ?>

    <?php
    /* viewuser_template.php */
    ?>
    <html>
    <head>
    <title>View User</title>
    </head>
    <body>
    <?php
    foreach ($dataObject as $dataChild) {
    ?>
    <p>Name:<?php echo ($dataChild->name); ?>
    <p>Email:<?php echo ($dataChild->email); ?>
    <p>Signature:<?php echo ($dataChild->name); ?>
    <?php
    }
    ?>
    </body>
    </html>
    And the Awesome Template engine...

    PHP Code:
    <?php
    /* AwesomeTemplateEngine.class.php */
    class AwesomeTemplateEngine {
        var 
    $templatePath;
        function 
    AwesomeTemplateEngine($templatePath) {
            
    $this->templatePath=$templatePath;
        }
        function 
    parseTemplate($dataObject,$template) {
            include(
    $this->templatePath.$template);
        }
    }
    ?>
    One for Hotscipts?
    Last edited by HarryF; Aug 19, 2002 at 23:11.

  2. #2
    will code HTML for food Michel V's Avatar
    Join Date
    Sep 2000
    Location
    Corsica
    Posts
    552
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    And I had put so much hope in that single click on the topic's name

    Anyway, that's the coolest template engine Easy to work with, too
    [blogger: zengun] [blogware contributor: wordpress]

  3. #3
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ( This is where you'll find Vincents prime rant about templates BTW. )

    I've been very bad... Hotscripts here we come...

    Actually going back to Vincents rant, the way we build templates at the moment is along the lines of the application defines the user interface. What Vincent suggested as the ideal thing for templating is where a design builds a user interface and the application reads them and "builds" itself.

    Been looking at XML Schema's recently and methinks this is just around the corner. A designer could use something like xmlspy to build an interface, the underlying schema being generated automatically. This then defines the behaviour of the UI, the database structure and everything in between. Don't think XML Schemas have everything needed to do that yet but when something turns up, rest assured it will be AwesomeTemplateEngine V2

  4. #4
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As you may or may not know, I'm STILL finishing my graduation project (as a matter of fact, I'm presenting it next week), which is a database application framework written in PHP. I was thinking about what it did the other day and how it did it, and I found that you could say it's a template engine...

    My 'template engine' however is responsible for generating ALL HTML, so it's not possible for the designer to say what HTML he wishes to see. There are no template HTML files with special symbols a la Smarty; instead the configuration of the framework uses CSS-like configuration files (not XML, because that's not what it's for - sorry Harry!). An example:

    PHP Code:
    albums
    {
        
    forms
        
    {
            
    album_tracker typetrackertablealbum; }
            
    album_search  typesearchtrackeralbum_tracker; }
            
    album_pager   typepagertrackeralbum_tracker; }
            
    album_view
            

                
    typerecord_view;
                
    trackeralbum_tracker;
                
    fields
                
    {
                    
    title           { }
                    
    length          typestatic_time; }
                    
    cover           typeimage; }
                    
    artist.showname { }
                }
            }
            
    track_view
            
    {
                
    type  relation_view;
                
    table track;
                
    parentalbum_tracker;
                
    fields
                
    {
                    
    no     { }
                    
    title  { }
                    
    length { }
                }
                
    orderno;
            }
        }
        
    layout
        
    {
            
    typeborder;
            
    westalbum_search,album_pager;
            
    centeralbum_recordtrack_view;
        }

    (Yes, this could be done with XML as well, but it takes a lot longer to parse, and is much less readable by humans!)

    This little piece of configuration defines the page 'albums', which shows three forms (as defined in the 'layout' section). On the left there are a search form and a pager, and on the right (the largest part of the screen) there is a recordview (showing the currently selected record in the pager). Under the current record (an album) is a list of tracks on that album.

    As you can see, there is no HTML/XML in the configuration anywhere. Granted, my framework is mostly aimed at database applications, but I can use it to implement other sites as well.

    In the configuration, you can change many things:
    - Use a different layout type to change the way the various forms are presented. The type 'border' (BorderLayout) is a popular one, but there are others (TableLayout, FlowLayout, and so on).
    - Use a different form type to show a completely different form. On this configuration there are a 'pager', a 'search', a 'record_view' and a 'relation_view'. But there are many, many more. (And they can easily be added to.)
    - Each type (be it a form, a layout, or something else completely) defines it's own properties. For example the borderlayout defines the properties 'north', 'west', 'center', 'east' and 'south'. Other layouts don't use these properties, so you can't even define them in the configuration if you use a different layout.

    So where is the HTML? It's in the components. When the method show() is called on a layout, it generates the HTML necessary to show the components on the layout in the right way. A simple layout (like the FlowLayout) just calls show() on all components on the layout and nothing more, while the BorderLayout generates an HTML table around the components. A Form-component knows how to show its title and its frame, but not how to show it's contents; the contents are defined by the widgets on the form (as described in the configuration), and each widget knows how to draw itself. And of course, the form again uses a layout to show its widgets.

    So how do you influence the HTML? By default every type of component uses its own CSS-class to draw itself. (Every widgets uses class 'widget' for example), but this is overridable in the configuration file by specifying a 'css' property. This gives a flexible and simple way to change the way the different elements on the page are shown. I have made two applications on my framework as of yet, looking nothing alike. Both designs came from a designer, and I have been able to incorporate it in the site without writing any PHP code. Just placing css-properties in the configuration and defining these in the CSS was enough.

    Apart from being a template engine, the framework has many, many properties:
    - It's completely object-oriented.
    - It uses an intelligent cache.
    - It can be extended by application programmers (simply write a new 'Form'-derived class, register it in a text file by giving it a typename e.g. test_form, and it can immediately be used in the configuration by specifying 'type: test_form;'). It's as easy as that.
    - It generates ANSI-SQL queries, and resolves joins betweens tables completely by itself. (In the album_view above for example you see the field 'artist.showname'. In the database schema there's a one-to-many relation between artists and albums, and the system finds these by itself. Between tracks and albums is a many-to-many relation, which also doesn't need to be specified in the configuration of the page.)
    - It can use any database system supported by my Eclipse library. Currently that's MySQL, PostgreSQL, MS-SQL and Sybase, and more are on the way.
    - It's multi-langual. All texts on the site are translated from symbols to strings using simple dictionaries. A user can change it's locale after which the site switches to another language dynamically.
    - It's extensible. Application programmers can define their own forms, widgets, layouts, (and more), either by subclassing an existent component, or by writing a new one from scratch.
    - And lots more!

    When I started on this project, the aim was to generate database administration sites easily. I'm almost finished now, and I can certainly do what I aimed for. And lots more, I have also used the framework to implement other (non-)database driven websites. Implementing a site is a simple matter of writing a configuration file and an appropriate CSS file. Something you can do in one or two days.

    The biggest difference between my 'template engine' and others is the way I treat HTML: I use it like Delphi or Visual Basic use the Windows API to generate Windows GUI's. The HTML isn't important; it's what on the page that is. Smarty (and others) concentrate only on the HTML being shown. It parses some input HTML to extract the special symbols; replaces the symbols with HTML, and produces HTML again. It's HTML all the way. For me, HTML is only interesting on the output-side of the framework.

    Vincent

  5. #5
    No. Phil.Roberts's Avatar
    Join Date
    May 2001
    Location
    Nottingham, UK
    Posts
    1,142
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Which is all very great from an application-developer point of view. But templating systems are designed primarily for designers. And as such are REQUIRED to be 'HTML all the way' simply because the whole point of them is to divorce them from any kind of program logic and allow designers to come up with their pretty layouts in a familiar coding environment where they dont need to worry about mucking up the backend.

    Granted, many template systems re-introduce program logic in the forms or loops and if-then-else constructs. But these arnt neccesary.
    THE INSTRUCTIONS BELOW ARE OLD AND MAY BE INACCURATE.
    THIS INSTALL METHOD IS NOT RECOMMENDED, IT MAY RUN
    OVER YOUR DOG. <-- MediaWiki installation guide

  6. #6
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I completely agree with you.

    But I don't see why designers should have to work with HTML. (Not that they would want to work with my configuration files, but that's not the point.) A designer not only doesn't want to work with PHP, he really doesn't want to work with HTML either. Give a designer a nice GUI, let him/her paint, draw, drag and drop, and store the design in some easy-to-use format, which likely won't be HTML (but could be XML). When the designer is done, use a separate tool to transform the special design-format to HTML, with an easy to use PHP-API (or ASP/JSP) to supply the contents of the special blocks. That way, designers won't be bothered with HTML, nor will the programmers. Because why would a programmer want to work with HTML?

    Vincent

  7. #7
    SitePoint Member
    Join Date
    Sep 2001
    Location
    UK
    Posts
    24
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by voostind
    A designer not only doesn't want to work with PHP, he really doesn't want to work with HTML either. Give a designer a nice GUI, let him/her paint, draw, drag and drop, and store the design in some easy-to-use format, which likely won't be HTML (but could be XML).
    I agree. As we move towards an XML/XSLT basis this will become much more important. We're fussing over logic within current templates (such as Smarty ones) and yet when you look at XSLT the logic's even further mixed in. And yet I don't think this is a problem, because it is presentation logic. The only problem is that designers won't stand a chance - and so every time they change the design we'll be tweaking the XSLT again by hand to match the new design.

    It will be interesting to see who comes out with a visual tool combining the design, generation of XSLT and data management - from what little I've read about XSLT I don't belive that it will be possible to separate the data structure from the design, because of the necessesity of embedding the logic/tags. So who does the role of converting the design to the XSLT fall to? My guess is that it will still be the programmer...

    Peter

  8. #8
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It will be interesting to see who comes out with a visual tool combining the design, generation of XSLT and data management - from what little I've read about XSLT I don't belive that it will be possible to separate the data structure from the design, because of the necessesity of embedding the logic/tags. So who does the role of converting the design to the XSLT fall to? My guess is that it will still be the programmer...
    That's a real interesting topic. If I can dare to re-word what Vincent is advocating - application development should be done from the bottom up, not the top down. This obviously contrasts with user interface design, which works from the top down.

    What's needed, as far as XSLT is concerned, is a mechanism where by the data being sent up from below to the "XSLT layer" and the interface design above the XSLT layer are "mapped" together. In other words, generation of XSL style sheets needs to be an automatic process.

    And when talking about user interface design, it's not even (X)HTML and perhaps not even the placement of application "components" such as form elements. Just visuals.

    As someone pointed out somewhere, an HTML tag like;

    Code:
    <input type="text" name="myfield" maxlength="50">
    ...is the job of the developer not the designer.

    Interesting reads I've been looking at recently are XSL-FO (Formatting Objects), XForms and XHTML / XML Schema components.

  9. #9
    SitePoint Member
    Join Date
    Sep 2001
    Location
    UK
    Posts
    24
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by HarryF


    That's a real interesting topic. If I can dare to re-word what Vincent is advocating - application development should be done from the bottom up, not the top down. This obviously contrasts with user interface design, which works from the top down.
    I've never come across development top down/bottom up before, can you explain what it means.?

    What's needed, as far as XSLT is concerned, is a mechanism where by the data being sent up from below to the "XSLT layer" and the interface design above the XSLT layer are "mapped" together. In other words, generation of XSL style sheets needs to be an automatic process.
    .. and yet, how can it be so, without someone deciding where tag XXX fits into the layout?

    And when talking about user interface design, it's not even (X)HTML and perhaps not even the placement of application "components" such as form elements. Just visuals.

    As someone pointed out somewhere, an HTML tag like;

    Code:
    <input type="text" name="myfield" maxlength="50">
    ...is the job of the developer not the designer.
    I think that the placement should be up to the designer, as this affects the design and usability of the application. I'd also query form elements as being the domain of the developer - because most designers I've come across want to heavily style them (so maybe it's no bad thing to have them in the developer's domain ). But I take your point - for the designer it'd be just as meaningful to draw a rectangle and colour it how you want the form input to look.

    Peter

  10. #10
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OK - first of all - let me retract that about re-wording Vincent (as no doubt I've got things wrong).

    I've never come across development top down/bottom up before, can you explain what it means.?
    That's my wording (there's probably jargon which I don't know to describe this).

    But the point is, how do you design an application?

    Do you start with the user interface (the HTML) - draw all the pages users will see, then put the code/database behind them? This is probably what alot of web developers do?

    Or do you start with the database, putting together a database structure then from there, write the code on top and finally the user interface?

    Or do you even start somewhere in the middle - code first then database and user interface as you need them?

    It's a real interesting topic for converstation. In the PHP world, in my opinion, as most developers start at the top and work down, they end up using things like templates to seperate HTML from their code. But if they worked "from the bottom up", perhaps they'd use object orientation to generate the user interface (e.g. form controls in ASP-speak). Or perhaps they'd do some clever stuff with XML...

    .. and yet, how can it be so, without someone deciding where tag XXX fits into the layout?
    Here's my thinking on that. In a typical PHP app, in a database you already have a "schema" which describes the data stored there.

    Step 1. is turn the db schema into an XML schema.

    Step 2. in your PHP code, you read the schema, use some XSLT and convert it into another schema, taking advantage of something they're working on at W3 - Modularization of XHTML to XML Schema. You're schema now describes not only the data but what type of "user interface element" is should be part of.

    Step 3. now run a query on the database and turn the result set into XML and attach the schema you ended up with in Step 2.

    Step 4. perform another XSLT to turn the XML from step 3 into XHTML, using the attached schema to work out what the user interface should be (on the fly).

    Step 5. display the user interface.

    Now that only works from the "bottom up" - needs some more thinking about how to get the designer involved (no answers there right now).

    I think that the placement should be up to the designer, as this affects the design and usability of the application.
    I agree. Perhaps the solution is rather than the designer working with HTML, XSL or whatever, instead you, the application developer, give the designer a list of "components" which you've made yourself. They can then place the compenents as they choose. If your components are designed flexibly enough, the design can tell them what color they should be etc.

    Although that kind of ends up back with the current problem of templates - you force designers to learn your language.

    The perfect solution, in my opinion, is if the designer can draw pictures which your application reads and turns into a user interface. Course we're a long way from there...

  11. #11
    SitePoint Wizard Crowe's Avatar
    Join Date
    Nov 2001
    Location
    Huntsville
    Posts
    1,117
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    HarryF

    This is awesome. Any chance of seeing the Dao.php class?
    Chrispian H. Burks
    Nothing To Say

  12. #12
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Funny you should say that I've just put up a demo of what I've got so far (which is next to nothing);

    http://www.pinkgoblin.com/pagoda/

    I'm not going to be implementing the underlying database classes (you can turn to Vincent and Eclipse for that - ps Vincent - I haven't forgotten the Oracle class - still on the to do list). Also the Schema generation is poor right now - it's way to big: you can optimise XML schemas by defining your own data types within them.

    As said - not interested in doing the underlying classes. Here's why - the Schema building should be able to work from any source - not just a database. Up above;

    Step 1. is turn the db schema into an XML schema.
    I want this also to work for a web services source (XML-RPC or SOAP) - the good news is they already come with schemas, so you can begin straight away with Step 2.

    That way you can really start thinking about n-tier PHP.

    Anyway - all in the future - oooo for some clones or infinite time

  13. #13
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Oh and one further point.

    So far we've only talked about generating pages. What about user feedback (like they fill in a form)?

    We're also in good shape there, having built an XML schema - somehow we can then use that to validate the data the user sends back the application (which is is what schema are for after all). More thinking to go there as well - can't completely see it right now as I'm a long way from there.

    One essential peice that is missing is a PHP class which can validate an XML file against a schema. The only person I've seen with anything like that is Dietrich Ayala and NuSOAP: http://dietrich.ganx4.com/nusoap/APIDoc/XMLSchema.html - not complete either. Anyone want to take a shot?

  14. #14
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Have put together a document describing Pagoda plan: https://sourceforge.net/docman/displ...group_id=63100

    If anyone want's to help out just say the word

  15. #15
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Going back to the subject of templates, there's an interesting article here: http://www.webkreator.com/php/techni...templates.html

    This describes the process of creating an application as being one of three ways;

    Push - the developer goes to town then gets in the designers at the end

    Pull - the designs rule and the developer suffers

    The Third Way

    Personally, I believe that too many people focus on templating mechanisms than on the concept of templating itself. They forget that they need to do the task of separating the design and they focus on creating a new "templating language". I like to keep it simple by using the PHP languate itself for templates as well. This is easily done by having one file that contains only the php code (performs actions and created objects) and the other file that contains the design with minimal amounts of php code that is used only to extract the necessary information from existing objects. The biggest danger with this approach is that content separation is not enforced, and you can make that short cut when you are pressured for time.
    Makes some interesting brief comments about the current template systems as well;

    Smarty has become increasingly popular recently. It essentially creates a whole new programming language.

    PHPLib is a programming framework and it includes a solution for templates.
    Of course he's the creator of XCS (http://www.webkreator.com/php/xcs/) the XML-RPC class server... (a truly awesome script in my opinion)

  16. #16
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Isn't that what I have been saying all along?

    Vincent

  17. #17
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Exactly! Just wanted you to know that you're not alone

  18. #18
    SitePoint Enthusiast Digital.Knight's Avatar
    Join Date
    Jun 2002
    Location
    Canada
    Posts
    25
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by voostind
    I completely agree with you.

    But I don't see why designers should have to work with HTML. (Not that they would want to work with my configuration files, but that's not the point.) A designer not only doesn't want to work with PHP, he really doesn't want to work with HTML either. Give a designer a nice GUI, let him/her paint, draw, drag and drop, and store the design in some easy-to-use format, which likely won't be HTML (but could be XML). When the designer is done, use a separate tool to transform the special design-format to HTML, with an easy to use PHP-API (or ASP/JSP) to supply the contents of the special blocks. That way, designers won't be bothered with HTML, nor will the programmers. Because why would a programmer want to work with HTML?

    Vincent
    Sounds like Adobe GoLive 6 to me! ;-)
    Cheers...
    -Brian

  19. #19
    killall -9 lusers
    Join Date
    Oct 2002
    Location
    Cincinnati, Ohio, USA
    Posts
    390
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Actually, the template class presented in the first message is extremely useful with one small modification. Instead of:

    PHP Code:
    <?php
    /* AwesomeTemplateEngine.class.php */
    class AwesomeTemplateEngine {
        var 
    $templatePath;
        function 
    AwesomeTemplateEngine($templatePath) {
            
    $this->templatePath=$templatePath;
        }
        function 
    parseTemplate($dataObject,$template) {
            include(
    $this->templatePath.$template);
        }
    }
    ?>
    I would use:

    PHP Code:
    <?php
    /* AwesomeTemplateEngine.class.php */
    class AwesomeTemplateEngine {
        var 
    $templatePath;
        function 
    AwesomeTemplateEngine($templatePath) {
            
    $this->templatePath=$templatePath;
        }
        function 
    parseTemplate($dataObject,$template) {
            
    ob_start();
            include(
    $this->templatePath.$template);
            
    $strParsedTemplate ob_get_contents();
            
    ob_end_clean();
            return 
    $strParsedTemplate;
        }
    }
    ?>
    By capturing the output in a buffer, you are able to store the parsed template in a variable, otherwise the method would just display the parsed template wherever it was called.

  20. #20
    SitePoint Enthusiast Digital.Knight's Avatar
    Join Date
    Jun 2002
    Location
    Canada
    Posts
    25
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Being a newbie I find myself impelled to ask what is probably one of the simplest of questions to all of you... What is a Class and how is it used with regards to PHP: the end product?
    Cheers...
    -Brian

  21. #21
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    By capturing the output in a buffer, you are able to store the parsed template in a variable, otherwise the method would just display the parsed template wherever it was called.
    When I get a moment, I might just update the AwesomeTemplateEngine with that Would certainly freak people out to know that PHP is actually capabable of caching.

    Being a newbie I find myself impelled to ask what is probably one of the simplest of questions to all of you... What is a Class and how is it used with regards to PHP: the end product?
    It's a simple question to which you could write whole books answering Classes allow you to write object oriented code. This allows you to save massive amounts of time, makes your code easy to read and understand, makes your code reusable (you should never need to write the same thing twice again) and easy to maintain. And a whole host of other benefits. So you know, if you don't use classes, your're writing procedural code which these days is regarded as deader than dead by most serious developers.

    To get you started, check out the Advanced PHP Resources in particular Kev's Object Oriented PHP: Paging Result Sets.

    For a kind of example of how you could use OO to build an application, try: OO PHP App Design.

  22. #22
    killall -9 lusers
    Join Date
    Oct 2002
    Location
    Cincinnati, Ohio, USA
    Posts
    390
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So you know, if you don't use classes, your're writing procedural code
    Not necessarily, you could be writing functional code. Or, you could be writing procedural code that uses classes. I think a lot of people who are new to the idea of using classes end up doing this for a while until they really get it.

  23. #23
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think there's an important separation between templating systems we need to take into account in this discussion

    Most people who talk about template systems will probably use the first form. They have some PHP code which parses {placeholders} and replaces them with variables. This way the programmer still controls what content is displayed.

    Reversed Templating (I think that's what it's called) is different, as it 'tells' the underlying code what to do, instead of the code telling the template what to display. In one of my scripts, I use a language like this:

    Code:
    {section name="news" nr="20"}
      {header}<ul>{/header}
    
      <li>
        <a href="/news/{$id}">{$title}</a>
        {$content-truncate(250)}
        {#if-forSubscriberOnly#}
          This news is only for subscribers!
        {/#if}  
      </li>
    
      {footer}<ul>{/footer}
    {/section}
    This piece of code tells the underlying code that it needs to display 20 articles in the 'news' section/category. Systems like these are important in true Content Management Systems if you ask me, because the client needs to be able to control the content on his page (what and how it's displayed) without having to have a programmer write the script to get the data (from a database or something).

    Now I just asked one of my clients how he would feel if he'd had to learn some PHP code instead of my own {template} language. He said he would have no problem with it, because using PHP itself as the templating system would add much more functionality to the 'templating language'. I think most clients would be in favour of this as well.

    Think about it: whether you have to learn some weird and restrictive and complex template language like Smarty (even Smarty can't accomplish everything and it's underlying code is quite complex already ) or you have to learn PHP, which is not restrictive (you can do anything you want) and it's not complex code for the programmer to write, because it's all native PHP functions.

  24. #24
    killall -9 lusers
    Join Date
    Oct 2002
    Location
    Cincinnati, Ohio, USA
    Posts
    390
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In thinking about this, I realized that one (and in my mind the only) advantage of templating systems like Smarty is the fact that a string like "{ArticleHeadline}" will be displayed in a WYSIWYG design tool whereas "<?= $ArticleHeadline ?>" would not display because the system would treat it as an HTML tag. When creating the 'template', it is easier for the designer to see the end effect of what a page will look like when different text formatting is applied if the text actually displays in the editor.

    Does anyone know of a good way around this other than having to insert dummy text, format it, and then replace it with the PHP tag?

  25. #25
    SitePoint Enthusiast Digital.Knight's Avatar
    Join Date
    Jun 2002
    Location
    Canada
    Posts
    25
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by HarryF

    It's a simple question to which you could write whole books answering Classes allow you to write object oriented code. This allows you to save massive amounts of time, makes your code easy to read and understand, makes your code reusable (you should never need to write the same thing twice again) and easy to maintain. And a whole host of other benefits. So you know, if you don't use classes, your're writing procedural code which these days is regarded as deader than dead by most serious developers.
    Just to make sure I'm understanding you correctly, would it be correct to say that a class is basically a module, a multi-use code snippet?

    To get you started, check out the Advanced PHP Resources in particular Kev's Object Oriented PHP: Paging Result Sets.

    For a kind of example of how you could use OO to build an application, try: OO PHP App Design.
    Thanks Harry, I'll starting digging into this right away!
    Cheers...
    -Brian


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
  •