| SitePoint Sponsor |
Ezku, first of all thanks for your reply! I am replace the render()-function of the View-class to use my own simple template engine. But indeed it might be smart to add that logic in the AppController itself. Using the preferred language as specified in the $context->request->SERVER
Maybe I am gonna need to rewrite your routing class to make it look more RoR-like.
The way I deal with it, language is a property of Request (maps to Content-Language header). It should be set automatically by the browsers language initially, but possible to override by the programmer (and ultimately the user, through a command/action).
Translation would happen most likely in the template, where the easiest would be simply to use a global/functional approach, since it's a fairly global thing anyway. This is the approach I have been using and it works pretty well. From my encounters with other codebases this is how most people deal with it anyway.
The weakness of this design is that you can only serve one language at a time (i18n) as opposed to mixing languages in the same request. I have never had any use for multiple language at the same time, but I suppose it has it's uses. How's your experience with this ?
Well, I was also planning to use content-language to find out the preferred language of the user. The link know has /:language/ parameter is defaults to the content-language value if not available it changes to English.
About the multi-language support I currently as a item in the Context-instance where the information is stored about the controller including controllername, action, parameters etc.
Currently I have a master template that support page content (i.e. child template) the master template is available in the main directory /templates/ and the page content templates in /templates/[controllername]/?. The file naming convention at the moment is: master.{$language} . TEMPLATE_EXTCode:array( 'controller' => 'Report', 'action' => 'view', 'id' => 'D17EF91A', 'language' => 'en' )Only this works at the moment...
Beside of that I wouldn't have a possible use for multiple languages at the same time, currently if the template is not available or that language it raises a 404.
So is this project dead or is it just taking a break?
I have read both threads now and i took me 3 hours, and i just scratched the surface
Great work guys!
Hey there,
So I downloaded the source package for this and started to try to understand it. The best way for me to do this was to go through the execution path of the Hangman example cleaning up the source and writing tests for each class that I came across.
So far everything makes a lot of sense, unfortunately I have gotten hopelessly bogged down in trying to test the ApplicationController::execute method. The problem is that I am trying to Mock as much as possible of the things that I have already written tests for. That way I can skip a lot of their internals and more importantly use them as auditors.
The real issue boils down to the static use of the Handle::resolve method. This function takes a Handle object and an array of arguments for the class contructor. The problem is that I cannot mock the Handle object so that I can apply a setReturnValue to the resolve method. Since I can't do that, then there is no way for me to mock/audit State objects that are managed by the Application Controller. The whole point of the Application Controller being that when I pass in a certain set of parameters I get a definite state object that I run the execute method on.
Here is the offending code block from the Input Controller:Was there a reason to design the Handler that way? It is hard to find anything about it in the thread. To be honest, the Handle object itself feels unweildy and took me a while to even figure out what the point of it was.PHP Code:/**
* @access public
* @param Locator $locator
* @return boolean
* @todo Handle::isHandle check (~ln 158) is redundant, performed again by resolve method
*/
public function execute($locator) {
$locator->set('Controller', $this);
foreach (array_keys($this->Handlers) as $key) {
$MethodName = 'execute';
$CurrentHandler = $this->Handlers[$key];
if (Handle::isHandle($CurrentHandler)) {
if (strlen($CurrentHandler->getMethodName()) > 0)
$MethodName = $CurrentHandler->getMethodName();
$Handler = Handle::resolve($CurrentHandler, array(0=>$locator));
} else {
$Handler = $CurrentHandler;
} // end if
$Handler->$MethodName($locator);
} // end foreach
return $this->Error;
} // end execute
Later,
Matthew.
> To be honest, the Handle object itself feels unweildy and took me a while to even figure out what the
> point of it was.
Yer... It turned up originally in WACT if I remember? That's the earliest reference point that I could recall and it's a concept that I didn't much like either.
With the advent of PHP5 though, I see no further use for it...
It acts a bit like a closure, in addition to the lazy-load mechanism. However, since PHP already has a callback type (Although a bit clumsy), I think it might be better to use that ?Originally Posted by Dr Livingston
Hey there,
I was talking to arborint about the Handle class and he mentioned that its purpose was indeed to provide and lazy-loading facility for objects. This is a great idea once I understood it. After re-reading this post by Dr Livingston again I have been thinking that a Locator on Steroids might be a better way to handle this operation though. I know that it would certainly be more testable as I could mock the factory and set up the expectations for the object that it instantiates. More testable = better design yes?
later,
Matthew.
Better design?
Yes I would say that with a Service Locator or DI you have a better and more flexible route open to you
The ability of PHP5 to use it's Reflection API basically makes the WACT inspired approach redundant in my view... I think WACT in it's PHP5 reincarnation though uses a form of Dependency Injection now as well?
Posting Permissions
Bookmarks