Skeleton Directories
Moderator: General Moderators
- volomike
- Forum Regular
- Posts: 633
- Joined: Wed Jan 16, 2008 9:04 am
- Location: Myrtle Beach, South Carolina, USA
Skeleton Directories
On the devnetwork Skeleton project, I was trying to understand the directory structure.
- Why call it "A" when you guys call it Skeleton? Why not a folder named Skeleton?
- Why does everything have to start with "A_" in the framework classes? Why not call the classes like "Model::classMethod()", "Controller::classMethod()", "View::classMethod()", "Cart::classMethod()"?
- What is "specs" in the root folder?
- Why stick "sweety" (the template engine) in the root path?
- Why are "tests" in the root path?
- Where's your .htaccess file to load index.php for the front controller?
- Where's your bootstrap file to load common classes for the framework?
- You call it "Mapper", but I think the world calls it "Router". Why is that?
- In "examples" I find a front controller example. Why make that like an optional implementation? Why not just make it a default and if people don't like that they can choose to replace it? I mean, it makes it one more step one has to learn in order to use Skeleton.
- You appear to have common library classes in A, but then why also have "classes" there and "functions" there?
- Where's the class for controllers, for models, and for views as part of the mechanics of this framework?
- Why have a "Template" class when you appear to use "sweety"?
- Why are folders under "A" along with files? Why not a structure of Domain Object folders for the parts of the framework, and then files under that? I mean, let's take Validator.php. You could create a Validator folder and just put Validator.php inside. And if you need to grow Validator beyond one class, you already have a folder. It just is more logical to me.
- Have you all considered a file hierarchy like the following? The {x} means folder.
.htaccess
index.php
{controllers} (or _controllers)
{models} (or _models)
{views} (or _views)
{system} (or _system or _library -- stuff for the framework)
The .htaccess calls index.php for all unrecognized URLs (the 404 trick). It loads the index.php as the front controller. The front controller can be minimal here, doing nothing but loading the system\bootstrap.php file, and doing the default routing of any URL that comes in so that:
http://site.com/domain-object/task/whatever/whatever/
is automatically routed to:
controllers/DomainObject/Task.php and whatever/whatever can be parsed inside that.
The page controllers folder can be empty except for the controllers/Home/Home.php file which gets called if someone hits the site like so:
http://site.com/
The models folder can be empty and the Model::loadModel('DomainObject/SubDomainObject") class method can load stuff from models. Under models, for instance, I could create a folder "Employees" and then perhaps a class file like "Management.php". And then I could do Model::loadModel('Employees/Management') to load it in my page controller.
The views folder can be empty except for the Home/Home.php file which gets called automatically if someone does something from Home/Home.php like: View::displayView($sView) where $sView is either empty or says "Home/Home".
In the system folder, you can store the classes that handle controllers, models, and views, and then the classes that provide all the goodies in Skeleton like DB, Filter, Email, PDF, Pagination, Cart, Captcha, etc.
Just saying that with a more logical file structure, it might make it easier to understand and use.
- Why call it "A" when you guys call it Skeleton? Why not a folder named Skeleton?
- Why does everything have to start with "A_" in the framework classes? Why not call the classes like "Model::classMethod()", "Controller::classMethod()", "View::classMethod()", "Cart::classMethod()"?
- What is "specs" in the root folder?
- Why stick "sweety" (the template engine) in the root path?
- Why are "tests" in the root path?
- Where's your .htaccess file to load index.php for the front controller?
- Where's your bootstrap file to load common classes for the framework?
- You call it "Mapper", but I think the world calls it "Router". Why is that?
- In "examples" I find a front controller example. Why make that like an optional implementation? Why not just make it a default and if people don't like that they can choose to replace it? I mean, it makes it one more step one has to learn in order to use Skeleton.
- You appear to have common library classes in A, but then why also have "classes" there and "functions" there?
- Where's the class for controllers, for models, and for views as part of the mechanics of this framework?
- Why have a "Template" class when you appear to use "sweety"?
- Why are folders under "A" along with files? Why not a structure of Domain Object folders for the parts of the framework, and then files under that? I mean, let's take Validator.php. You could create a Validator folder and just put Validator.php inside. And if you need to grow Validator beyond one class, you already have a folder. It just is more logical to me.
- Have you all considered a file hierarchy like the following? The {x} means folder.
.htaccess
index.php
{controllers} (or _controllers)
{models} (or _models)
{views} (or _views)
{system} (or _system or _library -- stuff for the framework)
The .htaccess calls index.php for all unrecognized URLs (the 404 trick). It loads the index.php as the front controller. The front controller can be minimal here, doing nothing but loading the system\bootstrap.php file, and doing the default routing of any URL that comes in so that:
http://site.com/domain-object/task/whatever/whatever/
is automatically routed to:
controllers/DomainObject/Task.php and whatever/whatever can be parsed inside that.
The page controllers folder can be empty except for the controllers/Home/Home.php file which gets called if someone hits the site like so:
http://site.com/
The models folder can be empty and the Model::loadModel('DomainObject/SubDomainObject") class method can load stuff from models. Under models, for instance, I could create a folder "Employees" and then perhaps a class file like "Management.php". And then I could do Model::loadModel('Employees/Management') to load it in my page controller.
The views folder can be empty except for the Home/Home.php file which gets called automatically if someone does something from Home/Home.php like: View::displayView($sView) where $sView is either empty or says "Home/Home".
In the system folder, you can store the classes that handle controllers, models, and views, and then the classes that provide all the goodies in Skeleton like DB, Filter, Email, PDF, Pagination, Cart, Captcha, etc.
Just saying that with a more logical file structure, it might make it easier to understand and use.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Skeleton Directories
arborint would be the one to answer but I'll chime in anyways (before bed):



It's when frameworks make all these assumptions that they become higher level frameworks and thus fall out side the scope of a minimalist framework. Joomla for instance, assumes a lot...which is great for getting up and running ASAP but sooner than later you hit a Joomla wall and your stuck banging your head off the wall.
Software should be built in layers, one framework ontop of another, not all mangled into one code base...that is the epitomy of bad design, fragile design
anyways, not strictly bad, I guess as long as it works.
A framework should be dropped into an existing application, as a developer you should then be responsible for setting up the application controllers, models, etc. If there are defaults, you provide them as there is no way a framework developer could ever know what I expect for a default. Some examples of possible defaults might be an error controller, but still...IMHO in a minimalist framework there should only be abstract controllers...not default controllers. These should be provided by the client developer.
I wondered this too...I figure it's probably because it reads in English as "A skeleton framework" or because it's a framework that started in alpha state and will continue to be so...probably later to being renamed as "B" following the marketing strategy of the ever popular B and C language.Why call it "A" when you guys call it Skeleton? Why not a folder named Skeleton?
Convention? Following PEAR and Zend...makes sense for the most part but there are times when this isn't the case so I hear your complaints.Why does everything have to start with "A_" in the framework classes? Why not call the classes like "Model::classMethod()", "Controller::classMethod()", "View::classMethod()", "Cart::classMethod()"?
I assume they are specifications...PHPSpec...BDD instead of TDD and SimpleTest???What is "specs" in the root folder?
There is a template system called sweety? Yuck. But aside from a horrible name...probably because the root path is the easiest place to rip something out and replace it with something custom...like Smarty or Stupid or Dummy.Why stick "sweety" (the template engine) in the root path?
Like above...they are not part of the 'core' framework so you want them in a place where they can be easily removed by end users. Again only a guess.Why are "tests" in the root path?
I believe skeleton is a minimalist framework...if I know how arborint thinks I would guess that .htaccess probably falls outside the domain of a minimalist framework...thats application code.Where's your .htaccess file to load index.php for the front controller?
Same as above...again only a guess.Where's your bootstrap file to load common classes for the framework?
arborint is probably most fluent in terms of pattern terminology...so I'm sure there is good reason but I would dislike that name if it is indeed actually a router used in routing requests to action controllers.You call it "Mapper", but I think the world calls it "Router". Why is that?
Because a framework is not always used to build web applications...might be command line...in which case a front controller may not be needed. Each time you introduce a requirement like this, it only serves to improve your code as a framework...making it truly minimalist...free of un-needed dependencies and more cohesive as a whole.In "examples" I find a front controller example. Why make that like an optional implementation? Why not just make it a default and if people don't like that they can choose to replace it? I mean, it makes it one more step one has to learn in order to use Skeleton.
It's when frameworks make all these assumptions that they become higher level frameworks and thus fall out side the scope of a minimalist framework. Joomla for instance, assumes a lot...which is great for getting up and running ASAP but sooner than later you hit a Joomla wall and your stuck banging your head off the wall.
Software should be built in layers, one framework ontop of another, not all mangled into one code base...that is the epitomy of bad design, fragile design
anyways, not strictly bad, I guess as long as it works.
Ugh...that is starting to sound like CodeIgnitor making assumptions like that...it's intended to be a research platform for a generic, minimalist framework I believe...making those assumptions would start leading them down the path of more reistance and bad design.The views folder can be empty except for the Home/Home.php file which gets called automatically if someone does something from Home/Home.php like: View::displayView($sView) where $sView is either empty or says "Home/Home".
A framework should be dropped into an existing application, as a developer you should then be responsible for setting up the application controllers, models, etc. If there are defaults, you provide them as there is no way a framework developer could ever know what I expect for a default. Some examples of possible defaults might be an error controller, but still...IMHO in a minimalist framework there should only be abstract controllers...not default controllers. These should be provided by the client developer.
What is more logical? I haven't looked at Skeleton in ages but the last I looked it made sense for the most part, at least from the perspective of a minimalist framework.Just saying that with a more logical file structure, it might make it easier to understand and use.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Skeleton Directories
Thanks Alex!
There are a number of possible layouts for the application directory. Some are shown in the documentation. There are several examples that show basic layouts. Skeleton support modules if you want them as well.
There is also an A_Application class that is an all-in-on solution to what you are asking for. It turns the bootstrap into 3-4 lines. We are waiting for John Cartwright to fix that class though.
Though typically you would have an application directory If you used modules you could have something like this:And finally a good practice is to separate public, application and libraries like this:All of those structures are easy to do. Skeleton does not lock you into a specific structure. Maybe it should?
application/controllers/domain_object.php and would call the domain_object::task() method (and the request parameter "whatever" would be set to the value "whatever".
Or if modules were use then:
application/domain_object/controllers/task.php and would call the task::whatever() method.
I am really not sure the best way to do class loading. With Skeleton you can use the Locator to load or the load() method in Action Controller and View base classes. The load method uses the Mapper to let you load from the application, modules or controller directories -- so you can specify things relatively. I think you can do Model and View loading in a similar way to what you show above.
).
Hopefully the answers above clarify how and why things are done in Skeleton. Of course nothing is set in stone with Skeleton, so improvements are welcome. What you see is a bunch of trade-offs with the goal of creating the best overall result. Balancing all the competing forces within the design of a framework is a huge challenge -- certainly bigger than one person can handle.
Yikes that's a lot of questions! I will try to do my best to answer them. As I always note that Skeleton is an unreleased framework (the current download is a few months out of date). I can think of many, many problems with both the design and code. Volunteers are always welcome.volomike wrote:On the devnetwork Skeleton project, I was trying to understand the directory structure.
Well "A" was the shortest and first thing I thought of. The project is technically just "A Skeleton Framework" not "The Skeleton Framework".volomike wrote:- Why call it "A" when you guys call it Skeleton? Why not a folder named Skeleton?
The framework uses the PEAR namespacing convention that many other project use. So the class "A_Foo_Bar" can be found in the file "A/Foo/Bar.php" which makes class loading easy.volomike wrote:- Why does everything have to start with "A_" in the framework classes? Why not call the classes like "Model::classMethod()", "Controller::classMethod()", "View::classMethod()", "Cart::classMethod()"?
That is a folder to hold PHPSpec BDD scripts from when Pádraic Brady was involved in Skeleton (when he used to hang around DevNet). It is no longer used and we should delete it.volomike wrote:- What is "specs" in the root folder?
Sweety is a test runner by Chris Corbyn that he configured at one time to run the test suite. I think he has since developed a new version because this one had problems. It is no longer used and we should delete it. To run tests, use the tests/menu.php scripts.volomike wrote:- Why stick "sweety" (the template engine) in the root path?
This directory contains the unit tests for that go with the framework. I should clarify that the main directory that you are looking is not intended to be deployed as organized. In an actual deployment, the A directory would be put wherever you prefer it. It could be in the include path, in an applicaiton directory, in the public HTML directory, etc.volomike wrote:- Why are "tests" in the root path?
There are a number of possible layouts for the application directory. Some are shown in the documentation. There are several examples that show basic layouts. Skeleton support modules if you want them as well.
Skeleton supports, but does not require, clean URLs. So you can have URLs like "site.com?module=foo&controller=bar&action=baz" or URLs like"site.com/foo/bar/baz". There is a filter class (A_Http_Pathinfo) that can set the Request object from PATH_INFO. An example of the .htaccess for mod_rewrite is in examples/pathinfo.volomike wrote:- Where's your .htaccess file to load index.php for the front controller?
Again, the examples show the files needed for bootstrap. Most of them just put those include()s in index.php to remove the extra include, but you could certainly build such a file. There is some variety in bootstraps depending on how you like your apps organized. Skeleton is Repository-centric so you define you application context by what you provide in the Repository because it is injected into every Controller and View.volomike wrote:- Where's your bootstrap file to load common classes for the framework?
Actually the "Mapper" (A_Controller_Mapper) is the object that the controllers use to map module/controller/action information onto actual file paths. Its separation is an architectural difference. For example Zend passes the whole Front Controller around (or accesses it statically) to do the same thing. The "Router" is the filter I mention above which is a filter for Request. It is called A_Http_Pathinfo, but you make a good point that A_Http_Router would probably be clearer.volomike wrote:- You call it "Mapper", but I think the world calls it "Router". Why is that?
If you want all the decisions made for you there are plenty of other frameworks that do that. That's just not what Skeleton is. With Skeleton there is a little more flexibility in how you can organize things. And loose coupling and duck typing make most things replaceable. There are "basic_app" and "frontcontroller" examples you can grab as a starting place. We could certainly build an example that is organized like you are asking. If I can understand your directory layout below, I will put something together.volomike wrote:- In "examples" I find a front controller example. Why make that like an optional implementation? Why not just make it a default and if people don't like that they can choose to replace it? I mean, it makes it one more step one has to learn in order to use Skeleton.
There is also an A_Application class that is an all-in-on solution to what you are asking for. It turns the bootstrap into 3-4 lines. We are waiting for John Cartwright to fix that class though.
Those are some extra classes and functions that have been collected along the way. I am not sure that all will stay if there is ever a 1.0 release. What would be better names for those?volomike wrote:- You appear to have common library classes in A, but then why also have "classes" there and "functions" there?
In thei simplest directory structure you could just have:volomike wrote:- Where's the class for controllers, for models, and for views as part of the mechanics of this framework?
Code: Select all
index.php
controllers/
models/
views/Code: Select all
index.php
application/
controllers/
models/
views/Code: Select all
index.php
application/
admin/
controllers/
models/
views/
blog/
controllers/
models/
views/Code: Select all
public_html/
index.php
application/
controllers/
models/
views/
library/
A/
Swift/Again, Sweety is a test runner that is not used. There are template classes in the A/Template directory. Skeleton provide two basic template classes: A_Template_Include for PHP templates, and A_Template_Strreplace for {tag} style HTML templates. There is a wrapper around Smarty and some others (to adapt them to be used with the View/Response classes.volomike wrote:- Why have a "Template" class when you appear to use "sweety"?
Most of the classes in the main A directory are basic support classes that do not have a directory with them. Some like A_Validator are deprecated and there is now A_Validator_Set that does the same thing (and A_Validator_Abstract as well). So yes, you are right, the goal is to move everything multi-file into a directory. Where were you a year ago to get this right!volomike wrote:- Why are folders under "A" along with files? Why not a structure of Domain Object folders for the parts of the framework, and then files under that? I mean, let's take Validator.php. You could create a Validator folder and just put Validator.php inside. And if you need to grow Validator beyond one class, you already have a folder. It just is more logical to me.
I think I show this above. This and more complex directory structures are supported.volomike wrote:- Have you all considered a file hierarchy like the following? The {x} means folder.
.htaccess
index.php
{controllers} (or _controllers)
{models} (or _models)
{views} (or _views)
{system} (or _system or _library -- stuff for the framework)
The URL http://site.com/domain-object/task/whatever/whatever/ would be routed to:volomike wrote:The .htaccess calls index.php for all unrecognized URLs (the 404 trick). It loads the index.php as the front controller. The front controller can be minimal here, doing nothing but loading the system\bootstrap.php file, and doing the default routing of any URL that comes in so that:
http://site.com/domain-object/task/whatever/whatever/
is automatically routed to:
controllers/DomainObject/Task.php and whatever/whatever can be parsed inside that.
The page controllers folder can be empty except for the controllers/Home/Home.php file which gets called if someone hits the site like so:
http://site.com/
application/controllers/domain_object.php and would call the domain_object::task() method (and the request parameter "whatever" would be set to the value "whatever".
Or if modules were use then:
application/domain_object/controllers/task.php and would call the task::whatever() method.
There is a CI style load() method available in Controllers and Views. Models would be in the application/models or application/module/models directory. In a controller you load your models with:volomike wrote:The models folder can be empty and the Model::loadModel('DomainObject/SubDomainObject") class method can load stuff from models. Under models, for instance, I could create a folder "Employees" and then perhaps a class file like "Management.php". And then I could do Model::loadModel('Employees/Management') to load it in my page controller.
Code: Select all
$this->load()->model('foo'); // loads application/models/fooModel.phpIn a controller you load your models with:volomike wrote:The views folder can be empty except for the Home/Home.php file which gets called automatically if someone does something from Home/Home.php like: View::displayView($sView) where $sView is either empty or says "Home/Home".
Code: Select all
$this->load()->view(); // loads application/views/*controllername*View.phpHopefully the above made it clearer what is the application directory, public HTML directory and library directory (and that they can be combined or separated in any combination you prefervolomike wrote:In the system folder, you can store the classes that handle controllers, models, and views, and then the classes that provide all the goodies in Skeleton like DB, Filter, Email, PDF, Pagination, Cart, Captcha, etc.
Just saying that with a more logical file structure, it might make it easier to understand and use.
Hopefully the answers above clarify how and why things are done in Skeleton. Of course nothing is set in stone with Skeleton, so improvements are welcome. What you see is a bunch of trade-offs with the goal of creating the best overall result. Balancing all the competing forces within the design of a framework is a huge challenge -- certainly bigger than one person can handle.
(#10850)
- volomike
- Forum Regular
- Posts: 633
- Joined: Wed Jan 16, 2008 9:04 am
- Location: Myrtle Beach, South Carolina, USA
Re: Skeleton Directories
Here's what I recommend for Skeleton:
1. Consider renaming the A folder to "Skeleton".
2. Consider switching the way this thing is loaded with A_ and make it use class objects named sk_*, like sk_Controller, or just declare classes like Controller without the sk_* for now and when namespaces arrive in the mainstream, use those. Sure, you might have some namespace collision here if you name something like Controller, but I tend to live with it and workaround it. And when namespaces arrive in the mainstream, this problem will eventually be resolved.
3. Clean up the directory structure like you mention. It's not exactly like my recommended structure, but I understand your reasoning, and it's close. And also, if you have a single class, I still recommend creating a folder for it if it's part of your framework, and sticking that single class in there -- for consistency reasons and so it doesn't throw newbies like me for a loop. Besides, you can add other class files into that folder later on as necessary.
4. Go ahead and throw a CI-style front controller in, but have a commented out section below it to allow any kind of URL to be used instead (where then people handle routing with a switch/case statement). Or, make a config toggle where you can change the style there and it will load either section in the front controller. And yes, that means including an .htaccess file.
5. I'd say to switch from calling it Mapper to calling it Router which is more mainstream because you're handling URL routes in the common nomenclature. In my case with my MVC framework, however, I simply have a Controller class and I dispatch routes like so:
...this translates to:
...however, it's not exactly like that. Because I use CI-style URLs in my MVC, my front controller automatically fills in the stuff inside () after doing security checks on that string, but you get the idea.
6. On the idea of someone running your framework at command line, to be honest all I would see people doing is cherry-picking a class out for their small script here or there, so the idea of not having a hard-coded (or alternate-coded -- see last item in this message) front controller due to command line seems a little odd to me. Besides, if I'm going to call the classes at command line, I can path to it and go around the front controller.
7. Make the framework ready-to-go. You just copy the project over to a web directory, connect to it in your browser, and controllers/Home/Home.php automatically loads, calls models/Home/Home.php to get some data, and slaps it into the view under views/Home/Home.php, providing a Hello World output. Then all someone has to do is revamp Home/Home and also make other domain objects under controllers, models, and views as they see fit. To make someone understand this better, you could make Hello World also have a field and a submit button. The form could post with an action of "home/result". One fills out the field, you do the usual security voodoo on the field posting via a model and some framework object calls inside the model, and it outputs a result from Home/Result.php. This helps people understand how this framework works in less time. At underneath the result in Home/Result.php, you could have a Getting Started link that explains how to convert this simple example into a full-blown website with all the bells and whistles.
8. Take for instance the Home/Home.php example. Make it such that inside the page controller I don't have to instantiate anything except my custom model, and then when I get some data from that, I simply call View::assignVar('HELLO',$sData) and then View::displayView('Home/Home') (or also permit a default of View::displayView() and it looks at the controller pathing to determine what view to load). Note the rest is handled in the bootstrap, making it completely easy to use this thing without having to load all the classes I need manually. In models, where there's another Home/Home.php, yeah, you'll need to have Home.php have a class definition inside like:
And under views, it'll just be XHTML with either {VAR}, $VAR, VAR (a constant), or some XSLT style of variable insertion.
The end result would be a huge boost to Skeleton because:
- newbies would understand the directory structure if they've just learned MVC
- they could get started right away
- CI-style URLs make a whole lot of sense, and I like the fact that simply creating folders and files under "controllers" makes them automatically loadable, but if you have a toggle in a config file to an anything-goes-url format, you provide the best of both worlds
- you want valuable input on the project, and you don't want it to stagnate, so with these changes people would just "get it" a lot faster and be able to recommend improvements in the framework rather than get discouraged and not see the real value in it -- for instance, I see value in it finally
- it would still work at command line or another context besides web
And if you don't believe I'm on the right track here -- call a vote and surprise me. :)
1. Consider renaming the A folder to "Skeleton".
2. Consider switching the way this thing is loaded with A_ and make it use class objects named sk_*, like sk_Controller, or just declare classes like Controller without the sk_* for now and when namespaces arrive in the mainstream, use those. Sure, you might have some namespace collision here if you name something like Controller, but I tend to live with it and workaround it. And when namespaces arrive in the mainstream, this problem will eventually be resolved.
3. Clean up the directory structure like you mention. It's not exactly like my recommended structure, but I understand your reasoning, and it's close. And also, if you have a single class, I still recommend creating a folder for it if it's part of your framework, and sticking that single class in there -- for consistency reasons and so it doesn't throw newbies like me for a loop. Besides, you can add other class files into that folder later on as necessary.
4. Go ahead and throw a CI-style front controller in, but have a commented out section below it to allow any kind of URL to be used instead (where then people handle routing with a switch/case statement). Or, make a config toggle where you can change the style there and it will load either section in the front controller. And yes, that means including an .htaccess file.
5. I'd say to switch from calling it Mapper to calling it Router which is more mainstream because you're handling URL routes in the common nomenclature. In my case with my MVC framework, however, I simply have a Controller class and I dispatch routes like so:
Code: Select all
Controller::dispatchRoute('Employees/Create');Code: Select all
require_once('controllers/Employees/Create.php');6. On the idea of someone running your framework at command line, to be honest all I would see people doing is cherry-picking a class out for their small script here or there, so the idea of not having a hard-coded (or alternate-coded -- see last item in this message) front controller due to command line seems a little odd to me. Besides, if I'm going to call the classes at command line, I can path to it and go around the front controller.
7. Make the framework ready-to-go. You just copy the project over to a web directory, connect to it in your browser, and controllers/Home/Home.php automatically loads, calls models/Home/Home.php to get some data, and slaps it into the view under views/Home/Home.php, providing a Hello World output. Then all someone has to do is revamp Home/Home and also make other domain objects under controllers, models, and views as they see fit. To make someone understand this better, you could make Hello World also have a field and a submit button. The form could post with an action of "home/result". One fills out the field, you do the usual security voodoo on the field posting via a model and some framework object calls inside the model, and it outputs a result from Home/Result.php. This helps people understand how this framework works in less time. At underneath the result in Home/Result.php, you could have a Getting Started link that explains how to convert this simple example into a full-blown website with all the bells and whistles.
8. Take for instance the Home/Home.php example. Make it such that inside the page controller I don't have to instantiate anything except my custom model, and then when I get some data from that, I simply call View::assignVar('HELLO',$sData) and then View::displayView('Home/Home') (or also permit a default of View::displayView() and it looks at the controller pathing to determine what view to load). Note the rest is handled in the bootstrap, making it completely easy to use this thing without having to load all the classes I need manually. In models, where there's another Home/Home.php, yeah, you'll need to have Home.php have a class definition inside like:
Code: Select all
class Home_Home {
}
$Home = new Home_Home();
The end result would be a huge boost to Skeleton because:
- newbies would understand the directory structure if they've just learned MVC
- they could get started right away
- CI-style URLs make a whole lot of sense, and I like the fact that simply creating folders and files under "controllers" makes them automatically loadable, but if you have a toggle in a config file to an anything-goes-url format, you provide the best of both worlds
- you want valuable input on the project, and you don't want it to stagnate, so with these changes people would just "get it" a lot faster and be able to recommend improvements in the framework rather than get discouraged and not see the real value in it -- for instance, I see value in it finally
- it would still work at command line or another context besides web
And if you don't believe I'm on the right track here -- call a vote and surprise me. :)
- allspiritseve
- DevNet Resident
- Posts: 1174
- Joined: Thu Mar 06, 2008 8:23 am
- Location: Ann Arbor, MI (USA)
Re: Skeleton Directories
A_ is short and sweet... and reads like english to boot.volomike wrote:1. Consider renaming the A folder to "Skeleton".
2. Consider switching the way this thing is loaded with A_ and make it use class objects named sk_*, like sk_Controller, or just declare classes like Controller without the sk_* for now and when namespaces arrive in the mainstream, use those. Sure, you might have some namespace collision here if you name something like Controller, but I tend to live with it and workaround it. And when namespaces arrive in the mainstream, this problem will eventually be resolved.
What's wrong with the way things are loaded now? It makes autoloading really easy. Also, if I'm using a framework I don't want to have to "live with it and work around" its conventions. Maybe in your own code you can live with a class called Controller, but that's just not a suitable naming convention for a framework. Also, I've not really been impressed with namespaces in 5.3, and will probably stick with the current Zend/PEAR standard unless things change in the future. So I don't really consider the problem to be resolved with 5.3 namespaces.
I hope you don't mean hijacking the 404 error document call... that means google will see all of your pages as 404 error pages...volomike wrote:The .htaccess calls index.php for all unrecognized URLs (the 404 trick). It loads the index.php as the front controller.
Last edited by allspiritseve on Fri May 29, 2009 10:48 am, edited 1 time in total.
Re: Skeleton Directories
I might respond to some other points later, but as to the namespacing: I love the A_ ! It reads as plain English instead of some random prefix and is short and sweet as allspiritseve points out. In fact we should get a patent for that prefix 
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Skeleton Directories
I doubly vote for the full Skeleton or A prefix...no abbreviations their always confusing...
Symphony uses sfController -- which is great but tells you nothing about where the file is located whereas PEAR/Zend
Skeleton_Controller_*
Would map directly to Skeleton/Controller/*
Although it doesn't always make sense to map 1:1 like this in most cases it makes everything easier.
Symphony uses sfController -- which is great but tells you nothing about where the file is located whereas PEAR/Zend
Skeleton_Controller_*
Would map directly to Skeleton/Controller/*
Although it doesn't always make sense to map 1:1 like this in most cases it makes everything easier.
- volomike
- Forum Regular
- Posts: 633
- Joined: Wed Jan 16, 2008 9:04 am
- Location: Myrtle Beach, South Carolina, USA
Re: Skeleton Directories
Okay, so it looks like there's multiple opinions for:
Skeleton_Controller
skController
A_Controller
A couple went nuts with !!! on the A_ thing. Sorry -- I can understand wanting to stick with what you've already supported thus far. Perhaps it's too late to consider other ways of doing this if there's a huge movement behind Skeleton. And Matthijs said, well, it was short and logical to him.
My vote is on skController, but my vote doesn't count because I'm quite satisfied with my own MVC -- although I do look at Skeleton and other frameworks from time to time to see how they do something, and see if it inspires me to change on something.
And on the question about the ErrorDocument 404 thing -- no, I do it like this in my .htaccess:
And Google sees it just fine without 404's. I just sort of called it the 404 technique because, without that blurb above, it would most definitely go to the 403 or 404 error document.
Skeleton_Controller
skController
A_Controller
A couple went nuts with !!! on the A_ thing. Sorry -- I can understand wanting to stick with what you've already supported thus far. Perhaps it's too late to consider other ways of doing this if there's a huge movement behind Skeleton. And Matthijs said, well, it was short and logical to him.
My vote is on skController, but my vote doesn't count because I'm quite satisfied with my own MVC -- although I do look at Skeleton and other frameworks from time to time to see how they do something, and see if it inspires me to change on something.
And on the question about the ErrorDocument 404 thing -- no, I do it like this in my .htaccess:
Code: Select all
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [QSA]- allspiritseve
- DevNet Resident
- Posts: 1174
- Joined: Thu Mar 06, 2008 8:23 am
- Location: Ann Arbor, MI (USA)
Re: Skeleton Directories
Ah, ok. The way you described it was misleading, I have heard people discuss using the errordocument to make clean urls, but that should be a last resort kind of thing. The way you're doing it is basically how I do it as well.volomike wrote:And on the question about the ErrorDocument 404 thing -- no, I do it like this in my .htaccess: And Google sees it just fine without 404's. I just sort of called it the 404 technique because, without that blurb above, it would most definitely go to the 403 or 404 error document.
I would be OK with Skeleton_, though I prefer A_. With skController however, there's no way to distinguish a directory structure, which I think is essential.volomike wrote:Okay, so it looks like there's multiple opinions for:
Skeleton_Controller
skController
A_Controller
Oh, by the way: Anyone interested in Skeleton projects should check out the pagination code that arborint and I have been working on: viewtopic.php?f=50&t=100934
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Skeleton Directories
I am a little baffled that this is a point of confusion. I guess we could rename it to "A Framework"volomike wrote:Here's what I recommend for Skeleton:
1. Consider renaming the A folder to "Skeleton".
I am not clear about "the way this thing is loaded?" This PEAR naming has been around a long time. Zend took the same naming that Skeleton uses (Skeleton is much older), so for the controllers you mention in Zend its Zend_Controller_Front and in Skeleton it is A_Controller_Front. It is the same with most classes. Someone familiar with Zend would immediately be familiar with the class naming in Skeleton. I think the issue is that you are familiar with CodeIgniter. But if there is a naming convention to be similar to, I think more people will be familiar with Zend than CI.volomike wrote:2. Consider switching the way this thing is loaded with A_ and make it use class objects named sk_*, like sk_Controller, or just declare classes like Controller without the sk_* for now and when namespaces arrive in the mainstream, use those. Sure, you might have some namespace collision here if you name something like Controller, but I tend to live with it and workaround it. And when namespaces arrive in the mainstream, this problem will eventually be resolved.
We will continue with that cleanup. The other goal of keeping all class for a component in a directory is to make components easy to use stand-alone. Many of those directories can be used on their own because there are no dependencies to other framework classes. That has been a goal.volomike wrote:3. Clean up the directory structure like you mention. It's not exactly like my recommended structure, but I understand your reasoning, and it's close. And also, if you have a single class, I still recommend creating a folder for it if it's part of your framework, and sticking that single class in there -- for consistency reasons and so it doesn't throw newbies like me for a loop. Besides, you can add other class files into that folder later on as necessary.
I am not exactly sure what you mean "CI-style front controller", but it seems like you want an actual set of application directories that make it so you just unzip and it runs (instead of examples). That is a great idea and something we should do. I get the impression that you want something like the "codeigniter/CodeIngiter.php" script. Skeleton has the A_Application class (not currently working) that does the same kinds of thing. So your index.php would be:volomike wrote:4. Go ahead and throw a CI-style front controller in, but have a commented out section below it to allow any kind of URL to be used instead (where then people handle routing with a switch/case statement). Or, make a config toggle where you can change the style there and it will load either section in the front controller. And yes, that means including an .htaccess file.
Code: Select all
include 'A/Application.php;
$app = A_Application();
$app->run();I don't think you understood what I wrote above. The "Mapper" is an object that the Front and Action controllers use calculate paths. It does not actually "route" in the sense of scanning PATH_INFO and parsing it against registered routes. There is another class for that which should be called "Router". Just to be clear, with Skeleton the bootstrap looks something like this:volomike wrote:5. I'd say to switch from calling it Mapper to calling it Router which is more mainstream because you're handling URL routes in the common nomenclature. In my case with my MVC framework, however, I simply have a Controller class and I dispatch routes like so:
...this translates to:Code: Select all
Controller::dispatchRoute('Employees/Create');
...however, it's not exactly like that. Because I use CI-style URLs in my MVC, my front controller automatically fills in the stuff inside () after doing security checks on that string, but you get the idea.Code: Select all
require_once('controllers/Employees/Create.php');
Code: Select all
require_once('config.php');
require_once('A/DL.php');
require_once('A/Locator.php');
require_once('A/Http/Request.php');
require_once('A/Http/Response.php');
require_once('A/Http/Pathinfo.php');
require_once('A/Controller/Front.php');
require_once('A/Controller/Mapper.php');
$Response = new A_Http_Response();
$Request = new A_Http_Request();
$Router = new A_Http_Pathinfo();
$Router->run($Request);
$Registry = new A_Locator();
$Registry->set('Request', $Request);
$Registry->set('Response', $Response);
$DefaultAction = new A_DL('', 'home');
$ErrorAction = new A_DL('', 'error');
$Mapper = new A_Controller_Mapper('', $DefaultAction);
$Controller = new A_Controller_Front($Mapper, $ErrorAction);
$Controller->run($Registry);
echo $Response->render();There is not CLI support currently, but there could be. That was PCSpectra's conjecture.volomike wrote:6. On the idea of someone running your framework at command line, to be honest all I would see people doing is cherry-picking a class out for their small script here or there, so the idea of not having a hard-coded (or alternate-coded -- see last item in this message) front controller due to command line seems a little odd to me. Besides, if I'm going to call the classes at command line, I can path to it and go around the front controller.
I think your point about having a standard 'application' directory is a good one. We just have not done a release like that. Would you want to see an 'application' and 'public_html' directory in the same level as the 'A' directory? Or should the index.php be in the top directory so you just unzip and it works?volomike wrote:7. Make the framework ready-to-go. You just copy the project over to a web directory, connect to it in your browser, and controllers/Home/Home.php automatically loads, calls models/Home/Home.php to get some data, and slaps it into the view under views/Home/Home.php, providing a Hello World output. Then all someone has to do is revamp Home/Home and also make other domain objects under controllers, models, and views as they see fit. To make someone understand this better, you could make Hello World also have a field and a submit button. The form could post with an action of "home/result". One fills out the field, you do the usual security voodoo on the field posting via a model and some framework object calls inside the model, and it outputs a result from Home/Result.php. This helps people understand how this framework works in less time. At underneath the result in Home/Result.php, you could have a Getting Started link that explains how to convert this simple example into a full-blown website with all the bells and whistles.
Action Controllers in Skeleton are a lot like CodeIgniter controllers because of the load() helper. So in Skeleton the CodeIgniter example action would look like:volomike wrote:8. Take for instance the Home/Home.php example. Make it such that inside the page controller I don't have to instantiate anything except my custom model, and then when I get some data from that, I simply call View::assignVar('HELLO',$sData) and then View::displayView('Home/Home') (or also permit a default of View::displayView() and it looks at the controller pathing to determine what view to load). Note the rest is handled in the bootstrap, making it completely easy to use this thing without having to load all the classes I need manually. In models, where there's another Home/Home.php, yeah, you'll need to have Home.php have a class definition inside like:
Code: Select all
class Home_Home { } $Home = new Home_Home();
Code: Select all
class welcome extends A_Controller_Action {
function run($locator)
{
$this->load()->response()->view('welcome_message');
}
}Skeleton currently separates View objects which can be in a hierarchy from Template objects, although they can be mixed to an extent because they have the same base interface. This is an area that has not received much attention. It also brings up the question of how may frameworks (e.g. CodeIngiter and Zend) use the Controller as the View. It certainly adds convenience ($this->load->view() ) so the question is whether that should be supportedvolomike wrote:And under views, it'll just be XHTML with either {VAR}, $VAR, VAR (a constant), or some XSLT style of variable insertion.
I agree that making it work out of the box would be a great improvement. That is great suggestion. Above I asked whether adding 'application' and 'public_html' at the top level would make sense to you?volomike wrote:The end result would be a huge boost to Skeleton because:
- newbies would understand the directory structure if they've just learned MVC
- they could get started right away
Skeleton works the same way, I am not sure how you got a different impression? Putting files in the 'controllers' directory makes them automatically loadable just like in other frameworks.volomike wrote:- CI-style URLs make a whole lot of sense, and I like the fact that simply creating folders and files under "controllers" makes them automatically loadable, but if you have a toggle in a config file to an anything-goes-url format, you provide the best of both worlds
Agreed. It has to be easy to get up and running.volomike wrote:- you want valuable input on the project, and you don't want it to stagnate, so with these changes people would just "get it" a lot faster and be able to recommend improvements in the framework rather than get discouraged and not see the real value in it -- for instance, I see value in it finally
As I said above, no command line currently. The CLI comment was PCSpectra's design conjecture.volomike wrote:- it would still work at command line or another context besides web
I think you make a lot of great points that hopefully will make the framework easier to learn and use. Thanks.volomike wrote:And if you don't believe I'm on the right track here -- call a vote and surprise me.
(#10850)
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Skeleton Directories
Go Nuts!!! I love it!!!volomike wrote:Okay, so it looks like there's multiple opinions for:
Skeleton_Controller
skController
A_Controller
A couple went nuts with !!! on the A_ thing. Sorry -- I can understand wanting to stick with what you've already supported thus far. Perhaps it's too late to consider other ways of doing this if there's a huge movement behind Skeleton. And Matthijs said, well, it was short and logical to him.
My vote is on skController, but my vote doesn't count because I'm quite satisfied with my own MVC -- although I do look at Skeleton and other frameworks from time to time to see how they do something, and see if it inspires me to change on something.
But let's be clear that this is a naming discussion, and you can just never make everyone happy in naming discussions.
Skeleton uses the same kids of .htaccess, typically:volomike wrote:And on the question about the ErrorDocument 404 thing -- no, I do it like this in my .htaccess:
And Google sees it just fine without 404's. I just sort of called it the 404 technique because, without that blurb above, it would most definitely go to the 403 or 404 error document.Code: Select all
RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [QSA]
Code: Select all
RewriteEngine on
RewriteRule !\.[a-zA-Z0-9]{2,4}$ index.php(#10850)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Skeleton Directories
Mike: Why so convinced that skController makes more sense than mapping the class name to the directory name 1:1 -- at least with this conventional approach you can implement __autoload() to 'include' your class files auto-magically and avoid doing this manually...
I see no benefit to using skController? If the length of the class name is your concern...I don't know what to say...long English like variable names, class names and other namespaces are critical for me.
Whats in a name? Everything if you ask me...without labels it's impossible to accurate explain or describe something and describing something is exactly what writing software is all about.
skController? Why not just Controller? The prefix is to avoid namespace collisions I suppose, but then Framework_ or Skeleton_ does that as well and it's clear English.
I see no benefit to using skController? If the length of the class name is your concern...I don't know what to say...long English like variable names, class names and other namespaces are critical for me.
Whats in a name? Everything if you ask me...without labels it's impossible to accurate explain or describe something and describing something is exactly what writing software is all about.
skController? Why not just Controller? The prefix is to avoid namespace collisions I suppose, but then Framework_ or Skeleton_ does that as well and it's clear English.
- volomike
- Forum Regular
- Posts: 633
- Joined: Wed Jan 16, 2008 9:04 am
- Location: Myrtle Beach, South Carolina, USA
Re: Skeleton Directories
Yeah, I'm looking for another way to say it because I tend to mention it a good bit. Let me know what you would call the technique.allspiritseve wrote:Ah, ok. The way you described [the 404 thing] was misleading, I have heard people discuss using the errordocument to make clean urls, but that should be a last resort kind of thing. The way you're doing it is basically how I do it as well.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Skeleton Directories
Well ... "The 404 Thing" is catchy!volomike wrote:Yeah, I'm looking for another way to say it because I tend to mention it a good bit. Let me know what you would call the technique.
Code: Select all
ErrorDocument 404 /index.phpI should also note that the Skeleton Front Controller is designed for they kind of rewrite rule that you and I specified. Skeleton has a number of ways to catch dispatch errors. If you look in the example above there is a "default controller/action" and an "error controller/action". The default is dispatched where no controller/action is specified (e.g., mysite.com/). The error one is dispatched if the FC is unable to load the controller class (e.g. mysite.com/foo/ but no controllers/foo.php). Finally, if there is no method specified or the one specified is no found in the controller class, then it will call a default method name that you can specify (default is run() ). I recall that pytrin has suggested that there should be two different possible error handling methods -- one for when no method is specified and different one for when a method is specified but does not exist.
(#10850)
- allspiritseve
- DevNet Resident
- Posts: 1174
- Joined: Thu Mar 06, 2008 8:23 am
- Location: Ann Arbor, MI (USA)
Re: Skeleton Directories
In general I'd probably call it 'clean urls' or 'search engine friendly urls'. The rewrites just allow you to route everything to index.php. I think the fact that the one file handles all [non-file, non-folder] requests is more important than what would happen if the rewrite weren't there. If the rewrite weren't there you wouldn't use clean urls in the first place (generally) so I think the rewrite and the urls are both part of the same concept.volomike wrote:Yeah, I'm looking for another way to say it because I tend to mention it a good bit. Let me know what you would call the technique.