SitePoint Sponsor |
|
User Tag List
Results 1 to 24 of 24
-
Jul 5, 2006, 18:29 #1
- Join Date
- May 2003
- Location
- virginia
- Posts
- 988
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Request object? Or use Controller?
I'm building a mvc application. I'd like to make it as simple and independent as possible. I'm wondering how necessary it would be to create a Request object that encapsulates $_GET, $_POST and $_COOKIE?
I'm tempted to simply add methods to the controller base object:
Controller:aramGET()
Controller:aramPOST()
Controller:aramCOOKIE()
Controller:aramPATH()
I've also considered just using Controller:aram(), for $_GET, $_POST and $_SERVER['PATH_INFO'], where $_POST would override $_GET... and $_GET would override $_SERVER['PATH_INFO']. Controller::storage() could be for for $_COOKIE.
Is it so wrong to make it as simple as possible? I mean it's MVC, not RMVCR right?
- matt
-
Jul 5, 2006, 18:56 #2
MVC is a seperation of layers, there's no obligation for each layer to be a single class (although that's certainly a way to do it), and it's very common to have multiple classes in each layer. Also, ask yourself what's really simpler, a single class that has two different responsibilities, or two classes that have one each? Classes that do too much are generally considered a bad thing...
-
Jul 5, 2006, 19:02 #3
- Join Date
- Aug 2005
- Posts
- 11
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
The way I see it, encapsulating Request data in the Controller is pushing the Controller towards God status. It doesn't make sense to me semantically.
On the other hand, I'm not a big fan of Request objects. The ones I've seen don't seem much more than glorified data containers; perhaps with a redirect method thrown in for good measure.
$this->request = $_REQUEST;
usually suffices for me, but I generally avoid abstractions that I don't need or don't think I'll need in the future.
-
Jul 5, 2006, 20:05 #4
- Join Date
- May 2003
- Location
- virginia
- Posts
- 988
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Right. My main concern is name space issues and just having too many objects. I think I've decided to have separate objects, but will wait to see what happens.
On the same token as keeping it simple.... If I'm building a very simple controller framework.... does it seem weird to put all of the classes in one file and name the file "framework.inc.php" or some such? I realize that testing could be a problem with that setup... but not to that point yet.
-
Jul 5, 2006, 20:05 #5
- Join Date
- Jul 2002
- Location
- Dallas, TX
- Posts
- 2,900
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I'd be curious to hear your opinion on this
http://www.sitepoint.com/forums/show...7&postcount=14
There's a request object in the root post you might be interested in as well.
-
Jul 5, 2006, 21:23 #6
Originally Posted by mwmitchell
While the responsibilities of a request object can easily be done by the controller, I think it's a good candidate for a seperate object because the abstraction is easy to grasp, and it's responsibilities are quite clear, and easy to seperate from a controller's. I also think that, if you're doing TDD, it's better to have the request be seperate and mockable, rather than inserting data into the super globals.
-
Jul 5, 2006, 23:33 #7
- Join Date
- May 2005
- Location
- Holland!
- Posts
- 852
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by 33degrees
Business as usual is off the menu folks, ...
-
Jul 6, 2006, 02:31 #8
- Join Date
- Aug 2005
- Posts
- 11
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by mwmitchell
-
Jul 6, 2006, 03:13 #9
- Join Date
- Sep 2004
- Location
- Zagreb, Croatia
- Posts
- 830
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by i_m_making_a_cms
Opinions?
-
Jul 6, 2006, 12:53 #10
- Join Date
- Oct 2005
- Location
- Herts, UK
- Posts
- 113
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by BerislavLopac
-
Jul 6, 2006, 19:13 #11
- Join Date
- Jul 2005
- Posts
- 163
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Just a quick question about the intercepting filters. I understand the general theory behind them (pre and post processing), but what kind of actions do you do inside of your intercepting filters? I can not really think of anything that would need to be explicitly run before or after all parts of the application are run.
-
Jul 6, 2006, 21:00 #12
Originally Posted by EscapeYourMind
-
Jul 7, 2006, 02:18 #13
- Join Date
- Sep 2004
- Location
- Zagreb, Croatia
- Posts
- 830
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by 33degrees
-
Jul 7, 2006, 05:12 #14
- Join Date
- May 2003
- Location
- virginia
- Posts
- 988
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by i_m_making_a_cms
- matt
-
Jul 7, 2006, 05:13 #15
- Join Date
- May 2003
- Location
- virginia
- Posts
- 988
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by 33degrees
Thanks for all of the feedback.
- matt
-
Jul 7, 2006, 09:19 #16
- Join Date
- Mar 2005
- Posts
- 423
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by BerislavLopac
-
Jul 7, 2006, 09:52 #17
Here's an abridged code snippet:
PHP Code:class Controller {
function process($request, $response) {
$this->request = $request;
$this->params = $request->parameters;
$this->response = $response;
if (isset($this->params['action'])) {
$this->action_name = $this->params['action'];
} else {
$this->action_name = 'index';
}
$filter_result = $this->filter_chain->call_before($this->action_name);
if (!$filter_result || $this->has_performed()) {
return $this->response;
}
if (method_exists($this, $this->action_name)) {
call_user_func(array(&$this, $this->action_name));
}
if (!$this->has_performed()) {
$this->render();
}
$this->filter_chain->call_after($this->action_name);
return $this->response;
}
}
The filter chain executes all the registered filters (which I set in the constructor of the controller), one after the other. If any filter returns false, execution stops; filters can also call a render or a redirect, at which point the rest of the filters will execute, but the called action will not.
Edit:
Forgot to mention: Each filter has a reference to the controller, via which they can modify the request and response, if needed. That's also how they can call redirects or renders.
-
Jul 7, 2006, 11:20 #18
- Join Date
- Jul 2005
- Posts
- 163
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Ok I can see that now. So you basically have your filters in each of your application controllers? From reading around the net I was sort of under the impression that they would be implimented in the front controller so the same filter would be applied to all pages, and I couldn't really think of what use that would be. I can understand having them at the application controller level since each page would be using its own unique set of filters. Do you find that most large applications end up being a combination of MVC within an overall MVC?
-
Jul 7, 2006, 12:20 #19
Since each of my controller inherits from a common application controller, filters placed there will apply to all controllers; thus you can have a combination of application wide and controller specific filters. I think this is a more flexible and elegant solution than only having an application wide filterchain, or both application wide and controller specific chains
-
Jul 7, 2006, 23:04 #20
- Join Date
- Aug 2005
- Posts
- 11
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by BerislavLopac
-
Jul 8, 2006, 04:46 #21
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
> I really think some PHP developers need a smack and a stern reminder that they're not
> programming in Java.
I don't think that was called for; This issue resides with any number of other languages, not just Java alone. I think the problem that you have highlighted is more down to the lack of experience in both design and object oriented methodologies.
Not blame Java for the worlds ills please
-
Jul 8, 2006, 06:07 #22
- Join Date
- Aug 2005
- Posts
- 11
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Dr Livingston
-
Jul 8, 2006, 09:45 #23
- Join Date
- Sep 2004
- Location
- Zagreb, Croatia
- Posts
- 830
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by i_m_making_a_cms
-
Jul 8, 2006, 11:13 #24
- Join Date
- Aug 2004
- Posts
- 428
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I disagree
Depending on the application i may use context object. I think request object is silly if all your doing is $this->_post = $_POST;
Here is an example of a context object more further down this comment
PHP Code:#/calendar/day/year/month/day#/
$viewhelper = new CalendarViewHelper();
$viewhelper->setDayMonthYear( array($year, $month, $day) );
$viewhelper->setUserName( SystemConfig::$SubdomainBrowsing );
$viewhelper->setViewSize('large');
$calendar = new CalendarDay(new GregorianCalculations());
$body.=$calendar->build($viewhelper);
all chains, decorators, composites, CoR will use a
viewhelper/context object/visitor - see my next example:
I agree. PHP has one of the programming world's most versatile implementations of array, and that should be used whenever there is just data involved, with no behavior.
and not holding configuration information.
Problem that arises if config is in array:
Some applications use an array which are passed to the constructor as to provide another type of functionality. That is bad design because the object is holding to much responsibility. It needs to be broken up into all the options you want.
I think i've seen this in some pear packages also. Cache_Lite i think. This is a way to avoid it.
PHP Code:$chain = Cache_Database($handle, Cache_FileSystem('directory', Cache_Memory()));
//if object
$chain->saveObject($contextObject);
//if non object
$chain->save($contextObject);
PHP will always continue to keep arrays aka collections/dictionaries alive.
However php will mold into an oop language. php5 was a big step and i'm sure it won't stop there.
Just pointing out that PHP and Java are two very different beasts and just because they have similarities in syntax, doesn't mean they should be programmed in the same way.
I think the problem that you have highlighted is more down to the lack of experience in both design and object oriented methodologies.
Most often php developers have experience with other oo languages. In my case c# to help in areas php can't ... windows forms. [yes i already know about php-gtk ]
Bookmarks