A single core class throughout a framework

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

Re: A single core class throughout a framework

Post by Christopher »

pytrin wrote:The only place that would be useful is that if you don't know which action controller you would be using (ie, the skeleton framework). Personally, I use only one type of action controller so that's never been a problem (as I said, this is much to personal preference). Still, to me the passed registries is too much of a compromise in this case and doesn't provide enough to make it worth it.

Not sure how that answers my question - do you use both in the same application? don't you choose one and use it exclusively in each application? changing between those two types is a major design decision. It will never be just about replacing one with the other.
Do you always use the same base Controller because you have no choice or because that is your choice? I do when I use Zend. With Skeleton I use no base Controller as well as building custom ones. As far as different Registries, I have reusable modules that work with either. If one or the other was hard-coded in places it would mean doing search-and-replace.
(#10850)
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: A single core class throughout a framework

Post by Eran »

I always extend the base zend controller with my own which provides project specific functionality. The Zend AC is the foundation however. I've been very pleased with it.

I know it's not relevant to this discussion, but we have differing views on what is a framework. I believe a framework should make choices on how things are done, not offer every possible choice. When you try to please everyone, you end up pleasing no one. The compromises borne out of trying to do everything equally well are not worth it.
User avatar
inghamn
Forum Contributor
Posts: 174
Joined: Mon Apr 16, 2007 10:33 am
Location: Bloomington, IN, USA

Re: A single core class throughout a framework

Post by inghamn »

pytrin wrote:I know it's not relevant to this discussion, but we have differing views on what is a framework. I believe a framework should make choices on how things are done, not offer every possible choice. When you try to please everyone, you end up pleasing no one. The compromises borne out of trying to do everything equally well are not worth it.
8O
Now you've gone and said it. Arborints going to come down on you like a ton of bricks!
*goes and gets popcorn*
:lol:
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Re: A single core class throughout a framework

Post by matthijs »

inghamn wrote:
pytrin wrote:I know it's not relevant to this discussion, but we have differing views on what is a framework. I believe a framework should make choices on how things are done, not offer every possible choice. When you try to please everyone, you end up pleasing no one. The compromises borne out of trying to do everything equally well are not worth it.
8O
Now you've gone and said it. Arborints going to come down on you like a ton of bricks!
*goes and gets popcorn*
:lol:
Actually, the troops are already on their way :)

But serious, I think that what Pytrin says is somewhat related to the topic of this thread, as both are about a design decision between
a) having a choice made for you (can be easier, can be restricting) or
b) having all options open (can be more flexible, can have other drawbacks)

probably depending on the situation and the preference of the developer(s) either one is a better choice in certain situations
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: A single core class throughout a framework

Post by Eran »

I'm not talking about having a choice made out for you. I'm talking about specializing and achieving better results through that specialization. Every developer has personal preferences, and I think it's better to use a framework that matches your preferences very well than a framework that tries to match everybody's preference but no one in particular. You are the one making a choice by picking that framework that matches your style and preferences.

It's a novel cause to try to come up with a fit-all solution, but I don't believe that one exists.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: A single core class throughout a framework

Post by josh »

there is a different between "making choices on how things are done" and "making choices on what gets done", the features, their implementations, 2 different concepts. Even if a framework is focused on one thing the key is that a framework in order to be defined as that has to be able to be used in multiple problem domains
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: A single core class throughout a framework

Post by Christopher »

pytrin wrote:I know it's not relevant to this discussion, but we have differing views on what is a framework.
I really don't think we have differing views on what is a framework. I know we have had this supposed disagreement on static Registries vs passed Registries. The differences in our opinions are very slight. You say if there is really only one then static is fine, I say if you can pass then pass. It is almost splitting hairs. I think your way is a fine choice and as good as mine -- better in some circumstances.
pytrin wrote:I believe a framework should make choices on how things are done, not offer every possible choice.
I don't know of any framework that that does not makes choices, or any that try to offer every possible choice -- Skeleton included. In fact, this discussion is about a choice that a framework makes that you don't like. ;)
pytrin wrote:When you try to please everyone, you end up pleasing no one.
Again, I don't know what framework is trying to please everyone. They all try to provide flexibility within the decisions they make. But as we see, those decisions don't please everyone.
pytrin wrote:The compromises borne out of trying to do everything equally well are not worth it.
Again I don't see any compromises, nor any framework trying to please everyone. I just see decisions that have some upsides and downsides. I use Zend. I use Cake. I use CodeIgniter. They are all a little different in how they do things.

