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

alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Skeleton Directories

Post by alex.barylski »

I'm looking at the 'controllers' directory and I notice you have a controller for 'flash'??? Why is this?

My own framework has only a basic abstract controller (might even just be an interface now) but the idea of organizing controllers into modules like this is interesting to me...I'd like to hear more of the reasoning behind that if possible? :)
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 »

PCSpectra wrote:I'm looking at the 'controllers' directory and I notice you have a controller for 'flash'??? Why is this?

My own framework has only a basic abstract controller (might even just be an interface now) but the idea of organizing controllers into modules like this is interesting to me...I'd like to hear more of the reasoning behind that if possible? :)
To whom was this addressed, PC?
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 »

PCSpectra wrote:I'm looking at the 'controllers' directory and I notice you have a controller for 'flash'??? Why is this?

My own framework has only a basic abstract controller (might even just be an interface now) but the idea of organizing controllers into modules like this is interesting to me...I'd like to hear more of the reasoning behind that if possible? :)
If you are talking about Skeleton then that would be the Flash Helper that does RoR style flash() where you can save a value in the session and it exists for one request to be use on redirect/forwards/etc. So you can do $this->flash('Thanks for whatever!'); in the Action, and then echo $this->flash(); in the View on the next page. I think the Action Controller example shows this.

I am not sure what you mean by "organizing controllers into modules"? Do you mean separate directories of MVC directories?

FYI - the base Skeleton Action Controller is pretty lightweight -- more CI style. There are actually two Action controllers: A_Controller_Action and A_Controller_Action_Dispatch. The second adds pre/post dispatch filters and other things common in heavier Action Controllers. The Skeleton Front Controller does not require Action Controllers extend any base class to be dispatched, so there are three levels of functionality you can use depending on what you need (and they can be mixed).
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Skeleton Directories

Post by alex.barylski »

If you are talking about Skeleton then that would be the Flash Helper that does RoR style flash() where you can save a value in the session and it exists for one request to be use on redirect/forwards/etc. So you can do $this->flash('Thanks for whatever!'); in the Action, and then echo $this->flash(); in the View on the next page. I think the Action Controller example shows this.
Cool. So for error messages, etc? It has nothing to do with Flash the technology?
FYI - the base Skeleton Action Controller is pretty lightweight -- more CI style. There are actually two Action controllers: A_Controller_Action and A_Controller_Action_Dispatch. The second adds pre/post dispatch filters and other things common in heavier Action Controllers. The Skeleton Front Controller does not require Action Controllers extend any base class to be dispatched, so there are three levels of functionality you can use depending on what you need (and they can be mixed).
Interesting. How does distpatch provide pre and post filtering? Do you wrap the action controller in a dispatch controller, something like a decorator or similar?
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 »

PCSpectra wrote:Cool. So for error messages, etc? It has nothing to do with Flash the technology?
Yeah, nothing to do with Adobe Flash. That's just what they called in the RoR, so that's what it's called in most every framework.
PCSpectra wrote:Interesting. How does distpatch provide pre and post filtering? Do you wrap the action controller in a dispatch controller, something like a decorator or similar?
Skeleton has pre/post filters in the Front Controller that give you the controller object before and after it is dispatched. So you have complete access to the controller object with that to do lots of stuff. There are some prebuilt filters for calling a method (handy for Access Control) and for Dependency Injection. But those filters are global.

In addition, the A_Controller_Action_Dispatch allows the controller itself to have pre/post methods that are called before and after the dispatched method is called. Handy for doing things controller-wide.
(#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 »

arborint wrote:Yeah, nothing to do with Adobe Flash. That's just what they called in the RoR, so that's what it's called in most every framework.
I recall somebody a while back (last year?) trying to start a movement to rename it to "flare". Look how well that turned out. :)
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 »

arborint, I guess the Flash thing brings up a good point for me about the Skeleton framework. At what point do you begin to question and ask if something isn't just bloat that makes the framework harder to use because it includes too much, as well as potentially slows the framework down, versus something that makes a lot of sense to have in it? For instance, I think universally most senior PHP developers would tell you that an ActiveRecord implementation makes a tremendous amount of sense in any PHP framework, as is a conf settings API, cookie management, session management, etc. But sometimes even if an idea is just "cool", there are some things in my opinion that should be left out of a framework simply because they are just "nice haves" but not essential to most development, they slow down a project potentially, and they make the project more ominous to install and use, especially for newbies. And for everything else, make it into a plugin to the framework.

