views looking messy, is there a better way?

Couple of questions:

1)
Which direction do you choose?
output buffering or concat $page var (all views return a string)?


I choose the concat method, however, it's hard on the eyes: I didn't notice until i worked with a non programmer. [designer]

PHP Code:

---

$this->html.='<p class="more">'.
'<a href="/rss" title="Click here to see an XML representation of the content of this weblog."><img src="'.EnumArticleConstants::$path.'themes/'.$this->theme.'/img/xml-summaries.gif" alt="Click here to see an XML representation of the content of this weblog." /></a> '.
'</p>'; 


---

I took a look at smarty template engine, however i never implemented it as I felt the learning curve for the designer would be as much as picking up basic semantics for php. (also php has incredible documentation and is easy to learn)

so I tried to recreate the crash course in php.. I'll like to get feedback on this if possible ...its attached. [i'll like to take a look at some advanced smarty template files to c if i can recreate them using what i've created]


I used a registry to register my transfer object in case the data access and view were not sequential. meaning data access was called a lot earlier than the view. This has a negative effect in that i can't reuse templates since the view asks the registery for a specific transfer object. [example 1]

are data access and view ever that seperated?

Example 2 shows a template the doesn't explicitely request the transfer object.. but expects for the object to exist in the same scope. [require instead of require_once]






2
How many use the method described on page 282 of harry's volume 2 book? Does anyone know what this method is called? dao? ..as it does create a transfer object.

Is that what the example attempts? (without the business object)? http://java.sun.com/blueprints/corej...essObject.html







3
i plan to refactor a lot of my views this summer as i feel the views have become bloated. Take a look at my biggest view. How can i redesign using view helpers?
- one of my ideas in refactoring is to implement view helpers as described in core j2ee patterns by alur..
anyone with any advice?






4
lastly does anyone use composite controllers?
are composite controllers the same as chain of responsiblity
my thoughts are to have all my applications have a controller.. and in the __constructors add specific controllers for that domain.
CalendarController, AuthenticationController, ArticleController

anyone with any advice?

> lastly does anyone use composite controllers?

I do, have done for about a year or so now and have not looked back; If you are looking for clues as to how to use it, do a search on this forum, as I've posted a lot on it in the past. Enjoy yourself :)

> are composite controllers the same as chain of responsiblity

Nope; I posted an example of both the Composite and the CoR in a thread a while back, amongst other patterns were disuccess...

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

attached is the screen shot of the view [note i cut some of the article]


in previous applications all files have standard place to be included. Either constants.php or the application specific constants.php
I always felt more control instead of including files randomly in the view .. what do ya feel about includes randomly spread throughout the app?



phpsmarty design
the user can map data to values he wants... uses __get intercept
uses final on construct so user cannot overload and affect the logic.
user must implement the routine in map.



>Dr Livingston
i'll do my searching this week.. i've already found some gems about composites/composite views. I guess i'll concentrate on CoR since composites +visitors are becomming more and more familiar ground.

thanks.

here are the examples taken from the forums:


Example of composite view
http://www.sitepoint.com/forums/showthread.php?t=352752
by kyberfabrikken

PHP Code:

---


$page = new PageBuilder();

$page->attach( new View("header.tpl.phtml") );
$page->attach( new View("login.tpl.phtml") );
$page->attach( new View("menu.tpl.phtml") );
//main content start
$content = new CompositeView("content.tpl.phtml"); //<div> and closing </div>
$content->attach( new View("musicSearch.tpl.phtml") );
$content->attach( new View("music.tpl.phtml",$music) );
$page->attach($content);
//main content end
$page->attach( new View("footer.tpl.phtml") );
        
$page->render(); 


---

In this composite view, all views now need logic inside to decide how exactly the view should be represented. Example login.tpl.phtml: when a user has logged in; the view should change to show the user name instead of the login form.

also example needs: $page->render( $RequestObject ); //so views base there logic off the request object

All views now are required to pull data.. unless this example shows static templates not needing data. Looks like $music can be dynamic data passed to the view.. but i'm not sure.

This is a good strategy if you've already seperated out your views in the application.

forums/ - has a defined view
forums/showthread.php - has a defined view
www.sitepoint.com/ - defined view
http://www.sitepoint.com/blogs/ - defined view

PHP Code:

---

$ViewBuilder = CompositeViewFactory::getInstance($RequestObject); //returns the full composite tree for a defined view
$ViewBuilder->render(); //each component in the tree will have to fetch its own data 


---

Since in my application have defined views i might take this track.






composite controller
by Dr Livingston http://www.sitepoint.com/forums/show...3&postcount=14

PHP Code:

---

// each composite - handler - is a controller
$page = new PageHandler();
$page -> attach( $body = new BodyHandler() );
$body -> attach( new BlogHandler() /* module */ );
$body -> attach( new ArticleHandler() /* module */ );
/* add other modules */
$page -> attach( new MenuHandler() );
$page -> attach( new FooterHandler() );
$response = new Response();
$response -> render( $page ); 


---

Although composite view looks like a winner since my views are distinctly defined....

I also have applications/components properly defined.
I have a calendar, gallery, and article system

they're small applications(admin sections and all), therefore wouldn't it make sense to designate a controller for each?

and why is it not: echo $page->render($response) //so all elements in the tree see the response.

So is this how you generate a view with composite controller?

PHP Code:

---

function render($response) {
    $subview='<div>';
    foreach($this->components as $child) {
        $subview.=$child->render($response);
    }
    $subview.='</div>';                   
    return $subview;
} 


---

is there any application that takes advantage of both the composite view and the composite controller? I feel that they approach page generation with different strategies that collide with one another if implemented together on 1 site.

just wanted to put the block of code that manages all my components in index.php. i guess you would call this the page controller?

this block of code exist for faq, gallery, article, calendar .. and other systems i'm building inside index.php.

would like to see how the composite controller would help in this case?

PHP Code:

---

#FAQ: Answer Stuff
if( count($_GET)>0 && count($_POST)<=0 ){
    if( isset($_GET['FaqInsertAnswer']) ){
        $objects['one-column'].= FAQForms::InsertAnswer( $db, false, false, false);
    }elseif( isset($_GET['FaqEditAnswerSelect']) ){
        if(($i=BuildForms::myIsInt($_GET['FaqEditAnswerSelect'])) !== false){
            $faq = new FAQSelect($db);
            if($faq->getFAQsAnswers( $i, 3, false, false, false)){
                $list = new FaqEditAnswersView( $faq, false );
                $objects['one-column'].=$list->render();
            }
        }
    }elseif( isset($_GET['FaqEditAnswer']) ){
        if(($i=BuildForms::myIsInt($_GET['FaqEditAnswer'])) !== false){        
            $_SESSION['edit']=$i;
            $objects['one-column'].= FAQForms::InsertAnswer($db, false, true, false);
        }
    }
}elseif(count($_POST)>0){
    if( isset($_POST['FaqInsertAnswer']) ){
            $objects['one-column'].=FAQForms::chkInsertAnswer($db, false, false);
    }elseif( isset($_POST['FaqEditAnswer']) ){
            $objects['one-column'].=FAQForms::chkInsertAnswer($db, false, true);
    }
} 


---

Just looking at the post you included from Kyber and DL would something like the following in index.php not work for you.

I presume that faq, calendar and gallery are in a sense plugins that can be included inside any module/page?

PHP Code:

---

$locator = new Locator();
$locator->set('Request', new Request());
$page = new PageHandler();
$page->attach(new HeaderHandler());
$page->attach($body = new BodyHandler()));
$body->attach(new FaqHandler()        /* FAQ Plugin on page */);
$body->attach(new CalendarHandler()   /* Calendar Plugin on page */);
// What is nice about the Composite is that as your feature set grows it is easy to add additional plugins to the rendering of a page
$body->attach(new ArticleHandler()    /* Article Module */);
$page->attach(new FooterHandler());
$response = new Response();
$response->render($page); 


---

From where I stand one could either pass the locator into the Handlers or use it as a singleton to access your request options inside your handlers for the decision making in individual Handlers.

I am sure Kyber and DL could add some gems here as well :lol:

--
lv

You might want to check this thread as well.

Quote:

---

Originally Posted by leblanc

also example needs: $page->render( $RequestObject ); //so views base there logic off the request object

---