Specific to Skeleton, there is a Singleton Registry class (A_Locator_Singleton) if you want to access the Registry that way instead of via the passed value -- so both styles are supported within Action Controllers. The differences in how common objects are communicated within the controller classes is an architectural difference that I don't think matters much to programmers using the framework. Skeleton makes a choice to allow no base Action Controller. That's just a choice, not trying to please everyone. If there are changes that you would like that would make in how common objects are accessed within the base Action Controllers (more like Zend or another framework) then we should implement those...
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: A single core class throughout a framework

Post by alex.barylski »

What is the reasoning one would:

1. Use a base controller class -- what functionality could possibly exist in a base controller that could be reused over and over again? Controllers are probably the least re-usable components in the MVC triad. Much of what I could do in a base controller I would want to explicitly do in my active controller for the explicit-ness of it -- of which I cannot htink of anything off hand.

2. Static registries. What difference does it make if one:

Code: Select all

Registry::getObject('MyObject');
or

Code: Select all

$registry->getObject('MyObject');
All I know from experience is that, the former is where I always wanted to go, because it was easier than injecting the registry into the controller at dispatch or whenever. The latter is what I eventually began doing because it made my controller less dependent and overall improved my code.

I suppose there are no real differences between solution A and solution B except for experience, I've tried all and concluded one indeed was worse than the other, not much mind you, but enough so the tables turned and I changed my design.

I am interested in hearing about base controllers though, I found myself wanting to stuff everything from the registry accessor (cause it wrapped the static) to the template and views, etc.

Slowly my controllers thinned out, especially in hierarchy, which caused so many more issues than it was worth.

Cheers,
Alex
User avatar
allspiritseve
DevNet Resident
Posts: 1174
Joined: Thu Mar 06, 2008 8:23 am
Location: Ann Arbor, MI (USA)

Re: A single core class throughout a framework

Post by allspiritseve »