My two cents.
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:sometimes even if an idea is just "cool", there are some things in my opinion that should be left out of a framework simply because they are just "nice haves" but not essential to most development
For me, the flash feature is essential. It is the corollary to POST-Redirect-GET and allows for an (in my opinion) elegant balance between RESTful URLS and storing everything in the session. From a usability standpoint it allows me the most flexibility in passing messages back to users and keeping their form input saved without running into state problems. My two cents.
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Re: Skeleton Directories

Post by matthijs »

@volomike: about the flash thing: it is a useful feature and certainly not bloat. Zend framework has exactly the same thing.

But more in general I think it's important to realize that what you might call bloat is not bloat in reality. Most classes and components in the skeleton framework, just like those in ZF, are very independent standalone components. You can use them if you want, but you don't have to.
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:arborint, I guess the Flash thing brings up a good point for me about the Skeleton framework. At what point do you begin to question and ask if something isn't just bloat that makes the framework harder to use because it includes too much, as well as potentially slows the framework down, versus something that makes a lot of sense to have in it?
I agree a lot with this. I think what we have tried to do with Skeleton is to allow you to have bloat if you want it, but not require it. And example I mentioned above is that all of the major frameworks expect you to extend their Controller base class. That's not true with Skeleton. You can run it without a router and without a base controller class for simple applications or where you want very low overhead for performance (it is even faster that way). Or you can run it with the base Action Controller for a CI style minimal controller. Or with the more full featured Controller like bigger frameworks have. Or create your own base controller class. And you can mix them all within an application.

Neither of the built-in Action Controllers is a finalized design. I would be interested in the opinions of those we have strong views about Action Controller design and use cases.

I don't know where you draw the line at bloat. I do know that there will be a large percentage of programmers who will draw the line at a different spot from you. Dig through the bootstrap code in any framework and you will find tens if not hundreds of lines that I consider optional.
volomike wrote:For instance, I think universally most senior PHP developers would tell you that an ActiveRecord implementation makes a tremendous amount of sense in any PHP framework, as is a conf settings API, cookie management, session management, etc.
I don't use ActiveRecord, agree on config and sessions, but cookies are way down in the list behind many other features for me because they are just too simple to get/set. So you and I agree 50% -- which is pretty good. ;) As I said above, I would rather make something optional than draw the line. I find one of the most annoying things about working on a frameworks is being an advocate for a feature that many people like, but I don't use.
volomike wrote:But sometimes even if an idea is just "cool", there are some things in my opinion that should be left out of a framework simply because they are just "nice haves" but not essential to most development, they slow down a project potentially, and they make the project more ominous to install and use, especially for newbies. And for everything else, make it into a plugin to the framework.
The Flash Helper is a 'plugin', that's why PCSpectra noticed it because it is a separate file that is only loaded if you do $this->flash().
volomike wrote:My two cents.
An excellent two cents! ;) I'd be interested in where you draw the line for bloat and see if we can support that.

