Page 3 of 3

Re: Skeleton Directories

Posted: Wed Jun 03, 2009 3:41 pm
by volomike
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.
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?

Re: Skeleton Directories

Posted: Wed Jun 03, 2009 4:07 pm
by allspiritseve
volomike 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.
That's what flash() does :)

Re: Skeleton Directories

Posted: Wed Jun 03, 2009 4:14 pm
by alex.barylski
So it's a controller helper/plugin? Not strictly a controller that is invoked on it's own?

Re: Skeleton Directories

Posted: Wed Jun 03, 2009 4:24 pm
by allspiritseve
PCSpectra wrote:So it's a controller helper/plugin? Not strictly a controller that is invoked on it's own?
Yeah, it's really just a wrapper for a session handler that takes care of deleting the data on first access for you.

Re: Skeleton Directories

Posted: Wed Jun 03, 2009 4:36 pm
by Christopher
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.
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.

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.

Re: Skeleton Directories

Posted: Wed Jun 03, 2009 4:37 pm
by Christopher
PCSpectra wrote:So it's a controller helper/plugin? Not strictly a controller that is invoked on it's own?
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.

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.

Re: Skeleton Directories

Posted: Wed Jun 03, 2009 4:52 pm
by Christopher
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?
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.

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
And remember, like with some other frameworks, in Skeleton you can also organize your controllers into module directories, each with its own controllers, models, views sub-directories. That's a pretty standard feature that can help organize big projects.
  • mysite.com/admin/customerticket/ loads admin/controllers/customerticketfoo.php
  • mysite.com/blog/post/ loads admin/blog/controllers/post.php

Re: Skeleton Directories

Posted: Wed Jun 03, 2009 7:38 pm
by alex.barylski
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. :P

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.

Re: Skeleton Directories

Posted: Wed Jun 03, 2009 7:55 pm
by volomike
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 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.
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 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?
by injecting a Registry into every Controller
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?

Re: Skeleton Directories

Posted: Wed Jun 03, 2009 9:16 pm
by Christopher
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.
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: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.
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 use ;)). The Form Controller is a callback style forms manager (which needs to be upgraded to use the new A_Model_Form class ;)).
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 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: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.
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 checked ;)). The thing is that they can do a lot of stuff, but they don't do that much by default. For example you can have the FC change controller parameter 'foo' to 'FooController' if you want do (by adding a filter), but by default it just dispatches foo because I find needless overhead annoying. There is a lot of stuff like that.

Re: Skeleton Directories

Posted: Wed Jun 03, 2009 10:01 pm
by Christopher
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?
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: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.
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 you ;)). And you only have one kind of View class and you do everything the same way. That's fine for you, but as soon as we want to create a system where both you and I can create Views then we probably need to be able to load an object. I don't think there is anything wrong with the way you are doing it though.
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?
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: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?
Yeah, a Registry is just an central place from which to get commonly used objects.

Re: Skeleton Directories

Posted: Wed Jun 03, 2009 10:12 pm
by volomike
Ah, aborint, that clarifies a lot. Thanks.

Re: Skeleton Directories

Posted: Wed Jun 03, 2009 11:15 pm
by volomike
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.