SitePoint Sponsor

User Tag List

Page 13 of 16 FirstFirst ... 3910111213141516 LastLast
Results 301 to 325 of 384
  1. #301
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    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
    I've got an idea. This should pretty much do the trick:
    PHP Code:
    class Renderer implements IVisitor
    {
        
    // (...)

        
    protected $datastack NULL;

        public function 
    __construct(Context $context)
        {
            
    $this->context $context;
            
    $this->datastack = new DataSpace;
        }

        public function 
    visit(IVisitable $composite)
        {
            
    $this->datastack->merge($composite->view->data);
            
    $composite->view->data $this->datastack;
            
    // (...)
        
    }

    In terms of data, it's just as if execution was linear. We could also make it so that data flows from top to bottom, as in scopes.

    Edit: Changed it around. The View's local data becomes a reference to the global datastack.
    Last edited by Ezku; Aug 11, 2005 at 07:23.

  2. #302
    SitePoint Guru Galo's Avatar
    Join Date
    May 2005
    Location
    Holland!
    Posts
    852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    Mm, I don't think so. Would you mind elaborating? (And preferably editing that huge quote out, it's wasting precious screen estate. Thanks.
    Np, sorry that's a habbit clicking on quote rather then reply

    What i mean in reference to your previous post

    [QOUTE=Ezku]
    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.

    [/QUOTE]

    That sounds like you are decorating other object with data to me...
    I assume you use node objects which can implement childNodes at any level, also i assume you have used the observer pattern for node storage, this beceause otherwhise you wouldn't have the newest updates avaliable when changes occur, therefore i say by using the Decorator in this perspective you could solve the rendering problem by easely just push the render button.

    The decorator's render method would also call the render method of it's stored nodes.

    So this would alow you to store and read out data from your nodeTree with one method.
    Business as usual is off the menu folks, ...

  3. #303
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Galo
    What i mean in reference to your previous post

    Quote Originally Posted by Ezku
    Data between nodes could be passed inside the Context.
    Ah! Well, I'll admit it was a bad idea. If you look at my previous post you'll see I already came up with a better way of sharing data.

  4. #304
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    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 ?
    Your head was spinning huh?

    Going by your example you've posted, it looks like you found your way around my post without too much trouble though... The script excerpts I did post, are part of a larger framework yes, so there is quite a bit of abstraction, which I'm in favour of actually

    I'm going to look at your script some more later, but to be honest I favour the approach I have at the moment, but I'm sure other members will also find your script useful just as much. The approach I use, and the reason I will remain with it, is mostly to do with the framework it's self.

    There is little dependency, but the Visitors have other responsibilities such as cacheing for example.

    Controllers could build the composite tree in their discretion
    Exactly I pass into the Root Composite a configuration file, which basically holds static variables, ie Title if required, and also this configuration file holds the pathname to another configuration file for the child Composites, if any.

    So, this basically means that a Composites children are created on the fly, and then you can alter these children if required based on logic once you execute the Composite, in which case you can remove one, more than one, or all children as you see fit, or you can insert a different child Composite in replace of one... You could even use a different configuration file for a given child Composite as well, thus opening up more avenues to be explored.

    In doing so, (using a different configuration file) you are effectively rewriting the page structure it's self, as it's these configuration files which determine which Composites, and their children are to be used.

    Kyber, would you be willing to take a stab at trying to implement this? With the script you posted I wonder...?

  5. #305
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP Code:
    // ...
    public function visit(IVisitable $composite)
        {
            
    $this->datastack->merge($composite->view->data);
            
    $composite->view->data $this->datastack;
            
    // (...)
        

    // ... 
    The View's local data becomes a reference to the global datastack.
    That is true, but I would presume that you have (or is that, could?) logic within a DataSpace to provide methods to manipulate the stack it's self, from within a Controller?

    If you could, then I think the Global aspect of this would not be such an hinderance, or was there something else that you were thinking of, that made you make that statement I've missed?

  6. #306
    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 Dr Livingston
    Kyber, would you be willing to take a stab at trying to implement this? With the script you posted I wonder...?
    Of course I couldn't resist such a challenge. I'm still a bit puzzled on how it fits with the rest of the skeleton code.

    About the data-exchange between views ; This is a general problem for any type of composite view structure, and one I have been pondering over myself. I think the best solution is to have a global dataspace that all the views for a given context can refer to (read/write).
    Attached Files Attached Files

  7. #307
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    About the data-exchange between views ; This is a general problem for any type of composite view structure, and one I have been pondering over myself. I think the best solution is to have a global dataspace that all the views for a given context can refer to (read/write).
    I've got that pretty much tackled in my current solution; I only need to modify it so that View contents aren't evaluated before they are returned. This allows for compiling the Composite tree into a flat file, which means variables will work as expected (now they fall top-down in an odd [but perhaps favorable in some situations?] fashion).

    This turned out to look pretty nice.

    Edit: No, wait. It wasn't as easy as I thought. I'll have to look into this tomorrow.

  8. #308
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Of course I couldn't resist such a challenge. I'm still a bit puzzled on how it fits with the rest of the skeleton code.
    At the moment, well it kind of doesn't but I thought I'd bring the subject up anyways Kind of glad that I have now, as now it appears that there are a number of members who would be interested in using Composites but have not yet done so through a lack of knowledge and examples?

    The introduction of the Visitor conveys some reasurance I think, but in regards to the original question of XML I think a Visitor has a role to play in it all?

    Of course I couldn't resist such a challenge.
    I'm going to look at your attachment now, and may have a few questions for you? I have some working script at the moment, in regards to what I earlier posted on how the Composite structure is generated, and therefore your challenge, so I might as well just post that as well, and get it over and done with.

    But that's later...

  9. #309
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here is what I've just lifted out of my public folder on my local server, the scripts work so unpack the RAR as is.

    Then browse via your browser, to ../public/www/tmp/index.php Apparently this has nothing to do with this thread, but I'm sure someone could refactor the finer points, so that it does fit in

    Note, the filename extension I've changed to ZIP so the file could be attached, so be wary of that...

  10. #310
    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 haven't had time to look at your latest code livingston, but I realized a thing about the whole architecture, that bothers me a bit.
    Consider this :
    index.php
    PHP Code:
    class Component
    {
        var 
    $id;
        var 
    $view;

        var 
    $children = Array();

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

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

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

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

        function 
    execute() {
            for (
    $i=0,$l=count($this->children); $i $l; ++$i) {
                
    $this->view->set($this->children[$i]->getId(), $this->children[$i]->execute($buffer));
            }
            return 
    $this->render();
        }
    }

    class 
    Template
    {
        var 
    $values = Array();

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

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

        function 
    render() {
            
    ob_start();
            
    extract($this->values);
            include(
    $this->filename);
            return 
    ob_get_clean();
        }
    }

    $page =& new Component('page', new Template('templates/page.tpl.php'));
    $page->attach(new Component('body', new Template('templates/body.tpl.php')));
    echo 
    $page->execute(); 
    templates/page.tpl.php
    PHP Code:
    <html>
    <head>
    </head>
    <body>

    <h1>page</h1>

    <div id="body">
    <?php echo $body;?>
    </div>

    </body>
    </html>
    templates/body.tpl.php
    PHP Code:
    <h1>body</h1>

    <
    p>lorem ipsum dolor sit amet</p
    Compared to this :
    page.php
    PHP Code:
    <html>
    <head>
    </head>
    <body>

    <h1>page</h1>

    <div id="body">
    <?php include('body.php'); ?>
    </div>

    </body>
    </html>
    body.php
    PHP Code:
    <h1>body</h1>

    <
    p>lorem ipsum dolor sit amet</p
    They both archieve the same thing. The only real difference is that the first example composes the hierarchy at the controller level. You might argue that the second example mixes controller and view code (the include statement thus being controller and the rest of the markup being view). That may be right, but if that tradeoff allows me to reduce my code so drastically, I'm not sure if it's worth the effort.

  11. #311
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My comments on this code are twofold. First I am often confused when Structural patterns are used by their names in code rather than what they are. This is one reason that I often find Dr Livingstone's code so difficult to understand.

    Second, and related to the first, is what exactly is being converted to a tree structure. The Controller? The View generically? A TemplateView with children?

    The goal is to make the tree complete independent of the renderers used so you can plug in different template code at each point (or possibly inherit the root renderer if the node has none). I think kyberfabrikken gets close, but he has the same feeling that I do. There has to be a simpler, cleaner solution or it's not worth the effort.
    Christopher

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


    The tradeoff as you note not only reduces the code base but also will allow for (generally) quicker development but in saying that, to me the tradeoff by taking a shortcut to the same goal carries too much risk.

    Forgetting about the fact that there is PHP embedded within HTML (different topic entirely, which has already been exhausted anyways), this may lead the developer in question to take other shortcuts as well?

    For the immediate use, the second approach would work (and proberly work well enough I suppose, within reason) for smaller applications and for applications where there is to be no or very little growth.

    Or where the developer who is developing the application does just that, and is going (or not really concerned) about taking it further at a later date? The second approach thus decreases development time short term, but increases long term.

    With the first approach, there is more abstraction, and thus a (slightly) more increased development period, but this decreases long term.

    I tend to think long term, so plan, design and develop with that in mind, but I'm not so short sighted that I'm not going to say that there wouldn't be any benifits with your alternative either, as there are, for those developers that can understand the dis/advantages of each approach, and learn to live with that?

    Also, there is quite a bit more script that has been removed, and then again, there is some script that has yet to be refactored to fit in with this approach, as it's a different approach to the (current) one I have developed for

    Anyways, I look forward to hearing what you think of the attachment once you've had the time to take a look at it properly.

  13. #313
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    (...)
    To be honest, I find it hard to argument against that; I feel like I've achieved something, but still can't think of a real reason why it would be better this way. All new functionality I have here could be handled using ViewHelpers. Dr Livingston, I'd definitely like your comment here. Why do you prefer a complex structure such as this over anything else?
    Last edited by Ezku; Aug 12, 2005 at 09:24. Reason: Shouldn't take twenty minutes to post.

  14. #314
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    his is one reason that I often find Dr Livingstone's code so difficult to understand.
    Yes, I tend to have some difficulty with class naming, unfortunately

    Second, and related to the first, is what exactly is being converted to a tree structure.
    The goal is to make the tree complete independent of the renderers used so you can plug in different template code at each point (or possibly inherit the root renderer if the node has none).
    The Visitor generates a web page based on recursion. The Controllers (implementing a Composite interface) are generated on the fly in a hierarchacal structure to allow the Visitor to recurse over this struture.

    In doing so, the web page it's self, comprises of one (root), or more (child) templates. This gives you greater freedom on how the page is constructed, as for example, each Composite is independent... You want to display a calendar view, whereby there are 3 different months for example?

    You just need to declare 3 Controllers, using the exact same Controller for each. This gives you increased re-use no? Some may argue with that point though. Another benifit of this approach is that as suggested you can swap one Composite out, for another one, and the Composites children are gone along with it?

    At the moment I can do this using an Observer but the flexibility is far, far more limited due to the implementation, so this script I posted today is a lot more flexible, whereas at the moment I parse an XML file that determines the whole Composite structure.

    The rendering is I believe is independent of the other responsibilities. Anyways, look forwards to your comments, etc as maybe there is something in them, I'd need to look more closely at what I use and what's on the table, now.

  15. #315
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why do you prefer a complex structure such as this over anything else?
    Well, I don't think it's all that complex, from the point of view of the script. Maybe it is more complex compared to the alternatives by Kyber for example? But the script that I have at the moment, and what I have posted today are, or at least will be, a part of something bigger.

    So, at the moment, as the script it's self is standalone, it appears to be complex, but this isn't the case, when the script is used in the context of what I'll be using it for?

    If that makes some sense? Basically I'm looking at a bigger picture I suppose, where there are a lot more variables.

    Umm... Then again, coming back to the purpose of this thread, ie A skeleton of something that does just that, maybe what I use is not suitable at the moment huh?

    Like, using a 20lb hammer to knock in a nail on the wall for a picture frame, where something smaller would be better no?

  16. #316
    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 Dr Livingston
    Forgetting about the fact that there is PHP embedded within HTML (different topic entirely, which has already been exhausted anyways), this may lead the developer in question to take other shortcuts as well?
    That's a valid point, but more so if you don't trust the developer. As such it's closely related to the template-debate (as you mention yourself).
    In relation to that - the simple approach obviously only works with php as the view-layer, whereas the other could use any type of renderer for the view (smarty, xsl, whatever).

    Quote Originally Posted by arborint
    I am often confused when Structural patterns are used by their names in code rather than what they are.
    I agree to that. In particular the Visitor had me really puzzled, since it doesn't really act like a GoF/Visitor ? (In fact it's entirely obsolete)
    Quote Originally Posted by arborint
    Second, and related to the first, is what exactly is being converted to a tree structure. The Controller? The View generically? A TemplateView with children?
    I think the effort is to build a composite view (that is - multiple views assembled into one). The strategy is to do this at the controller level, by assembling the controllers into a hierarchy.
    My proposal to do it at the view-level rather than the controller-level, greatly simplyfies things, but admittedly fails to seperate the presentation-layer properly. I'm not really in favor of either approach - it relies on the context which is the best solution. But if we must stick with the mvc-paradigm, it's probably more correct to assemble at the controller-level.

  17. #317
    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 think the effort is to build a composite view (that is - multiple views assembled into one). The strategy is to do this at the controller level, by assembling the controllers into a hierarchy.
    My proposal to do it at the view-level rather than the controller-level, greatly simplyfies things, but admittedly fails to seperate the presentation-layer properly. I'm not really in favor of either approach - it relies on the context which is the best solution. But if we must stick with the mvc-paradigm, it's probably more correct to assemble at the controller-level.
    It is just a very tricky problem. The issue is not really the recursing down the tree which is pretty simple. It is 1) what to do with the output when you get it, and 2) how to make the interfaces clean yet plugabble. And it always starts to look like Heirarchical Template View. Perhaps as Dr Livingstone may have suggested, the goal is to flatten everything out and then render it.

    For example, say you have:

    • page
      • header
      • body
        • content
        • sidebar
      • footer

    What you want is to have a "render list" like:

    body[content] = content->view->render()
    body[sidebar] = sidebar->view->render()
    page[header] = header->view->render()
    page[body] = body->view->render()
    page[footer] = footer->view->render()

    I believe that Jeff Moore has been working on something like this for WACT. It would be great if we could come up with a generic way to assemble a tree of Views into a flat "render list".
    Christopher

  18. #318
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think the Composite pattern lends itself to that just fine. It's just a matter of how you apply it.

    Might be irrelevant, might not:
    PHP Code:
    interface IComposite
    {
        public function 
    attach(IComposite $composite);
        public function 
    getNode();
        public function 
    getChildren();
        public function 
    getParent();
        public function 
    setParent(IComposite $composite);
    }

    abstract class 
    Composite implements IComposite
    {
        protected 
    $node NULL;
        protected 
    $children = array();
        protected 
    $parent NULL;
        
        public function 
    attach(IComposite $composite)
        {
            
    $composite->setParent($this);
            
    $this->children[] = $composite;
        }
        public function 
    getChildren()
        {
            return 
    $this->children;
        }
        public function 
    getNode()
        {
            return 
    $this->node;
        }
        public function 
    getParent()
        {
            return 
    $this->parent;
        }
        public function 
    setParent(IComposite $composite)
        {
            
    $this->parent $composite;
        }
    }

    class 
    ViewComposite extends Composite
    {
        public function 
    __construct(IView $view)
        {
            
    $this->node $view;
        }
        
        
    /**
         * Get identifier from IView
         * @return    string    identifier
         */
        
    public function getId()
        {
            return 
    $this->node->getId();
        }
        
        
    /**
         * Set node data in synch with external DataSpace
         * @param    object    DataSpace
         */
        
    public function sync(DataSpace $data)
        {
            
    $data->merge($this->node->getData());
            
    $this->node->setData($data);
        }
        
        public function 
    process($context)
        {
            return 
    $this->node->process($context);
        }

    PHP Code:
    class Renderer
    {
        
    /**
         * @var    object    Context
         */
        
    protected $context NULL;
        
        
    /**
         * Parsed composite nodes named by id
         * @var    array
         */
        
    protected $templates = array();
        
        
    /**
         * A shared DataSpace for View data
         * @var    object    DataSpace
         */
        
    protected $datastack NULL;
        
        
    /**
         * Root node ID
         * @var    string
         */
        
    protected $rootnode NULL;
        
        
    /**
         * Renderer constructor
         * @param    object    Context
         */
        
    public function __construct(Context $context)
        {
            
    $this->context $context;
            
    $this->datastack = new DataSpace;
        }
        
        
    /**
         * Set default values for rendering
         * @param    array | object    DataSpace
         */
        
    public function setDefaults($data)
        {
            
    $this->datastack->merge($data);
        }
        
        
    /**
         * Recursively process ViewComposite nodes
         * @param    object    ViewComposite
         */
        
    public function process(ViewComposite $composite)
        {
            
    $composite->sync($this->datastack);
            
            
    $this->processNode($composite);
            foreach(
    $composite->getChildren() as $child)
            {
                
    $this->process($child);
                
    $this->processChild($child);
            }
            
    $this->rootnode $composite->getId();
        }
        
        
    /**
         * Process local ViewComposite node in renderer
         * @param    object    ViewComposite
         */
        
    protected function processNode(ViewComposite $composite)
        {
            
    $this->templates[$composite->getId()] = $composite->process($this->context);
        }
        
        
    /**
         * Process child ViewComposite node in renderer
         * @param    object    ViewComposite
         */
        
    protected function processChild(ViewComposite $composite)
        {
            
    $parent_id $composite->getParent()->getId();
            
    $id $composite->getId();
            
            
    $this->templates[$parent_id] = str_ireplace(
                
    '<core:import select="'.$id.'" />',
                
    $this->templates[$id],
                
    $this->templates[$parent_id]
            );
        }
        
        
    /**
         * Return contents of composite node (root node if no argument given)
         * @param    string    node id, optional
         * @return    string|boolean    false if node doesn't exist
         */
        
    public function render($id NULL)
        {
            if(empty(
    $id))
            {
                
    $id $this->rootnode;
            }
            if(empty(
    $this->templates[$id]))
            {
                return 
    false;
            }
            else
            {
                return 
    $this->templates[$id];
            }
        }

    Now, if you have a View that outputs, say, XML that needs to be parsed before it gets to the Renderer: you extend ViewComposite in an XmlViewComposite that overrides ViewComposite::process(), and do the parsing there. On the other hand if your whole hierarchy is XML, you can extend the Renderer. With proper automation this should be neat.

    Essentially same as before, but with the useless Visitor stuff removed. Now it really is a Composite. I think this could be made so that the result is a flat PHP file.

    Note: My View here is an Action, which translates into a kind of Controller. So it's not just a Template, m'keeh. :)

  19. #319
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Not sure I am clear about it. The View composite seems to put everything into a single dataspace and walks top-down rather than bottom up. And a single dataspace also implies that there can be no name reuse between views.

    The Renderer looks like a specific Template class that does a str_replace of <core:import select="name" /> with 'somevalue'.
    Christopher

  20. #320
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I personally have been working with a technique that builds from the bottom up. You get your target page (and/or controller) and whatever that page/view asks for serve it. If you don't ask for it, it doesn't get executed. This is the DispatchView am I correct? The pages can set and print variables. After it's been executed, there is a resulting dataspace.

    Then, you create decorator(s) to "fit" the page and/or it's data into a new view. The decorator uses a regX to match a particluar file/directory (match="pages/about"). You can build pages very quickly and overide decorators using page specific decorators.

    I like the tree composite idea (for some reason?), but it seems backwards to me. It needs to be inverted? Maybe that doesn't make much sense? ViewDispatch seems like the most direct and easy to maintain method. The tree builds it self and there is no cconfig file. A view asks for data, defines some data, and the decorators handle it from there. A template engine could be built (pull) to mimic how PHP would do it.

    Matt

  21. #321
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    Not sure I am clear about it. The View composite seems to put everything into a single dataspace and walks top-down rather than bottom up. And a single dataspace also implies that there can be no name reuse between views.
    Why would you want them to be parsed bottom-up? Data here flows from top to bottom as in scopes. The datastack is for sharing data, if it's wanted. Nothing prevents you from having a private dataspace in your View.
    The Renderer looks like a specific Template class that does a str_replace of <core:import select="name" /> with 'somevalue'.
    I guess I need to demonstrate it.
    PHP Code:
    $composite = new ViewComposite(new IndexNewsView);
    $composite->attach(new ViewComposite(new HeaderView));

    $renderer = new Renderer($context);
    $renderer->process($composite);
    echo 
    $renderer->render(); 
    PHP Code:
    class IndexNewsView extends View
    {
        protected 
    $template 'News/Index.tpl';
        
        
    /**
         * This is ran before processing
         */
        
    protected function initialize(Context $context)
        {
            
    $news = new NewsModel;
            
    $this->data->news $news->get(5);
            
    $this->data->section 'News > Index';
        }

    PHP Code:
    class HeaderView extends View
    {
        protected 
    $template 'Header.tpl';

    News/Index.tpl:
    PHP Code:
    <core:import select="Header" />
    <?php foreach($vars->news as $item) { ?>

       <h2><?php echo $item->topic ?></h2>
       <div><?php echo $item->content ?></div>

    <?php ?>
    Header.tpl:
    PHP Code:
    <h1>Section: <?php echo $vars->section ?></h1>
    The import statement in News/Index.tpl would be replaced with the contents of Header.tpl. It's a stupid example with the implementation of View left out and all, but I think you'll be able to decipher it nonetheless.

  22. #322
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mwmitchell
    I like the tree composite idea (for some reason?), but it seems backwards to me. It needs to be inverted? [...] ViewDispatch seems like the most direct and easy to maintain method. The tree builds it self and there is no cconfig file. A view asks for data, defines some data, and the decorators handle it from there.
    Sure! I'd love to see some code on that. We're all here to learn, right?

  23. #323
    SitePoint Zealot
    Join Date
    Jul 2005
    Posts
    194
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I am using a similar approach as the one by DrLivingstone only I am trying to make the objects accesible when you use PHP itself as a template engine, but you can also use XSLT/XML or my home-made one. If you tell the "system" to use XSLT/XML it will return XML instead of PHP objects etc.

  24. #324
    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
    And it always starts to look like Heirarchical Template View. Perhaps as Dr Livingstone may have suggested, the goal is to flatten everything out and then render it.
    You can convert a hierarical structure to a linear one by simply recursing through and push to a stack. But why you want to do that I can't see ?

    I think the key concern here is dependencies. One component depends on another component in order to render itself. Using post#310 as example, you can observe that page.php depends on body.php. This dependency translates directly to the tree-structure we are struggling with. Eg. the topmost elements depends on thoose further down the tree.

    The natural conclusion is that the leafs must be rendered before the root (down-up). This is precisly what the examples so far has been doing.

  25. #325
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm not sure if formatting knowledge should exist at all at this point in the code. If you simply define sets of data, a template can put everything in its proper place. Templates know about headers and footers etc but the code which gathers the data doesn't need to. Different views which display the same group of data might not have the same layout - a three column design isn't going to work on the command line for example.


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
  •