PS - I actually don't use the Flash feature! ;)
(#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 »

Okay, guys. I get it. I didn't realize it was such a desired feature, nor was already a plugin. I come at this from a different angle, where I'm growing my own framework, and I have to make decisions of bloat vs. usefulness. So it wasn't an attack on Skeleton, of course.
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, guys. I get it. I didn't realize it was such a desired feature, nor was already a plugin. I come at this from a different angle, where I'm growing my own framework, and I have to make decisions of bloat vs. usefulness.
Agreed. I think it is up to each programmer to draw the line between bloat vs. usefulness. It has been a goal of Skeleton to try to allow the programmer to do that more than other frameworks by providing multiple levels of solutions. If anything that has been a criticism (which you made above) that we don't pick one way an "Make the framework ready-to-go" as you said above. Having a ready-to-go application in the main directory is now on the To Do list thanks to you. I have already deleted the 'sweety' and 'specs' directory, plus removed some of the crufty classes (A_Validator, A_Filter) that you mentioned above. So your input is really appreciated. That was a great discussion above.

As an example, the Pagination component we recently did supports a ridiculous 6 levels of functionality. Part of the reason is that each of us did Pagination in a different way -- some wanting more control, others wanted a more all-in-one solution. We unfortunately have not had much critique of that code so we don't know how good it is. But hopefully it shows you how we try to allow each programmer to pick what they want to use and not having the overhead of things they don't want.
volomike wrote:So it wasn't an attack on Skeleton, of course.
Please, attack away. It is the only way the code will improve. I think you have raised an important point about what should be in the base Controller class. I am interested in what functionality you and others have in your base Action Controller class (where you draw the line). For example, do people list the ability to combine the Controller and View into a single Presentation class for simple pages like the auto-rendering that many frameworks have. What is you preferred way to load helpers? Etc. I'd be interested to see your Action Controller classes and what you think is the best way to do things.
(#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 »

With my framework, I've started very minimalist and hope to remain minimalist. Of course it's nowhere near as minimalist as, say, the limonade framework, but the goal is to make it easy to use so that it's not in your way and an not too academic of a thing, yet is capable, adaptable, and most of all, responsive.

With mine, my bootstrap loads other things of course, but mostly it loads a static Controller class, a static Model class, and a static View class. It then loads the front controller logic in index.php and stops.

When a connection comes in via the .htaccess hook to the index.php front controller, I then parse the URL, CI-style, and use something like this:

Code: Select all

// the initial URL was http://mysite.com/customer-ticket/settings/
Controller::dispatchRoute('CustomerTicket/Settings'); //which translates to controllers/CustomerTicket/Settings.php
[/size]

Why some framework authors want people to extend the Controller, Model, and View classes is beyond me. I haven't yet figured that one out as to why that would be interesting to do.

So that sends one to a page controller under the "controllers" folder. So, for instance, a login might be:

controllers/Members/Login.php

Now in Login.php, it's not a class file. I see in some frameworks that they may want you to extend some kind of page controller class or something. I don't make it that difficult. Instead, it's just an ordinary PHP file, and I provide a commented template that people can cut and paste into there and then start following the instructions.

So, typically what you would do in my framework in the page controller is interact with the static class methods of the Controller, Model, and View classes, such as:

Code: Select all

$sName = Controller::getVar('fldName');
Controller::redirectPage(U . 'err/BADLOGIN'); 
/*
where U, U_SSL, U_NOSSL, P, ACTION, ACTION_GROUP, ACTION_TASK -- these are all global constants:
U = current base URL when you strip out the ACTION on the URL
U_SSL/U_NOSSL = obvious
P = physical path for base URL
ACTION = strip out the domain and base URL and you get the ACTION part of the URL
ACTION_GROUP = if the url is http://mysite.com/members/login/, then ACTION_GROUP is members.
ACTION_TASK = if the url is http://mysite.com/members/login/, then the ACTION_TASK is login.
*/
$MemSettings = Model::loadModel('Members/Settings');
View::setVar('NAME',$sName);
View::displayView(); // assumes the current controller path for the view path out of "views" folder
View::displayView('Member/Settings');
 
[/size]
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:With my framework, I've started very minimalist and hope to remain minimalist. Of course it's nowhere near as minimalist as, say, the limonade framework, but the goal is to make it easy to use so that it's not in your way and an not too academic of a thing, yet is capable, adaptable, and most of all, responsive.

With mine, my bootstrap loads other things of course, but mostly it loads a static Controller class, a static Model class, and a static View class. It then loads the front controller logic in index.php and stops.
Well I can see a style difference immediately in that Skeleton actually tries not to use static calls. I know that Static factories can make things easy. I think it is better to work directly with object for a number of reasons which I think have been argued in these forums and elsewhere. Those reason may not matter to you. Skeleton solves the problem of providing access to commonly used objects by injecting a Registry into every Controller. That has been criticized. It is done to for consistency and customizablity. The bottom line difference is that you have multiple loaders where Skeleton has just one.

I should also note that with Skeleton you would probably not load any Models in index.php, maybe a DB connection class.
volomike wrote:When a connection comes in via the .htaccess hook to the index.php front controller, I then parse the URL, CI-style, and use something like this:

Code: Select all

// the initial URL was http://mysite.com/customer-ticket/settings/
Controller::dispatchRoute('CustomerTicket/Settings'); //which translates to controllers/CustomerTicket/Settings.php
[/size]
Yes, we talked about this earlier. I think we do almost exactly the same thing for .htaccess. However there is a difference in how loading works. For URL http://mysite.com/customerticket/settings/ the controller file would be 'controllers/customerticket.php' within that file would be a class named 'customerticket' and in this case the settings() method would be called.
volomike wrote:Why some framework authors want people to extend the Controller, Model, and View classes is beyond me. I haven't yet figured that one out as to why that would be interesting to do.
Base Controller and View classes provide common functionality, such as loading or connecting to other objects, in a single place. Those are pretty powerful features and really every framework implements tehm and most programmers ask for them. In Skeleton these classes are optional, so if you don't want then you don't even have the overhead of the static classes you load. I think Models are a little different because there are many possible base classes and styles of them.
volomike wrote:So, typically what you would do in my framework in the page controller is interact with the static class methods of the Controller, Model, and View classes, such as:
The advantages of using a class is that you can group related actions together and share their initialization. I don't really want to argue for or against it. I just know that this is how all of the major frameworks work and what the majority of programmers want. I didn't invent it but I know it works. ;)

Code: Select all

class members extends A_Controller_Action {
function __construct($registry) {
     // put common code here
     $this->MemSettings = $this->load()->model('Members/Settings');
}
// method called if URL is just http://mysite.com/members/
function run($registry) {
     $user = $registry->get('User');
     if ($user->isLoggedIn()) {
          $this->login($registry);
     } else {
          $this->login($registry);
     }
}
function login($registry) {
     $sName = $this->request->get('fldName');
     $this->forward('err/BADLOGIN'); 
     $view = $this->load()->view(); // assumes the current controller path for the view path out of "views" folder
     $view = $this->load()->view('login');
     $view->set('NAME',$sName);
     echo $view->render();
}
function logout($registry) {
     $view = $this->load()->view('logout');
     echo $view->render();
}
}
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Skeleton Directories

Post by alex.barylski »

volomike wrote:as well as potentially slows the framework down, versus something that makes a lot of sense to have in it? For instance, I think universally most senior PHP developers would tell you that an ActiveRecord implementation makes a tremendous amount of sense in any PHP framework, as is a conf settings API, cookie management, session management, etc. But sometimes even if an idea is just "cool", there are some things in my opinion that should be left out of a framework simply because they are just "nice haves" but not essential to most development, they slow down a project potentially, and they make the project more ominous to install and use, especially for newbies. And for everything else, make it into a plugin to the framework..
So long as the code is being executed, who cares if it adds bloat, it's obviously doing something for you. What I dislike about many applicaitons/frameworks is overhead bloat. That is, code that is included, parsed, but never executed. That to me is bloat worth worrying about.
For me, the flash feature is essential. It is the corollary to POST-Redirect-GET and allows for an (in my opinion) elegant balance between RESTful URLS and storing everything in the session. From a usability standpoint it allows me the most flexibility in passing messages back to users and keeping their form input saved without running into state problems. My two cents.
Not sure I ee the advantage or the purpose in using a controller for this, when you could set the message in a SESSION and fetch it and delete it when displayed next? I wrap all my session activity in a single session helper object so I know exactly what namespaces are being used for what...no namespace collisions, etc.

Flash is a misnomer IMHO, flash, in the context of any framework tells me Adobe flash player or something. I was thinking it must a controller/component that sets the default headers and creates a Flash object which is sent to it's request...I dunno...but I personally dislike the name.
But more in general I think it's important to realize that what you might call bloat is not bloat in reality. Most classes and components in the skeleton framework, just like those in ZF, are very independent standalone components. You can use them if you want, but you don't have to.
I think until we start talking in concrete numbers while comparing apples to oranges, anyone can use the term bloat to mean anything. If Mike feels framework A or B (not intentionally refering to skeleton A framework) that is his perogative.
And example I mentioned above is that all of the major frameworks expect you to extend their Controller base class. That's not true with Skeleton. You can run it without a router and without a base controller class for simple applications or where you want very low overhead for performance (it is even faster that way). Or you can run it with the base Action Controller for a CI style minimal controller. Or with the more full featured Controller like bigger frameworks have. Or create your own base controller class. And you can mix them all within an application.
That is the same approach I took with my own as well. Minimalist by design, Maximus by choice :D
Skeleton solves the problem of providing access to commonly used objects by injecting a Registry into every Controller. That has been criticized. It is done to for consistency and customizablity.
What were the criticisms, just curious? How else is a application supposed to share data? Globals? I htink injecting the registry into a controller context as opposed to pulling the registry in from the front controller or whatever is a much cleaner design. Keeps everything light weight and free of dependencies.
Post Reply