Skeleton Directories

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
volomike
Forum Regular
Posts: 633
Joined: Wed Jan 16, 2008 9:04 am
Location: Myrtle Beach, South Carolina, USA

Skeleton Directories

Post by volomike »

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.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Skeleton Directories

Post by alex.barylski »

arborint would be the one to answer but I'll chime in anyways (before bed):
Why call it "A" when you guys call it Skeleton? Why not a folder named Skeleton?
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 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()"?
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.
What is "specs" in the root folder?
I assume they are specifications...PHPSpec...BDD instead of TDD and SimpleTest???
Why stick "sweety" (the template engine) in the root path?
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. :P
Why are "tests" 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. :)
Where's your .htaccess file to load index.php for the front controller?
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 bootstrap file to load common classes for the framework?
Same as above...again only a guess. :)
You call it "Mapper", but I think the world calls it "Router". Why is that?
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.
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.
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.

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.
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".
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.

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.
Just saying that with a more logical file structure, it might make it easier to understand and use.
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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Skeleton Directories

Post by Christopher »

Thanks Alex! :)
volomike wrote:On the devnetwork Skeleton project, I was trying to understand the directory structure.
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:- Why call it "A" when you guys call it Skeleton? Why not a folder named Skeleton?
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 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()"?
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:- What is "specs" in the root folder?
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:- Why stick "sweety" (the template engine) in the root path?
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 are "tests" 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.

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.
volomike wrote:- Where's your .htaccess file to load index.php for the front controller?
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 bootstrap file to load common classes for the framework?
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:- You call it "Mapper", but I think the world calls it "Router". Why is that?
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:- 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.
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.

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. ;)
volomike wrote:- You appear to have common library classes in A, but then why also have "classes" there and "functions" there?
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:- Where's the class for controllers, for models, and for views as part of the mechanics of this framework?
In thei simplest directory structure you could just have:

Code: Select all

index.php
controllers/
models/
views/
Though typically you would have an application directory

Code: Select all

index.php
application/
     controllers/
     models/
     views/
If you used modules you could have something like this:

Code: Select all

index.php
application/
     admin/
          controllers/
          models/
          views/
     blog/
          controllers/
          models/
          views/
And finally a good practice is to separate public, application and libraries like this:

Code: Select all

public_html/
     index.php
application/
     controllers/
     models/
     views/
library/
     A/
     Swift/
All of those structures are easy to do. Skeleton does not lock you into a specific structure. Maybe it should?
volomike wrote:- Why have a "Template" class when you appear to use "sweety"?
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 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.
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:- 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)
I think I show this above. This and more complex directory structures are supported.
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/
The URL http://site.com/domain-object/task/whatever/whatever/ would be routed to:

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.
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.
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:

Code: Select all

$this->load()->model('foo');    // loads application/models/fooModel.php
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".
In a controller you load your models with:

Code: Select all

$this->load()->view();    // loads application/views/*controllername*View.php
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.
volomike 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 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 prefer ;)).

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)
User avatar
volomike
Forum Regular
Posts: 633
Joined: Wed Jan 16, 2008 9:04 am
Location: Myrtle Beach, South Carolina, USA

Re: Skeleton Directories

Post by volomike »

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:

Code: Select all

Controller::dispatchRoute('Employees/Create');
...this translates to:

Code: Select all

require_once('controllers/Employees/Create.php');
...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:

Code: Select all

class Home_Home {
}
 
$Home = new Home_Home();
 
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. :)
User avatar
allspiritseve
DevNet Resident
Posts: 1174
Joined: Thu Mar 06, 2008 8:23 am
Location: Ann Arbor, MI (USA)

Re: Skeleton Directories

Post by allspiritseve »

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.
A_ is short and sweet... and reads like english to boot.

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.
volomike wrote:The .htaccess calls index.php for all unrecognized URLs (the 404 trick). It loads the index.php as the front controller.
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... 8O
Last edited by allspiritseve on Fri May 29, 2009 10:48 am, edited 1 time in total.
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Re: Skeleton Directories