Not really - If the class has logic, that is concerned with the request, then it's most likely doing controller logic. So that would make it a composite controller.
My conclusions so far is that composite (hierachial) controllers are a good design, whereas adding a composite view structure to this is overkill. Composite views in them selves (with a single controller) is just not flexible anough. If your application is complex enough to need composite view, it probably needs composite controllers aswell.

Quote:

---

Originally Posted by leblanc

just wanted to put the block of code that manages all my components in index.php. i guess you would call this the page controller?

---

Page controller and front controller are patterns for how the http-request is translated into execution of code. It doesn't have anything to do with the internal processing. Exactly where the boundry between request-translation and internal flow is drawn is tricky though. In reality no clear distinction can be made. In general however, page controller refers to an architecture where you have multiple scripts with the .php extension. A front controller in contrast, is an architecture where you have just one .php script, which then dispacthes to a handler. This handler contains the same code as the page controller would - in fact it may be completely identical. The difference is in which way it is invoked - not in what it contains/does.

You can normally identify if a site uses page or front controller by looking at it's url's :
forum.php?thread=22 --> Page controller
index.php?c=forum&thread=22 --> Front controller

Often the front controller is used together with mod_rewrite, to give "pretty urls". So this would mean that in reality the front controller might have url's like this :
/forum/22

Sorry to continue this thread. I work alone therefore i rely on forums/books to keep me in touch with what others are doing in similar circumstances. Everyone's input is deeply appreciated.


My original goal was to design my code so a designer and programmer roles are seperated. Also, I wanted to create something more efficient/scalable than my current method to generate the page. I also wanted to design components so they can be used in other projects without a hassle.


Although the composite view would solve my page generation problem, it will entangle the programmer/designer roles. Therefore i don't think this is a good choice.


The problem with the current composite controller is that it does not describe the details on how the page is actually generated using the composites. Can it really handle complex views with this?


>lvismer
How do you imagine the final render of the page?

header txt
body txt
faq txt
calendar txt
article txt
footer txt

????

from what i see, the final render of the page would be directly related to how items were attached.

In real life however most pages are not designed like this. The composite controller structure cannot/should not tie down the final page render.



in real pages you have regions.

A regions is similar to a box model. A box that can contain a list of recently posted article titles, a list of upcomming events, and a list of recent uploaded pictures.

[this region requires article, calendar, and gallery components/modules]


In another region you could have a full txt article with a listing of faq's the correlate to the article.

[this region requires article and faq components/modules]



[see the view i posted previously for a real page]

I created the following image so everyone can understand what i mean about regions.


http://www.sitepoint.com/forums/atta...id=31049&stc=1






I have given this a lot of thought. Here is a sequence diagram that hopefully describes what my next plan is. Basically give the responsibility to regions. How do you know which region you need for a page request.. that responsibility is put on the page builder which requires page resolver.


http://www.sitepoint.com/forums/atta...id=31048&stc=1



thoughts anyone?

i currently have this simple version working. basically articlecontroller sets static data in the region which is then requested by the pagebuilder. It's very simple version since the articlecontroller isn't resolving any commands...but only sending static data back. The sequence diagram here describes in essense what i currently have working.


using the page frame resolver i also eliminate conditionals in my page class and seperate my code from designer code.

example:

PHP Code:

---

<body>
    <div id="center-everything">
        <div id="topbk">
        </div>
        <div id="container-main-blog">
            <div id="system-Container">
                <div id="system-spot-content">
                    [[RegionBuilder::SystemBody]]
                </div>
            </div>
            <div id="blogsyndrome-Container-Nav">
                <div id="rest-of-blogsyndrome">
                    [[RegionBuilder::SystemNavigation]] <!-- <div class="img-overflow-restrain"> <img src="/ads/1/ad.gif" alt="" /></div> -->
                </div>
            </div>
            <div id="site-credits">
                &nbsp;<!-- Developed by: <a href="http://www.robusthaven.com/">Robust Haven</a> -->
            </div>
            <div id="fox-float-closure">
                &nbsp;
            </div>
            <div>
                &nbsp;
            </div>
        </div>
        <div id="breadcrumb">
            <p>[[RegionBuilder::BreadCrumb]]</p>
        </div>
        <div id="buttons-nav">
            <ul>
                <li><a href="/about-blogsyndrome/" title="About Blogsyndrome">&nbsp;</a></li>
            </ul>
        </div>  
    </div>
</body> 


---