Wouldn't that mean that the customerticket.php file would be like seriously huge to handle every aspect of the CRUD in a single file? And you don't have subfolders under controllers to group similar things, meaning I might see like 200 files in there for a project of a scale, say, that you spent an entire year working on?the controller file would be 'controllers/customerticket.php' within that file would be a class named 'customerticket' and in this case the settings() method would be called.
Skeleton Directories
Moderator: General Moderators
- volomike
- Forum Regular
- Posts: 633
- Joined: Wed Jan 16, 2008 9:04 am
- Location: Myrtle Beach, South Carolina, USA
Re: Skeleton Directories
- allspiritseve
- DevNet Resident
- Posts: 1174
- Joined: Thu Mar 06, 2008 8:23 am
- Location: Ann Arbor, MI (USA)
Re: Skeleton Directories
That's what flash() doesvolomike wrote:Not sure I ee the advantage or the purpose in using a controller for this, when you could set the message in a SESSION and fetch it and delete it when displayed next? I wrap all my session activity in a single session helper object so I know exactly what namespaces are being used for what...no namespace collisions, etc.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Skeleton Directories
So it's a controller helper/plugin? Not strictly a controller that is invoked on it's own?
- allspiritseve
- DevNet Resident
- Posts: 1174
- Joined: Thu Mar 06, 2008 8:23 am
- Location: Ann Arbor, MI (USA)
Re: Skeleton Directories
Yeah, it's really just a wrapper for a session handler that takes care of deleting the data on first access for you.PCSpectra wrote:So it's a controller helper/plugin? Not strictly a controller that is invoked on it's own?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Skeleton Directories
I think mainly because some people like concrete interfaces especially between framework classes. But because Skeleton is loosely coupled everything goes through the Registry. The goal was consistency as much as anything else. For example the Zend controllers have several different way to do this -- an array of parameters, static calls, a Registry that is not required. Skeleton just went for consistency. It does mean there is sometimes an extra line of dereferencing code to get the object out of the Registry, but the interface is fluent so you can do one-liners.PCSpectra wrote:What were the criticisms, just curious? How else is a application supposed to share data? Globals? I htink injecting the registry into a controller context as opposed to pulling the registry in from the front controller or whatever is a much cleaner design. Keeps everything light weight and free of dependencies.
The Registry also allows you to define your application context. So you can load it up in the bootstrap with any application specific object need for that application and it is injected everywhere. I know some people like a Context object.
Finally, the Registry as implemented (A_Locator) combines a Registry with a Loader because loading is a unique PHP requirement. It has DI capabilities as well, so you can register dependencies for classes and they will be loaded and injected when the requested class is loaded/instantiated.
(#10850)
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Skeleton Directories
Yes, specifically A_Controller_Helper_Flash. I suppose it is a Helper because it takes and returns application data. As opposed to a plugin or intercepting filter that would talk directly to the controller instance.PCSpectra wrote:So it's a controller helper/plugin? Not strictly a controller that is invoked on it's own?
I understand from people who use it that they really love to work that way. Rails is sort of built around doing flash() for forms, etc.
(#10850)
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Skeleton Directories
Well, yes and no. The goal is generally thinner Controllers, so the Views and Models are separate files that are loaded -- that's where the bulk of the code for each individual action method should be.volomike wrote:Wouldn't that mean that the customerticket.php file would be like seriously huge to handle every aspect of the CRUD in a single file? And you don't have subfolders under controllers to group similar things, meaning I might see like 200 files in there for a project of a scale, say, that you spent an entire year working on?
Additionally, because they can share initialization code you may have less overall code because you have not copy/pasted the same code into multiple files. I think most MVC programmers find the all-in-one action controllers make things easier to maintain, not harder.
And of course you don't have to combine them. If you want mysite.com/customerticket/foo/ and mysite.com/customerticket/bar/ to load different files then in Skeleton you can just put the foo and bar scripts into separate files and change the URLs. Here are the options on how you can organize things:
- mysite.com/customerticketfoo/ loads controllers/customerticketfoo.php
- mysite.com/customerticket_foo/ loads controllers/customerticket/foo.php
- mysite.com/customerticket-foo/ loads controllers/customerticket_foo.php
- mysite.com/admin/customerticket/ loads admin/controllers/customerticketfoo.php
- mysite.com/blog/post/ loads admin/blog/controllers/post.php
(#10850)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Skeleton Directories
Ok so as I understand the Controller/Helper/Flash.php is a base class which you would derive from if you wanted to implement persistent message display, like showing an error after failure to create a record, etc.
I'm looking at the other controllers and I am somewhat confused by the number of them...my own framework only has an abstract controller (which provides the basic interface for front and action controllers). Actions must derive from the base class as does the front controller, but that is it.
What are the benefits of Form controller for instance, over processing the form manually in a controller? Does this class perform automatica mappings on field names based on some XML file that maps field names to field types, validations, etc?
I really like the idea of the "Dispatch" abstract class...I'll see if I cannot work that approach into my own framework.
I'm just going through the file structure of my own and renaming a bunch of folders/files and moving them around to make more logical sense...it's long over do.
Interested in hearing about your reasons behind the complex controller design.
My own are really minimal...literally the front controller derives from the abstract controller (which may only be acting as a common interface -- not sure if there is any implementaiton yet any more). The front adds the ability to get/set request/response/registry objects, dispatch to controller:actions, which are determined by the router and invoke any pre and post filters on a global level. I am looking into ways to implement a simple method to allow actions to have their own pre and post filters invoked as well.
I'm looking at the other controllers and I am somewhat confused by the number of them...my own framework only has an abstract controller (which provides the basic interface for front and action controllers). Actions must derive from the base class as does the front controller, but that is it.
What are the benefits of Form controller for instance, over processing the form manually in a controller? Does this class perform automatica mappings on field names based on some XML file that maps field names to field types, validations, etc?
I really like the idea of the "Dispatch" abstract class...I'll see if I cannot work that approach into my own framework.
I'm just going through the file structure of my own and renaming a bunch of folders/files and moving them around to make more logical sense...it's long over do.
Interested in hearing about your reasons behind the complex controller design.
My own are really minimal...literally the front controller derives from the abstract controller (which may only be acting as a common interface -- not sure if there is any implementaiton yet any more). The front adds the ability to get/set request/response/registry objects, dispatch to controller:actions, which are determined by the router and invoke any pre and post filters on a global level. I am looking into ways to implement a simple method to allow actions to have their own pre and post filters invoked as well.
- volomike
- Forum Regular
- Posts: 633
- Joined: Wed Jan 16, 2008 9:04 am
- Location: Myrtle Beach, South Carolina, USA
Re: Skeleton Directories
Why design a framework where one has to wrap page controllers in a class versus just include a page controller file and let it run its due course of interacting with controller, model, and view classes?
I mean, if I instantiate an object, doesn't that carry more of a memory footprint and CPU overhead versus calling a static class method? Shouldn't I be trying to shoot for static classes where possible and only instantiate objects as necessary? I mean, look at Zend Framework -- there's a lot of Zend_X:: this and Zend_X:: that in it. Surely I'm not that far off base in my reasoning here?
Sure, I instantiate objects if I want to maintain state. A great example is a DB class, giving me $DB, and so I can login to the database once with it and not have to keep doing that multiple times on the same page. I just don't see the benefit of doing that with Controller, Model, and View classes. I mean, with Controller, it's basically interacting with already established global variables, so why create an object for it and maintain that state overhead as a duplication of effort? With Model, I use it to load my model and yes, I create an object with that and interact with model objects, so I would agree making non-static objects here makes sense. However, I derive objects out of the Model class by making it do a file include and return an object handle back. With View, however, I'm basically assigning vars into a template and loading the template, and I don't see the benefit of creating an object out of it. So this is why my Controller, Model, and View classes all are static classes. When you say, "for a number of reasons," I guess I don't know what threads to read to be enlightened on why I should deviate from this strategy.I think it is better to work directly with an object for a number of reasons which I think have been argued in these forums and elsewhere.
I mean, if I instantiate an object, doesn't that carry more of a memory footprint and CPU overhead versus calling a static class method? Shouldn't I be trying to shoot for static classes where possible and only instantiate objects as necessary? I mean, look at Zend Framework -- there's a lot of Zend_X:: this and Zend_X:: that in it. Surely I'm not that far off base in my reasoning here?
Again, I join the ranks of the uninformed/unenlightened here. What is a Registry in this context? Is that sort of like some session space or shared memory space (like the old ASP Application object), loaded up with anything you want to attach to it?by injecting a Registry into every Controller
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Skeleton Directories
I think they often use if for the message that appears when the form is successfully submitted and redirected to a 'done' page. The custom message can be easily displayed and then disappears because it is deleted from the Session after one hop.PCSpectra wrote:Ok so as I understand the Controller/Helper/Flash.php is a base class which you would derive from if you wanted to implement persistent message display, like showing an error after failure to create a record, etc.
The only ones that are really of interest and the Mapper, Front and Action classes. The Mapper is a class that both the Front and Action Controller use to turn module/controller/action values into actual filesystem paths. The App and Input Controllers are special purpose base classes from which you can build other controller (and few people will ever usePCSpectra wrote:I'm looking at the other controllers and I am somewhat confused by the number of them...my own framework only has an abstract controller (which provides the basic interface for front and action controllers). Actions must derive from the base class as does the front controller, but that is it.
It is a callback design where you add _init(), _submit() and _done() methods in your Controller and it runs everything. It is just a different style of doing the same thing. (See the examples if you are curious)PCSpectra wrote:What are the benefits of Form controller for instance, over processing the form manually in a controller? Does this class perform automatica mappings on field names based on some XML file that maps field names to field types, validations, etc?
It's funny, I would describe the Skeleton Controllers as about as simple as they can be and still do the same things that the major frameworks do. The are actually pretty light and cut a bunch of corners where the majors have a ton of code. It also make the 3-4 times faster (last time Matthijs and I checkedPCSpectra wrote:Interested in hearing about your reasons behind the complex controller design.
My own are really minimal...literally the front controller derives from the abstract controller (which may only be acting as a common interface -- not sure if there is any implementaiton yet any more). The front adds the ability to get/set request/response/registry objects, dispatch to controller:actions, which are determined by the router and invoke any pre and post filters on a global level. I am looking into ways to implement a simple method to allow actions to have their own pre and post filters invoked as well.
(#10850)
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Skeleton Directories
I do want to be clear that we are making a distinction between Action Controllers (which are dispatched by a Front Controllers) and Page Controllers which are one per script and are access directly (e.g. mysite.com/foo.php). Wrapping them in a class give access to services local rather than from a static globals. Plus the shared initialization I mentioned above. I guess it give the general benefits of using a class, as opposed to just including a file. And it allows you to make the Front Controller special purpose and the Action Special purpose rather than having a combined. That also makes creating variations possible.volomike wrote:Why design a framework where one has to wrap page controllers in a class versus just include a page controller file and let it run its due course of interacting with controller, model, and view classes?
The Controller is an object that follows the Command pattern. That's just a way for one object (the Front Controller) to have a standard way to run code in another object. As you say, Models are usually object (even for youvolomike wrote:Sure, I instantiate objects if I want to maintain state. A great example is a DB class, giving me $DB, and so I can login to the database once with it and not have to keep doing that multiple times on the same page. I just don't see the benefit of doing that with Controller, Model, and View classes. I mean, with Controller, it's basically interacting with already established global variables, so why create an object for it and maintain that state overhead as a duplication of effort? With Model, I use it to load my model and yes, I create an object with that and interact with model objects, so I would agree making non-static objects here makes sense. However, I derive objects out of the Model class by making it do a file include and return an object handle back. With View, however, I'm basically assigning vars into a template and loading the template, and I don't see the benefit of creating an object out of it. So this is why my Controller, Model, and View classes all are static classes. When you say, "for a number of reasons," I guess I don't know what threads to read to be enlightened on why I should deviate from this strategy.
I don't know the difference in memory footprint between them and have not really been concerned about that. I don't know when it is best to use static calls and when to instantiate. Probably a long discussion.volomike wrote:I mean, if I instantiate an object, doesn't that carry more of a memory footprint and CPU overhead versus calling a static class method? Shouldn't I be trying to shoot for static classes where possible and only instantiate objects as necessary? I mean, look at Zend Framework -- there's a lot of Zend_X:: this and Zend_X:: that in it. Surely I'm not that far off base in my reasoning here?
Yeah, a Registry is just an central place from which to get commonly used objects.volomike wrote:Again, I join the ranks of the uninformed/unenlightened here. What is a Registry in this context? Is that sort of like some session space or shared memory space (like the old ASP Application object), loaded up with anything you want to attach to it?
(#10850)
- volomike
- Forum Regular
- Posts: 633
- Joined: Wed Jan 16, 2008 9:04 am
- Location: Myrtle Beach, South Carolina, USA
Re: Skeleton Directories
Ah, aborint, that clarifies a lot. Thanks.
- volomike
- Forum Regular
- Posts: 633
- Joined: Wed Jan 16, 2008 9:04 am
- Location: Myrtle Beach, South Carolina, USA
Re: Skeleton Directories
In this post...
viewtopic.php?f=19&t=100922&st=0&sk=t&s ... 15#p543533
I guess I'd like to know more about this Registry object. I mean, here are the states I see:
- store/retrieve any variable (no matter what type) in a collection area, but only for the route between data input and data output -- like a global var
- store/retrieve, but for the entire session -- like a session var
- store/retrieve, but for all sessions among all users, shared -- like a shared memory var, message queue, or database table. Old ASP programmers may be familiar with Microsoft's Application object, which would be similar.
And when I see that you require this Registry object to be passed around like you demonstrated, I would be more inclined at that point to reduce that requirement and just make it a global var, although I use global vars so sparingly and only when they suit the need.
viewtopic.php?f=19&t=100922&st=0&sk=t&s ... 15#p543533
I guess I'd like to know more about this Registry object. I mean, here are the states I see:
- store/retrieve any variable (no matter what type) in a collection area, but only for the route between data input and data output -- like a global var
- store/retrieve, but for the entire session -- like a session var
- store/retrieve, but for all sessions among all users, shared -- like a shared memory var, message queue, or database table. Old ASP programmers may be familiar with Microsoft's Application object, which would be similar.
And when I see that you require this Registry object to be passed around like you demonstrated, I would be more inclined at that point to reduce that requirement and just make it a global var, although I use global vars so sparingly and only when they suit the need.