Post by matthijs »

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

Post by alex.barylski »

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.
User avatar
volomike
Forum Regular
Posts: 633
Joined: Wed Jan 16, 2008 9:04 am
Location: Myrtle Beach, South Carolina, USA

Re: Skeleton Directories

Post by volomike »

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:

Code: Select all

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [QSA]
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.
User avatar
allspiritseve
DevNet Resident
Posts: 1174
Joined: Thu Mar 06, 2008 8:23 am
Location: Ann Arbor, MI (USA)

Re: Skeleton Directories

Post by allspiritseve »

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.
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:Okay, so it looks like there's multiple opinions for:
Skeleton_Controller
skController
A_Controller
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.

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
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Skeleton Directories

Post by Christopher »

volomike wrote:Here's what I recommend for Skeleton:

1. Consider renaming the A folder to "Skeleton".
I am a little baffled that this is a point of confusion. I guess we could rename it to "A Framework" ;)
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.
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: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.
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: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.
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:

Code: Select all

include 'A/Application.php;
$app = A_Application();
$app->run();
But there are also ways to configure the app and replace things as well.
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:

Code: Select all

Controller::dispatchRoute('Employees/Create');
...this translates to:

Code: Select all

require_once('controllers/Employees/Create.php');
...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.
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:

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();
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.
There is not CLI support currently, but there could be. That was PCSpectra's conjecture.
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.
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: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();
 
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:

Code: Select all

class welcome extends A_Controller_Action {
 
    function run($locator)
    {
        $this->load()->response()->view('welcome_message');
    }
}
volomike wrote:And under views, it'll just be XHTML with either {VAR}, $VAR, VAR (a constant), or some XSLT style of variable insertion.
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 supported

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
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:- 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
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:- 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
Agreed. It has to be easy to get up and running.
volomike wrote:- it would still work at command line or another context besides web
As I said above, no command line currently. The CLI comment was PCSpectra's design conjecture.
volomike wrote:And if you don't believe I'm on the right track here -- call a vote and surprise me. :)
I think you make a lot of great points that hopefully will make the framework easier to learn and use. Thanks.
(#10850)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Skeleton Directories

Post by Christopher »

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.
Go Nuts!!! I love it!!! :) This is all great input.

But let's be clear that this is a naming discussion, and you can just never make everyone happy in naming discussions. ;) I understand that you are familiar and like the CI naming style. Skeleton uses the PEAR/Zend naming style. As I said, being similar to Zend probably makes it more sense than being like CI. It is funny because some people love that 'A_' is short and sweet, yet you hate it -- naming!
volomike wrote: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]
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 uses the same kids of .htaccess, typically:

Code: Select all

RewriteEngine on
RewriteRule !\.[a-zA-Z0-9]{2,4}$ index.php
So Skeleton would work fine with the .htaccess you are currently using. The Skeleton one is just a little different with fewer rules.
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Skeleton Directories

Post by alex.barylski »

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.
User avatar
volomike
Forum Regular
Posts: 633
Joined: Wed Jan 16, 2008 9:04 am
Location: Myrtle Beach, South Carolina, USA

Re: Skeleton Directories

Post by volomike »

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.
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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Skeleton Directories

Post by Christopher »

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.
Well ... "The 404 Thing" is catchy! ;) I think you mean using ErrorDocument rather than Rewriting. The Apache configuration directive is:

Code: Select all

ErrorDocument 404 /index.php
The problems with this obviously is that all of your routes return a 404 error.

I 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)
User avatar
allspiritseve
DevNet Resident
Posts: 1174
Joined: Thu Mar 06, 2008 8:23 am
Location: Ann Arbor, MI (USA)

Re: Skeleton Directories

Post by allspiritseve »

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.
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.
Post Reply