SitePoint Sponsor

User Tag List

Page 10 of 16 FirstFirst ... 67891011121314 ... LastLast
Results 226 to 250 of 384
  1. #226
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I see. That'll be the way to solve the problem.
    We could name it ValidationError to prevent future confusion ?
    How about this :
    PHP Code:
    /**
      * Just a simple buffer for logging messages to
      * @implements ILogger
      */
    class Logger
    {
        var 
    $messages = Array();

        function 
    log($str) {
            
    $this->logMessage(new LoggerMessage($str));
        }

        function 
    logMessage(&$message) {
            
    $this->messages[] =& $message;
        }

        function 
    isEmpty() {
            return 
    count($this->messages) == 0;
        }

        function 
    getMessages() {
            
    $result = Array();
            for (
    $i 0$l count($this->messages); $i $l; ++$i) {
                
    $result[] = $this->messages[$i]->toString();
            }
            return 
    $result;
        }

        function 
    getMessageObjects() {
            return 
    $this->messages;
        }

    // end class Logger

    class LoggerMessage
    {
        var 
    $str "";
        var 
    $relation NULL;

        function 
    LoggerMessage($str$relation NULL) {
            
    $this->str $str;
            
    $this->relation $relation;
        }

        function 
    toString() {
            return 
    $this->str;
        }

        function 
    getRelation() {
            return 
    $this->relation;
        }
    // end class LoggerMessage 
    The LoggerMessage would be a nice place to put in a method for localizing the message.

    Edit:

    This implementation works transparently with the old Logger class
    Last edited by kyberfabrikken; Jul 29, 2005 at 06:56. Reason: better implementation

  2. #227
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Umm...

    Not yet all the responses since the last post I made, but I will. In the meantime,

    This is way I am filter thosen odes, because I only want the nodes and the properties of it to use in the page.
    Have you looked at Decorators? I can't tell at the moment if you have, sorry.

    I am planning to define a basic set of permissions for objects/node types in a configuration file, which can then be overriden through settings on a per user/role/object instance and object property base.
    Not yet implemented at this time, but I'd like to allow the parent to over-ride one, any or all children below it as well. If you have any ideas on how to do this, I'd welcome to hear about them

  3. #228
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wdeboer
    Proof of concept
    Ok, thanks. I didn't think of that one. I doubted between Point of Contact and Playboy on Campus
    Last edited by nacho; Jul 29, 2005 at 05:35. Reason: my english sucks

  4. #229
    SitePoint Zealot
    Join Date
    Jul 2005
    Posts
    194
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Umm...
    Have you looked at Decorators? I can't tell at the moment if you have, sorry.
    Yes, indeed, but why would I want to use decorators to filter out nodes that aren't needed :/


    Not yet implemented at this time, but I'd like to allow the parent to over-ride one, any or all children below it as well. If you have any ideas on how to do this, I'd welcome to hear about them
    If I know how I can implementate it, you will know it too

  5. #230
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, indeed, but why would I want to use decorators to filter out nodes that aren't needed
    And why not? I do, and they don't actually reflect on any other part of the system, in a manner that could be seen as being intrusive?

    If I know how I can implementate it, you will know it too
    Keeping us all informed, that'd be very much appreciated

  6. #231
    SitePoint Zealot
    Join Date
    Jul 2005
    Posts
    194
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    And why not? I do, and they don't actually reflect on any other part of the system, in a manner that could be seen as being intrusive?
    Any chance you could show me it, how you would do it? Not that I would touch that project today, currently trying to tackle my form problem

  7. #232
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here is a short example,

    PHP Code:
    // ...
    $dom = new DomDocument();
    $dom -> load'sample.xml' );
    $fragment $dom -> documentElement -> childNodes;

    $walker = new XmlWalker$fragment -> item) -> childNodes );
    $adapter = new DecoratableXmlAdapter( new XmlAdapter$fragment -> item) ) );
    $walker -> walk$adapter );
    // ... 
    PHP Code:
    interface IAdapter {
    public function 
    getComposite();
    }

    class 
    XmlAdapter implements IAdapter {
    private 
    $composite;
    public function 
    __construct$fragment ) {
    $this -> composite = new Composite$fragment );
    }

    public function 
    getComposite() {
    return 
    $this -> composite;
    }

    public function 
    pushDomElement $fragment ) {
    // ...
    }

    private function 
    traverseIComposite $compositeDomElement $fragment ) {
    // ...
    }
    }

    class 
    DecoratableXmlAdapter implements IAdapter {
    private 
    $decoratable;

    public function 
    __construct$decoratable ) {
    $this -> decoratable $decoratable;
    }

    public function 
    getComposite() {
    return 
    $this -> decoratable -> getComposite();
    }

    public function 
    pushDomElement $fragment ) {
    // ignore all nodes bar the one we require
    if( $fragment -> nodeName == 'node' ) {
    $this -> decoratable -> push$fragment );
    }
    }

    So, if the node in question is not a node by the name of 'node', it's ignored, such as in the following example of XML below,

    Code:
    <?xml version="1.0" encoding="utf-8"?>
    <nodes>
    <node>
    <id>0</id>
    <parent></parent>
    <name>Home</name>
    <pathname>home/</pathname>
    <node>
    <id>1</id>
    <parent>0</parent>
    <name>Contacts</name>
    <pathname>home/contacts/</pathname>
    </node>
    <!-- other nodes go here -->
    </node>
    </nodes>
    So, the nodes by the name of Id, Parent, etc are ignored, as we are only interested in knowing and processing the ones by the name of Node, as it's this node, that has the details we want, as it's child nodes

  8. #233
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    Ireland
    Posts
    349
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wdeboer
    currently trying to tackle my form problem
    This is what interests me at the moment. I have something in my head, and I think I will try to implement it (though probably not until Tuesday). Unless you are already working on something?

  9. #234
    SitePoint Zealot
    Join Date
    Jul 2005
    Posts
    194
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have been trying something, but it ain't real succesful yet. Need to come up with something good, to take all the current GET/POST data from the previous form to the next etc.

  10. #235
    SitePoint Zealot
    Join Date
    Jul 2005
    Posts
    194
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In one of the examples mentioned in this thread, a empty( $value ) is used to check if the variable is empty or not. This should be modified into strlen( $value ) > 0 because it will causes problems when the value is 0.

  11. #236
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wdeboer
    In one of the examples mentioned in this thread, a empty( $value ) is used to check if the variable is empty or not. This should be modified into strlen( $value ) > 0 because it will causes problems when the value is 0.
    Uhm, excuse me?
    PHP Code:
    $str "";
    strlen($str) > 0// false
    !empty($str); // false 
    I didn't get it. Empty is quite alright.

  12. #237
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think wdeboer refers to the fact that empty returns true when you evaluate a string with a value of 0. Because input will be a string, if it takes the value 0 it won't validate, while it could very well be a valid value.

    From a snippet of code posted previously in this thread:
    PHP Code:
    class Validator
    {
        function 
    validate() {
            if (isset(
    $_REQUEST['foo']) && !empty($_REQUEST['foo'])) {
                return 
    'VALID';
            }
        }

    If $_REQUEST['foo'] takes the value of '0', it will not validate.
    There’s more than one way to skin a cat.

  13. #238
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by nacho
    I think wdeboer refers to the fact that empty returns true when you evaluate a string with a value of 0. Because input will be a string, if it takes the value 0 it won't validate, while it could very well be a valid value.
    Ah, most true. I misunderstood him. Sorry.

  14. #239
    SitePoint Zealot
    Join Date
    Jul 2005
    Posts
    194
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yeah, it toke me 15 minutes to found out. Why selecting a No radio button in my form, still causes the Required error All fixed now

  15. #240
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hey kyberfabrikken, ezku, overrunner, et al.

    Did we ever talk over how controllers handle MVC? Take the case following files:

    app/action/MyForm.php
    app/model/MyFormModel.php
    app/view/MyFormView.php
    app/template/MyForm.html

    How does the controller do something like the following:
    PHP Code:

        $db 
    = new DB($Config);
        
    $template = new Template();

        include 
    'app/model/MyFormModel.php';
        include 
    'app/view/MyFormView.php';

        
    $view = new MyFormView($template);
        
    $model = new MyFormModel($db);

        return 
    $view->render($model); 
    This is not actual code but just something to show the things the Controller needs to do. It seems like some kind of MVCMapper is needed that you pass 'MyForm' to and it either does the loading and instaniating or returns Handles.

    The DB and Template objects are pretty common and are often used widely enough that they might be created earlier because they need config info for connection info, base template dir, etc.

    Any thoughts?
    Christopher

  16. #241
    SitePoint Zealot Overunner's Avatar
    Join Date
    Mar 2004
    Location
    Sweden
    Posts
    180
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi

    Your code example is pretty much what I would call an Action (mini-MVC-controller). I haven't found the View-classes any useful though. I build the entire page in the Actions directly, something like this:
    PHP Code:
    class ListCustomers extends Action
    {
      function 
    execute(&$request, &$response)
      {
        
    $db DatabaseFactory::create('MySQL');
        
    // Query for the customers...

        
    $tpl = new Template('customerList.html');
        
    $tpl->assign('title''Page Title');
        
    $tpl->assign('customers'$customerList);
        
    //...

        
    $response->appendContent($tpl->capture());
      }

    If you want to achieve more separation, you could let the Action handle the database stuff and pass any neccessary data to a View object which assembles the View.
    Quote Originally Posted by arborint
    It seems like some kind of MVCMapper is needed that you pass 'MyForm' to and it either does the loading and instaniating or returns Handles.
    My current approach of the whole process is as follows: First of all, I plug a ControllerMapper (which maps a request of type index.php?section=Home&action=Index to the HomeController for example) into a MapperChain and pass the Chain to the FrontController. If the mapping was successfull, the FrontController should've recieved a handle (concrete controller) from the mapper, which will be executed.
    I have 2 types of controllers: ActionController, which handles simple ActionMapping and ApplicationController, which handle different states and such.
    A concrete version of these controllers defines what actions the controllers may perform and what permissions the user must have in order to execute them. (Inspired by Limb). For example:
    PHP Code:
    class Home extends ActionController
    {
      function 
    defineActions()
      {
        return array(
          
    'Index'       => array('name' => 'Index',
                                 
    'path' => 'Home/'),
          
    'Information' => array('name' => 'Information',
                                 
    'path' => 'Home/'),
          
    'Secure'      => array('name' => 'Secure',
                                 
    'path' => 'Home/',
                                 
    'credentials' => array('Admin')),
          );
        }

      function 
    defineDefaultAction()
      {
        return 
    'Index';
      }

    When the controller gets executed, I extract the action parameter from the URL and find what action it maps to in my map (above). Then the action gets created and executed (if the user has enough credentials. Otherwise, I'll issue a redirect.) The action in turn creates the template, assign template vars etc, and appends the content to the response (for possible further processing). The end result will get echo:ed in the last InterceptingFilter.
    Quote Originally Posted by arborint
    The DB and Template objects are pretty common and are often used widely enough that they might be created earlier because they need config info for connection info, base template dir, etc.
    Hm? I'm not sure that I follow your reasoning here, but what has the configuration to do with where you create your objects?
    I simply include a config.php-file which defines a bunch configuration constants, like base template dir and such. I can then use them wherever and whenever I want . I will however spread out the configuration a bit by placing the TEMPLATE_DIR config for example in the same file I have my Template class.
    I'm not too keen having a configuration object which I'll need to pass wherever it is needed, which is probably everywhere!

  17. #242
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Overunner
    Your code example is pretty much what I would call an Action (mini-MVC-controller). I haven't found the View-classes any useful though. I build the entire page in the Actions directly, something like this:
    PHP Code:
    class ListCustomers extends Action
    {
      function 
    execute(&$request, &$response)
      {
        
    $db DatabaseFactory::create('MySQL');
        
    // Query for the customers...

        
    $tpl = new Template('customerList.html');
        
    $tpl->assign('title''Page Title');
        
    $tpl->assign('customers'$customerList);
        
    //...

        
    $response->appendContent($tpl->capture());
      }

    If you want to achieve more separation, you could let the Action handle the database stuff and pass any neccessary data to a View object which assembles the View.
    I think the primary goal of MVC is to separate the M from the VC. The script above looks like a Transaction Script with the M and V combined. It is the easiest to do, but the danger is that if you want another page like this one you make a copy of this page, but then you have two similar Models. I think a purpose of putting the Models in their own files is that it greatly increases the chance that they will be reused.

    If you movend the database code out of your example and just have a Model object available then all that is left is the View (which you call an Action). I think that would be a better separation. So is is most practical for the View create the Model like this?
    PHP Code:
    class ListCustomersView extends View
    {
      function 
    execute(&$request, &$response)
      {
        include 
    'model/ListCustomersModel.php';
        
    $model = new ListCustomersModel();

        
    $tpl = new Template('ListCustomers.html');
        
    $tpl->assign('title''Page Title');
        
    $tpl->assign('customers'$model->getCustomerList());
        
    //...

        
    $response->appendContent($tpl->capture());
      }

    Quote Originally Posted by Overunner
    Hm? I'm not sure that I follow your reasoning here, but what has the configuration to do with where you create your objects?
    I simply include a config.php-file which defines a bunch configuration constants, like base template dir and such. I can then use them wherever and whenever I want . I will however spread out the configuration a bit by placing the TEMPLATE_DIR config for example in the same file I have my Template class.
    I'm not too keen having a configuration object which I'll need to pass wherever it is needed, which is probably everywhere!
    I'm not sure the best way to handle this. You create the object locally using global defines. I was thinking that perhaps these common objects could be created before we get to this point and be available to any controller that follows (perhaps through a Locator class).
    Christopher

  18. #243
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Overunner
    Your code example is pretty much what I would call an Action (mini-MVC-controller). I haven't found the View-classes any useful though. I build the entire page in the Actions directly
    Quote Originally Posted by arborint
    The script above looks like a Transaction Script with the M and V combined
    I can appreciate that. Either I will do as overunner, or I will use ServerPages. Either way, I don't see the need for another object between the Action and the Template.
    If the view should become very complex, I might need some further seperation between V and C. In that case I will use viewhelpers for solving it.
    The main difference is that the full arsenal is only rolled out when and if it's needed, rather than forcing it upon even simple views, where it just becomes overhead. The catch of course is that the programmer need to be aware of what he's doing.

    About globals, configuration and databaseconnections - We have discussed already the idea of passing a context-object through the controllers, rather than ($request, $response). This object would be a good place to place all the globals.

  19. #244
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I can appreciate that. Either I will do as overunner, or I will use ServerPages. Either way, I don't see the need for another object between the Action and the Template.
    If the view should become very complex, I might need some further seperation between V and C. In that case I will use viewhelpers for solving it.
    The main difference is that the full arsenal is only rolled out when and if it's needed, rather than forcing it upon even simple views, where it just becomes overhead. The catch of course is that the programmer need to be aware of what he's doing.
    I think I understand. But if this is the case then neither you nor Overrunner are using MVC. You have the controller dispatch a Transaction Script that combines the M and V. The Action does some separation of M and V using a Template, whereas the ServerPage does it all in a PHP script. I think this is probably the easiest way to do PHP, but again it is not MVC.

    That is why I was suggesting here that we create a Handler that supports dispatching Model and VIew that are in different files. Another solution would be to add getModel() and getView() functions to the Controller. That might be the right place to put it and would allow the mappings (i.e. paths to model and view directories) to be set before the Controller is dispatched. Hmmmmm....
    Quote Originally Posted by kyberfabrikken
    About globals, configuration and databaseconnections - We have discussed already the idea of passing a context-object through the controllers, rather than ($request, $response). This object would be a good place to place all the globals.
    I have been thinking about this too. I have never liked a Context object because it seems very framework specific rather than a flexible, general solution. As I recall Struts/Mojavi use a Context object. Perhaps just passing a generic Locator that can hold any objects that your specific implemetation needs to have available.
    Christopher

  20. #245
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I have never liked a Context object because it seems very framework specific rather than a flexible, general solution.
    It doesn't have to be like that, as you see:
    Perhaps just passing a generic Locator that can hold any objects that your specific implemetation needs to have available.
    In which case the Locator would equal the Context as it is now, which kinda negates your point. Call it a Locator, sure, but we're still talking about the same thing.

  21. #246
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    You have the controller dispatch a Transaction Script that combines the M and V. The Action does some separation of M and V using a Template, whereas the ServerPage does it all in a PHP script.
    No - the M is completely seperated in both scenarios. The ServerPage combines V and C. But as I said, this is only so for simple pages. When the going gets tuff, I will seperate the C part out of the ServerPage and into a ViewHelper. So you might say that it's not "proper" MVC. I prefer to think if it as MVC-on-demand.

    On the other hand; The way Overunner does it - by using a TransactionScript (Controller) to push data (Model) into a template (View) is fully in accordance with the MVC paradigm.

    Quote Originally Posted by arborint
    I have been thinking about this too. I have never liked a Context object because it seems very framework specific rather than a flexible, general solution. As I recall Struts/Mojavi use a Context object.
    It is indeed framework-specific - but it's the only way really. (Ignoring DI here). The good thing is that it's the only dependency we will need.
    Quote Originally Posted by arborint
    Perhaps just passing a generic Locator that can hold any objects that your specific implemetation needs to have available.
    Except that it isn't named "servicelocator", that's what the context object does. (At least as far as I'm concerned)

  22. #247
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    "dispatching model"? can you explain that, I don't understand what you mean by it.

    I really don't understand the things in this thread anymore, actions, handles, flow controllers, dispatching, locator?? It seems like you are making a design that allows for 30 variations of the same 'thing' in different places.

    Guess that's what happens when you try to build things on vaguely defined concepts (which is what MVC is, hehe, or at least I think precisely because it is so vaguely defined ).

  23. #248
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    MVC is not vaguely designed, it's just that there are that many damn implementations of each layer that is just leading to your vagueness no? Lets clarify eh?

    M = Model, V = View, C = Controller,

    A request is sent, so the Controller catches this request, and processes it. Based on the processing results, it'll select one or more Model(s) if required, which the Model(s) are then passed to the View.

    The View (via a ViewHelper for presentational reasons) will generate the View for the user, putting the Model(s) data to the Views template file. Viola, no?

  24. #249
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    No - the M is completely seperated in both scenarios. The ServerPage combines V and C. But as I said, this is only so for simple pages. When the going gets tuff, I will seperate the C part out of the ServerPage and into a ViewHelper. So you might say that it's not "proper" MVC. I prefer to think if it as MVC-on-demand.

    On the other hand; The way Overunner does it - by using a TransactionScript (Controller) to push data (Model) into a template (View) is fully in accordance with the MVC paradigm.
    It may be conceptually MVC, but if it is all in one Transactions Script it is easy for dependencies to sneak into the code. If they are separate classes then there is an interface to define the separation. In the code Overrunner posted there is no Model interface to enforce the most important separation in MVC (i.e. M<-VC). I think it would be following our goals to allow for all options:

    1. Transaction Scripts like Overrunners (already supported),
    2. Have the Model class in the same file as the View/Action (already supported),
    3. Have the Model class in a separate file and have a mechanism to load and instantiate it based on predefined path/file naming mapping rules (not yet supported).

    Quote Originally Posted by kyberfabrikken
    It is indeed framework-specific - but it's the only way really. (Ignoring DI here). The good thing is that it's the only dependency we will need.

    Except that it isn't named "servicelocator", that's what the context object does. (At least as far as I'm concerned)
    I think the Difference I was thinking of was that a Context object works like this:
    PHP Code:
    $response $context->getResponse(); 
    Whereas a general Locator works like this:
    PHP Code:
    $response $locator->get('Response'); 
    So the Context is a framework specific class, whereas the Locator is just a Singleton DataSpace to hold objects where, for example, the Front Controller does
    PHP Code:
    $locator->set('Response', new Response()); 
    and passes the locator along making it available along the chain. It's a much more generic solution. This means that an application can make an object (at run time) available with just one line, rather than having to modify the Context class.
    Christopher

  25. #250
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In an effort to clarify what I was rambling about in my last post, this is what I mean by the two approaches :

    approach 1 : the transactionscript way :
    file : actions/myaction.php
    PHP Code:
    class MyAction
    {
        function 
    execute(&$context) {
            
    // access the model-layer
            
    $gateway =& $context->getGateway('Foo');
            
    $foo =& $gateway->getByPK('27');

            
    // create a view
            
    $template =& new Template('templates/mytemplate.php');
            
    // assign model to the view
            
    $template->set('foo'$foo);

            
    // render the view
            
    $context->response($template->render());
        }

    file : templates/mytemplate.php
    PHP Code:
    <p>
        zik : <?=$foo->getZik()?>
        <br />
        zok : <?=$foo->getZok()?>
    </p>
    approach 2 : the serverpage + viewhelper way :
    file : pages/mypage.php
    PHP Code:
    <?php $foo =& $this->get('foo/getbypk/1'); ?>
    <p>
        zik : <?=$foo->getZik()?>
        <br />
        zok : <?=$foo->getZok()?>
    </p>
    As you can see, the difference is subtle. #1 has a clearer seperation, but you have to create two files.


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
  •