PCSpectra wrote:Use a base controller class -- what functionality could possibly exist in a base controller that could be reused over and over again? Controllers are probably the least re-usable components in the MVC triad. Much of what I could do in a base controller I would want to explicitly do in my active controller for the explicit-ness of it -- of which I cannot htink of anything off hand.
I am not well read on the intricacies of controllers, but my base class currently has: an execute method that delegates to a GET() or POST() method depending on request method; a template method that allows me to add shared classes to a template (there's probably a better way of doing this) and a method that retrieves an action name from a submit button (All of my submit buttons have name="action[save]") so I can differentiate between multiple submit buttons. All of those save me ugly, repetitive code.
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: A single core class throughout a framework

Post by Eran »

Again I don't see any compromises, nor any framework trying to please everyone. I just see decisions that have some upsides and downsides. I use Zend. I use Cake. I use CodeIgniter. They are all a little different in how they do things.
What we were discussing is exactly one of those compromises. Since the front controller does not know which action controller it will be running, or even if it will be calling an action controller at all, it can't make assumptions about it and has to pass around a registry. Since you want to support all options (no action controller / multiple different action controllers), you have to have this as you've explained.

The same compromise was made on the database abstraction component in which you wanted to support all manners of abstraction, and even very basic (in my opinion) delete / insert / update operations were delegated to a wrapper. All those further abstractions in the name of flexibility make the overall design much more complex than it would've been if the scope of what the framework can do was smaller and more focused.

Even in your most recent component, the pagination component, you used view helpers that are not a part of the frameworks base view stack (which it doesn't have at this point), so there is no chance for reuse of the native view components of the framework. In the name of modularity you've created less chances for abstraction / code reuse and more chances for confusion. If that is not a compromise, I don't know what is.
1. Use a base controller class -- what functionality could possibly exist in a base controller that could be reused over and over again? Controllers are probably the least re-usable components in the MVC triad. Much of what I could do in a base controller I would want to explicitly do in my active controller for the explicit-ness of it -- of which I cannot htink of anything off hand.
A quick run down of stuff in my base controller:
1. ACL (access on a controller level)
2. Extended view initializing (overwritten Zend initView() since I don't use the layout component).
3. Some shortcut methods for accessing the request object functionality.

In addition to that I use a base controller per module that has module specific settings. Those are more application dependent and includes common setup routines that are used by several actions / controllers in that module.

Overall I found base controller classes to be pretty useful for reducing code duplication and increasing development speed.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: A single core class throughout a framework

Post by Christopher »

pytrin wrote:What we were discussing is exactly one of those compromises. Since the front controller does not know which action controller it will be running, or even if it will be calling an action controller at all, it can't make assumptions about it and has to pass around a registry. Since you want to support all options (no action controller / multiple different action controllers), you have to have this as you've explained.
All Front/Action Controller systems need ways to communicate between the controllers. Each framework does it a little differently. But that communication has no effect really on what the interface that the Action Controller provides to the programmer. It is really an internal design issue. So I don't see how it matters that much when using a framework. The functionality provided by the Action Controllers is unrelated to this internal scheme.
pytrin wrote:The same compromise was made on the database abstraction component in which you wanted to support all manners of abstraction, and even very basic (in my opinion) delete / insert / update operations were delegated to a wrapper. All those further abstractions in the name of flexibility make the overall design much more complex than it would've been if the scope of what the framework can do was smaller and more focused.
It's not "all manners" but only two levels of abstraction. The lowest level is just a connect()/query()/escape() style adapter interface, the second adds the Gateway style interface like Zend has. So the only difference is that Skeleton allows you to use a more minimal class if you want to. It certainly does not make it hard to include the full featured class. I recall the reason was that other database classes like ActiveRecord, TableDataGateway, etc. only needed the minimal connector.

I actually think that the layered approach is "smaller and more focused." I should point out that this is one area that shows a design difference with Zend. With Skeleton the minimal class is around 5k and the full featured on is under 20k. With Zend you only get the full featured option and it is over 70k. Admittedly there is a ton of functionality in the Zend class. But I think I am like most people in that I don't use most of it when I use Zend.
pytrin wrote:Even in your most recent component, the pagination component, you used view helpers that are not a part of the frameworks base view stack (which it doesn't have at this point), so there is no chance for reuse of the native view components of the framework. In the name of modularity you've created less chances for abstraction / code reuse and more chances for confusion. If that is not a compromise, I don't know what is.
I am not exactly sure what the argument is here, since what you are complaining about has not been written? I am guessing that we will do a bad job when we implement it though. ;) I don't see how we've created less chances for abstraction of code reuse. I assume that a framework View Helper when written would be as abstract as in the stand-alone version. And it would use probably reuse the stand-alone helper so there would be reuse. You could certainly use the current code as a View Helper by simply loading the standalone class. If you used some of the other classes you would need to pass the Pagination object to the helper. I assume that that is the main thing that the framework View Helper would do.

So I really don't see the lack of abstraction or reuse, using the View Helper does not seem confusing because it does everything for you. And on top of all that, you can use the Pagination component standalone without a framework (or with any framework).
(#10850)
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: A single core class throughout a framework

Post by Eran »

I actually think that the layered approach is "smaller and more focused." I should point out that this is one area that shows a design difference with Zend. With Skeleton the minimal class is around 5k and the full featured on is under 20k. With Zend you only get the full featured option and it is over 70k. Admittedly there is a ton of functionality in the Zend class. But I think I am like most people in that I don't use most of it when I use Zend.
I don't see how quoting file size is any indication of anything. First off you use very a minimalistic commenting scheme, and comments account for at least 50% of the actual size of some classes in the ZF. Other differences in coding styles account for more. Anyway, I was not aware that lower script file size is an ideal to be reached.

Second, I didn't say that Zend's is the ideal that everybody should strive for. I was just making an example of how a compromise was made to accommodate two approaches that resulted in a more complex class hierarchy. In this particular example the difference was slight - but again, it was just an example.
I am not exactly sure what the argument is here, since what you are complaining about has not been written?
I am not "complaining", I am just pointing out those compromises that you said were not there. Again, it is obviously my personal opinion only - to you it might be the best solution available.
I was referring to how you've written "view helpers" that are supposed to work standalone. This means, that whatever view stack you develop for your framework, this component was designed to work without it - and that even if that view stack is present, its capabilities could not be reused in the pagination component.
This could indicate you might've opted to develop the view stack before writing view-related components. I don't know. In any case, since your priority was to make that component completely stand-alone, you avoid opportunities for code-sharing and reuse within the framework (cause those would be "dependencies").
using the View Helper does not seem confusing because it does everything for you
Right now it doesn't seem confusing (though I was confused several times throughout your discussions which is why I stopped following), but when you have a separate view stack that organizes helpers in a certain manner, and individual components that organize their own helpers differently, that's when you create the confusion.

Maybe I'm completely wrong on everything I said and maybe there's some merit in there somewhere. Up to you what you do with it.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: A single core class throughout a framework

Post by Christopher »

pytrin wrote:Second, I didn't say that Zend's is the ideal that everybody should strive for. I was just making an example of how a compromise was made to accommodate two approaches that resulted in a more complex class hierarchy. In this particular example the difference was slight - but again, it was just an example.
I don't see the complex class hierarchy. It's only 2 classes + 1 abstract, Zend uses 5-8 files spread across several directories. And I don't see the compromise. I'd be happy to put anything you think is a good idea into the full class. Design your perfect interface and let's implement it. The existence of a lower layer with minimal functionality does not require any compromise yet adds an option.
pytrin wrote:I am not "complaining", I am just pointing out those compromises that you said were not there. Again, it is obviously my personal opinion only - to you it might be the best solution available.
I was referring to how you've written "view helpers" that are supposed to work standalone. This means, that whatever view stack you develop for your framework, this component was designed to work without it - and that even if that view stack is present, its capabilities could not be reused in the pagination component.

This could indicate you might've opted to develop the view stack before writing view-related components. I don't know. In any case, since your priority was to make that component completely stand-alone, you avoid opportunities for code-sharing and reuse within the framework (cause those would be "dependencies").
There is a View Stack and you could load the Pagination classes from it. I think the question of how to simplify access to Helpers in the View is interesting. I am not sure whether the directory full of Helpers like Zend is the best solution. Skeleton has Helpers that can be loaded. The question is how to provide a really easy way to access/use them.
pytrin wrote:Right now it doesn't seem confusing (though I was confused several times throughout your discussions which is why I stopped following), but when you have a separate view stack that organizes helpers in a certain manner, and individual components that organize their own helpers differently, that's when you create the confusion.
I would hope that the components would organize their view helpers in a standard way. I wonder if there is a way allow any component to have its view helpers integrated into the view stack -- along with one the application provides. Now you have me thinking. :)
pytrin wrote:Maybe I'm completely wrong on everything I said and maybe there's some merit in there somewhere. Up to you what you do with it.
The thing I don't understand is if there is an interface that provides everything that you want, what does it matter if there is also a simpler or more complex interfaces that shares that codebase? Especially if they are layered so that there is essentially 100% code reuse. It seems like there can be several layers that have merit. Why limit another option that someone else wants or some other code can use. Maybe it adds a small amount of complexity, but I don't see the compromise...
(#10850)
User avatar
allspiritseve
DevNet Resident
Posts: 1174
Joined: Thu Mar 06, 2008 8:23 am
Location: Ann Arbor, MI (USA)

Re: A single core class throughout a framework

Post by allspiritseve »

pytrin wrote:Even in your most recent component, the pagination component, you used view helpers that are not a part of the frameworks base view stack (which it doesn't have at this point), so there is no chance for reuse of the native view components of the framework. In the name of modularity you've created less chances for abstraction / code reuse and more chances for confusion. If that is not a compromise, I don't know what is.
Part of that is that we were truly releasing the Pagination component standalone-- tying it to any core Skeleton classes would mean extra classes and/or unused functionality in the context of pagination-- and by far the most common response we've gotten for that component is 'why so many classes?' :)
Post Reply