SitePoint Sponsor

User Tag List

Page 12 of 16 FirstFirst ... 28910111213141516 LastLast
Results 276 to 300 of 384
  1. #276
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    If it is in fact a problem, the next step could be to create a concrete descendant per table. Eg. :
    PHP Code:
    class BaseIndexAction
    {
        var 
    $table NULL;
        function 
    execute(&$context) {
            
    $gateway =& TableGateway::getGateway($this->table);
            
    $t =& new Template("index.tpl");
            
    $t->set("list"$gateway->getList());
            
    $context->response->setContent($t->render());
        }
    }

    (...)

    class 
    UserIndexAction extends BaseIndexAction
    {
        var 
    $table "user";

    This is basically how rails is constructed.
    The biggest problem with this design is that you are forced to create a lot of files that may be really trivial (simply extends a baseclass). In rails it doesn't seem that scary, since actions are grouped together in namespaces (called "controllers" in rails).
    Yes, but maybe to make it more flexible you should be able to set the name of the Model class and a parameter you pass it. For example:
    PHP Code:
    class BaseIndexAction
    {
        var 
    $table NULL;
        function 
    execute(&$context) {
            
    $modelclass $this>modelclass;
            
    $gateway =& new $modelclass($this->modelarg);
            
    $t =& new Template("index.tpl");
            
    $t->set("list"$gateway->getList());
            
    $context->response->setContent($t->render());
        }
    }

    (...)

    class 
    UserIndexAction extends BaseIndexAction
    {
        var 
    $modelclass 'TableGateway';
        var 
    $modelarg 'test';

    Christopher

  2. #277
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've been wondering lately about XSLT templating and its implications on MVC design. Say you have FrontController dispatch to an Action that decides which View and Model (if any) to use, and could take advantage of the InputProcessor. The View then takes the Model and uses a ViewHelper to first get the data into an XML tree and then perform XSLT on it.

    How would you introduce widgets or suchlike that require data from Models other than what the dispatched Action provided? Basically it's the template or rather the View that knows that it needs additional data, so it could go ahead and get a Model and use it. I don't know if this is such a good idea. I used to do this in the Actions, executing sub-actions that pushed data and added templates to the View. Comments?

  3. #278
    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)
    @Ezku
    Using PEAR::XML_Transformer you can make callbacks to a viewhelper, much the same way I have been suggesting to do with serverpages.

  4. #279
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Using PEAR::XML_Transformer you can make callbacks to a viewhelper, much the same way I have been suggesting to do with serverpages.
    But that's not XSLT anymore, you'd have to devise all the stuff yourself. Or is there something I didn't quite grasp? Care to elaborate?

    Or, after some thought, perhaps scrapping XSL altogether would be a good move. Still doesn't seem quite trivial, creating your own templating with XML_Transformer. Any examples to get me started?

  5. #280
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The usual me. There were unit tests among the sources. Quite alright.

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

    With a Model, you could massage it's data to XML via a Helper, but as you've picked up on, how to pass this over to the View... Personally I see the XSL stylesheet it's self, and nothing else, being the View.

    So, you need a method to aggregate the various Model(s), prior to the Transformation. An Xml Tree sounds like a good idea, but what form this takes I have no idea

    you can make callbacks to a viewhelper, much the same way I have been suggesting to do with serverpages.
    Funny enough, you can make callbacks on PHP from the stylesheet it's self, even though this disfigures the stylesheet, but it's basically the same thing, thus removing the need for PEAR.

    It's just that I tremble whenever I hear the word PEAR, I wonder why?

  7. #282
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Funny enough, you can make callbacks on PHP from the stylesheet it's self, even though this disfigures the stylesheet, but it's basically the same thing, thus removing the need for PEAR.
    The point in making "callbacks" is not as it is in XSL. With XML_Transformer, you can freely dictate the XML interface (for lack of a better word) that the template deals with, and then compile it to native PHP code that you can cache. Neat and effective.

  8. #283
    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)
    Actually it looks like I have been bit fast here. I haven't actually used XML_Transformer for anything but some experimenting. This is mainly because I think php is a better candidate for the job. (At least for the projects, I have been working with). I had a more in-dept look at the package, and I just realized that it doesn't do what I thought it did. XML_Transformer is really just a templating engine, based on xml. It's clever, but it doesn't actually help with your concrete problem.

    What i did in fact refer to (and what I thought the package provided) was something like xslt_set_scheme_handlers. (See also : Reading Multiple Input Documents).
    To proove what I meant, and perhaps as a penance for my bragging, I have put some code together. You'd need sablotron + php4. With php5 there are other ways to do the same thing, but I haven't looked too much at the api.
    Attached Files Attached Files

  9. #284
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That seems rather... useless. And the whole issue, while interesting, is beside the point - how do you handle widgets/subactions? I'm thinking of having a ViewHelper to do that, so the Action could remain agnostic of whatever extra the View needs. But would that be a Bad Idea?

  10. #285
    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 Ezku
    That seems rather... useless. And the whole issue (...) is beside the point - how do you handle widgets/subactions
    Really ?
    To answer the widget/subaction first ; You can use xsl:include and call templates.
    Anyway - My sample-script weren't really showing the possibilities, since I simply call a static array. Consider if the callback was a tabledatagateway.

    Further examples attached.
    Attached Files Attached Files

  11. #286
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm thinking of having a ViewHelper to do that, so the Action could remain agnostic of whatever extra the View needs.
    Generally I use a Visitor to factor a variable View(s), for the most part you only need the one Visitor, which is to recurse a Composite structure, pulling in the child Composites templates, to the parent Composite...

    However, for such an occasion that one Composites template may be XML (via a FORM submission for example?), you can't display that directly, but you need to transform it to xHTML instead...

    So you give that Composite in question another Visitor to visit instead, which'd do the transformation for you, and this visitor would return the transformed xHTML back to the Composite, which is later picked up again by the original (plain vanilla) Visitor

    Note: In recursion, the child Composite is always processed first, prior to it's parent Composite. Siblings are processed in the order you store them, just thought I'd add that since it's an important factor that a lot of people don't realise to begin with.

    This works but I've only done it with Composites, and no other approach to generating a View, but I think some though in this approach may actually help you out...
    Last edited by Dr Livingston; Aug 10, 2005 at 07:39. Reason: add a note

  12. #287
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    To answer the widget/subaction first ; You can use xsl:include and call templates.
    Anyway - My sample-script weren't really showing the possibilities, since I simply call a static array. Consider if the callback was a tabledatagateway.
    Ah! Not totally useless, I see. You indirectly answered my question; so it's alright for the View to use a Model.

    Do you consider getting Model data into XML a problem? I wouldn't know how to go about it, since creating an XmlMapper for each Model doesn't seem fun. That's because some of the fields definitely need to be CDATA, but having them all as such doesn't sound like a good idea.

    There's the implementation problem, too: I don't know how that could be done with PHP5 nor do dare to presume you have the interest to look into it.
    Quote Originally Posted by Dr Livingston
    Generally I use a Visitor to factor a variable View(s), for the most part you only need the one Visitor, which is to recurse a Composite structure, pulling in the child Composites templates, to the parent Composite...
    You totally lost me here. Sounds interesting, though; would be most kind of you to elaborate with a more concrete example. Some code, perhaps?

  13. #288
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sure,

    PHP Code:
    interface IVisitor {
    public function 
    render();
    public function 
    visitIComposite $composite );
    public function 
    __constructIRequestHandler $request_handler );

    PHP Code:
    // plain vanilla visitor as stated in earlier post...
    //
    class HtmlVisitor implements IVisitor {
    private 
    $request_handler;
    public function 
    __constructIRequestHandler $request_handler ) {
    $this -> request_handler $request_handler;
    }

    public function 
    render() {
    echo( 
    $this -> template['page'] );
    }

    public function 
    visitIComposite $composite ) {
    // at the moment, just have a controller return a template file
    // via a file_get_contents( 'filename-template.tpl' );
    // for simplicity
    $template $composite -> execute$this -> request_handler );
    // ...
    // do what is required to recurse composite, and it's child composites
    // at this point
    }

    Now, for example we have a given Controller (which implements IComposite Interface) that instead of returning a HTML template via the file_get_contents( ... ), instead it's template is a fragment of XML, so you need to transform it HTML yes? Okay...

    PHP Code:
    class XmlVisitor implements IVisitor {
    private 
    $request_handler;
    private 
    $visitor;

    public function 
    __constructIRequestHandler $request_handler ) {
    $this -> request_handler $request_handler;
    }

    public function 
    render() {
    // not implemented
    }

    public function 
    visitIComposite $composite ) { // edited due to error...
    // template is XML format
    $template $composite -> execute$this -> request_handler );
    // do transformation at this point
    //
    // note two things, due to the implementation of the IVisitor, the 
    // composite (controller) needs to know 'how' to return the transformed
    // XML (HTML) to the IVisitor, and not return the original XML it's self
    //
    // I have left this to the controller, thus to simplify the IVisitors, since it's
    // not every composite that would be handling XML anyways... 
    //
    // if you [I]do[/I] have other composites that use XML, again just use this visitor
    // on them, and voila, things are taken care of for you :)
    }

    Sorry for the bad explamation, but if there is anything you don't fully understand, I can go into more detail for you? Typically, a Controller that uses XML would look like this,

    PHP Code:
    // ...
    public function __construct() {
    $this -> transformed false;
    }

    public function 
    executeIRequestHandler $request_handler ) {
    // ...
    if( $this -> transformed ) {
    return 
    $this -> getHtml();
    } else {
    $this -> transformed true;
    // ... return the XML instead

    // ...

    // ... 
    EDIT:

    This is from memory, and looking back on the notes I made at the time, and the script, I made an error, but it has now been corrected The error that I had made, was the need for the Decorated Interface, but looking again there was no need for decoration

    Once the XML in any given Composite has been transformed, the result is put back to the Composite in question... Due to the recursiveness of the HtmlVisitor::visit( IComposite $composite ) class method, regardless of any Composite being visited by another visitor or not, the Composite that had the XML transformed to HTML is still visited by the HtmlVisitor implementation.

    In each Composite, to identify a given Composite, I have an ID for that Composite, ie

    PHP Code:
    class BodyActionHandler extends BaseActionHandler {
    protected 
    $id 'body';
    // ...

    class FooterActionHandler extends BaseActionHandler {
    protected 
    $id 'footer';
    // ... etc, for each Composite ... 
    So now that I've fixed the leak, I can get sleep a lot more easily
    Last edited by Dr Livingston; Aug 10, 2005 at 14:04.

  14. #289
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Almost forgot...

    PHP Code:
    $home = new HomeComposite();
    $body = new HomePageBodyComposite();
    $breadcrumb = new BreadCrumbComposite();
    $body -> attach$breadcrumb );
    $footer = new HomePageFooterComposite();
    // ...
    $html = new HtmlVisitor$request );
    $xml = new XmlVisitor$request$html );
    // ...
    $home -> accept$html );
    $body -> accept$xml );
    $home -> attach$body );
    $home -> attach$footer );
    // ...
    echo( $html -> render() );
    // ... 
    Note, that you only need the Root Composite ($home in this case) to have the HtmlVisitor, as it's this visitor that recurses the composite structure.Normally for the other Visitors, you just want it to work on the one given Composite it's self, that is passed to it via it's visit( IComposite $composite) class method.

    Once the work has been done, (ie Transform some XML, but the task at hand could be anything, for example, to enbolden some text? To underline some text? Etc, but you get the picture I hope), you want to give the result back to the Visitor that actually manipulates the data in some manner or other.

    For an idea of how to do the recursion within the HtmlVisitor::visit( IComposite $composite ) class method, have a look at the last post I made in this thread below, as it's this implementation that I use for the bulk of my Views

    http://www.sitepoint.com/forums/showthread.php?t=288046

    Anyways, questions if anyone has any, I'll try to answer if possible as always,

    The Good Doctor
    Last edited by Dr Livingston; Aug 10, 2005 at 13:37.

  15. #290
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    (...)
    Thanks, the latter part helped a lot. I still don't get it because I'm on a totally different mindset, but I'll definitely have to look into this.

    How do you share data in the Composite structure? It looked like data is private to each node.

  16. #291
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hello,

    At the moment data is commonly shared, is put in the Visitor (HtmlVisitor for example) as all Composites visit this visitor... But as you note, one Composite cannot share data with another Composite, and this I've not found a solution to either

    But I have an idea though... A stack of some sort yes? For example, as each Composite visits the Visitor, if it has data, it'd (the Composite) would push the data onto the stack, and through out the recursion process, another Composite would take a peek at this stack, and pop data off it, if it requires to do so? Likewise, it too could push it's own data to the stack, but...

    Once the lower child Composites have been processed, they no longer can access a higher Composites data, so it's like a one way street,... [EDITED AS NEED MORE THOUGHT ON DIRECTION OF COMPOSITE INTERACTION]

    Can't have your cake, and eat it at the same time I suppose?

  17. #292
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Almost forgot...

    PHP Code:
    $home = new HomeComposite();
    $body = new HomePageBodyComposite();
    $breadcrumb = new BreadCrumbComposite();
    $body -> attach$breadcrumb );
    $footer = new HomePageFooterComposite();
    // ...
    $html = new HtmlVisitor$request );
    $xml = new XmlVisitor$request$html );
    // ...
    $home -> accept$html );
    $body -> accept$xml );
    $home -> attach$body );
    $home -> attach$footer );
    // ...
    echo( $html -> render() );
    // ... 
    How does home know where breadcrumb, body and footer are "attached"?
    Christopher

  18. #293
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But again in saying that, that is just the way you want it when I think about it just now? Okay, in almost any given situation, if your lower down structures (template fragments for example) are to do a specific thing, such as for example, to display form errors yes?

    That given Composite that would be displaying those errors would need to know just what errors to display for example yes? Now, that given knowledge I would imagine (the way I'd do it anyways) would be held by a Composite that is higher up in the chain, wouldn't it? Well, yes...

    Code:
    ...
    Form Controller (displays form only, thus it has the 'knowledge' yes?)
    +... Little Form Displayer (displays errors only, but does not have the given 'knowledge' or Model in this case)
    ...
    If that makes sense? So, the Form Error Displaying Composite is just that... It only displays errors, and nothing more, so no point in giving it any Model related data, is there? You leave that to another Composite that is higher up if that makes sense?

    Umm...

    You'll need to excuse me, as I'm tired and needing some sleep (well, I was going to bed... At some point I might just get there ) so I'll sleep on it and get my thoughts together

  19. #294
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How does home know where breadcrumb, body and footer are "attached"?
    In each given Composite, you have this,

    PHP Code:
    // ...
    public function attachIComposite $composite ) {
    $this -> children[$composite -> getId()] = $composite;
    }
    // ... 
    It is as simple as that, and you then leave it to the recursion to pick up on it

  20. #295
    SitePoint Guru dbevfat's Avatar
    Join Date
    Dec 2004
    Location
    ljubljana, slovenia
    Posts
    684
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    But I have an idea though... A stack of some sort yes? For example, as each Composite visits the Visitor, if it has data, it'd (the Composite) would push the data onto the stack, and through out the recursion process, another Composite would take a peek at this stack, and pop data off it, if it requires to do so? Likewise, it too could push it's own data to the stack, but...
    Perhaps the Visitor could be used to pick up generated data on it's way back and pass it somehow to the parent Composite?

  21. #296
    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 Ezku
    You indirectly answered my question; so it's alright for the View to use a Model.
    It depends on who you ask, and whether you have the discipline to use it properly. I would definately say yes - It saves us from thoose controller-level classes that simply push data to the template (often known as Actions). There's a coupling between controller and view whichever way you put it - In this case, the dependency is just put in the view rather than in the controller.

    Quote Originally Posted by Ezku
    Do you consider getting Model data into XML a problem? I wouldn't know how to go about it, since creating an XmlMapper for each Model doesn't seem fun. That's because some of the fields definitely need to be CDATA, but having them all as such doesn't sound like a good idea.
    Actually I can't think of any problems which may occur due to using CDATA nodes. As long as it's machine-to-machine communication - It may be different if the xml should get in the hands of a human, but in this case that won't be an issue.
    Alternatively you can use textnodes, and simply use htmlspecialchars to escape thoose ... well ... special chars.

    Quote Originally Posted by Ezku
    There's the implementation problem, too: I don't know how that could be done with PHP5 nor do dare to presume you have the interest to look into it.
    Actually you can use sablotron with php5 - it's just not bundeled with the distribution anymore, but it is in PECL. Of course that makes it less attractive and presumably libxml (php5) is a lot faster than sablotron (php4), so that's another reason for sticking with the defaults for php5.

  22. #297
    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 got to admit that your code had my head spinning a few times Livingston. Are you really fond of complex hierarchies of abstract classes and interfaces, or did the code come out of a bigger framework, which makes some of the abstractions make sense ?
    Anyway - I tried to refactor your code step-by-step - beginning with changing it into php4 (There goes all the typehints and interfaces), and ended up with this, which I think captures the essense (correct me if I'm wrong) :
    PHP Code:
    class Template
    {
        var 
    $values = Array();

        function 
    Template($filename) {
            
    $this->filename $filename;
        }

        function 
    set($id$content) {
            
    $this->values[$id] = $content;
        }

        function 
    render() {
            
    $output file_get_contents($this->filename);
            foreach (
    $this->values as $id => $content) {
                
    $token '<value:'.$id.' />';
                
    $output str_replace($token$content$output);
            }
            return 
    $output;
        }
    }

    class 
    Component
    {
        var 
    $id;
        var 
    $view;

        var 
    $children = Array();
        var 
    $output NULL;

        function 
    Component($id$view) {
            
    $this->id $id;
            
    $this->view =& $view;
        }

        function 
    getId() {
            return 
    $this->id;
        }

        function 
    attach(&$component) {
            
    $this->children[] =& $component;
        }

        function 
    render($request) {
            
    // You could extend Component, and override this method
            // to assign model to the view at this point ...
            
    $this->output $this->view->render();
        }

        function 
    execute(&$request) {
            if (
    is_null($this->output)) {
                
    $childviews = Array();
                for (
    $i=0,$l=count($this->children); $i $l; ++$i) {
                    
    $child =& $this->children[$i];
                    
    $this->view->set($child->getId(), $child->execute($request));
                }
                
    $this->render($request);
            }
            return 
    $this->output;
        }
    }

    class 
    Request
    {
    }




    $body =& new Component('body', new Template('body.html'));
    $body->attach(new Component('menu', new Template('menu.html')));
    $page =& new Component('page', new Template('page.html'));
    $page->attach($body);
    $page->attach(new Component('footer', new Template('footer.html')));

    echo 
    $page->execute(new Request()); 

  23. #298
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I tried to refactor your code step-by-step
    A similar effort by me. I basically changed controller to View since that makes more sense in this context. Controllers could build the composite tree in their discretion and do something like $context->response->setContent($composite->render($rootnode)); Data between nodes could be passed inside the Context. This also means Model interaction is done in the View layer, which isn't half bad.

    Oh, and note that I changed the syntax from <nodeid /> to <core:import select="nodeid" />, this was done just for the kicks.
    PHP Code:
    abstract class Composite implements ICompositeIVisitable
    {
        
    /**
         * @var    array    IComposite
         */
        
    protected $children = array();
        
        public function 
    attach(IComposite $composite)
        {
            
    $this->children[] = $composite;
        }
        
        public function 
    accept(IVisitor $visitor)
        {
            
    $visitor->visit($this);
        }
        
        public function 
    getChildren()
        {
            return 
    $this->children;
        }
    }
    class 
    ViewComposite extends Composite
    {
        
    /**
         * @var    object    IView
         */
        
    public $view NULL;
        
        
    /**
         * ViewComposite constructor
         * @param    object    IView
         */
        
    public function __construct(IView $view)
        {
            
    $this->view $view;
        }
        
        
    /**
         * Get identifier from IView
         * @return    string    identifier
         */
        
    public function getId()
        {
            return 
    $this->view->id;
        }
    }
    class 
    Renderer implements IVisitor
    {
        protected 
    $context NULL;
        protected 
    $templates = array();
        
        public function 
    __construct(Context $context)
        {
            
    $this->context $context;
        }
        
        
    /**
         * Recurse composite nodes, get View process results into templates
         * @param    object    ViewComposite
         */
        
    public function visit(IVisitable $composite)
        {
            
    $id $composite->getId();
            
    $this->templates[$id] = $composite->view->process($this->context);
            foreach(
    $composite->getChildren() as $child)
            {
                
    $id_child $child->getId();
                
    $this->visit($child);
                
    $this->templates[$id] = str_replace(
                    
    '<core:import select="'.$id_child.'" />',
                    
    $this->templates[$id_child],
                    
    $this->templates[$id]
                );
            }
        }
        
        
    /**
         * Return contents of composite node
         * @param    string    node id
         * @return    string|boolean    false if node doesn't exist
         */
        
    public function render($id)
        {
            if(empty(
    $this->templates[$id]))
            {
                return 
    false;
            }
            else
            {
                return 
    $this->templates[$id];
            }
        }

    PHP Code:
    interface IVisitable
    {
        public function 
    accept(IVisitor $visitor);
    }
    interface 
    IVisitor
    {
        public function 
    visit(IVisitable $target);
    }
    interface 
    IComposite
    {
        
    /**
         * Attach a child Composite to the tree
         * @param    object    IComposite
         */
        
    public function attach(IComposite $composite);
    }
    interface 
    IView
    {
        
    /**
         * Process View
         * @param    object    Context
         * @return    string    View contents
         */
        
    public function process(Context $context);

    This was an interesting task. It even made a lot of sense in the end. :)

  24. #299
    SitePoint Guru Galo's Avatar
    Join Date
    May 2005
    Location
    Holland!
    Posts
    852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Looks more like your trying to Decorator an object to me, so why dont you use a Decorator pattern instead of eating scrumbled MVC's ?

    Decorating widgets is different from Compositing widgets but since i didn't follow the whole thread i could be wrong
    Last edited by Galo; Aug 11, 2005 at 06:38.
    Business as usual is off the menu folks, ...

  25. #300
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Galo
    Looks more like your trying to Decorator an object to me, so why dont you use a Decorator pattern instead of eating scrumbled MVC's ?
    Mm, I don't think so. Would you mind elaborating? (And preferably editing that huge quote out, it's wasting precious screen estate. :) Thanks.
    Last edited by Ezku; Aug 11, 2005 at 05:11.


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
  •