Proper way to design a 'skeleton' script? More...

[dagfinn]

I finally read this thread, which mostly happened while I was away on vacation but keep cropping up.

Although this is interesting and intelligent stuff, I'm going to be insufferably arrogant and disagree with the consensus.

The implementation seems too much inspired by the J2EE patterns which I find conceptually unfocused and too obsessed with "clever" object-oriented design. Fowler is much better.

IMHO, the Mapper hierarchy is unnecessary complexity. Better to translate all HTTP requests into object/method calls in a fixed way. That's because it simplifies the Front Controller code itself, but more importantly, because it makes for a more consistent way of using URLs and HTTP requests.

If you want to show a "page", you can easly do it from one of the actions. (BTW, I prefer the term "command". "Action" is ambigous: it it the action of the user or the software?).

[Aphenitry]

If you want to show a "page", you can easly do it from one of the actions. (BTW, I prefer the term "command". "Action" is ambigous: is it the action of the user or the software?).

I don't know, that depends on who is giving the command

[kyberfabrikken]

I finally read this thread, which mostly happened while I was away on vacation but keep cropping up.

Well ... We made a record there.

The implementation seems too much inspired by the J2EE patterns which I find conceptually unfocused and too obsessed with "clever" object-oriented design. Fowler is much better.

Possibly, but Fowler is also very shallow. There isn't much concrete in his handling of the FrontController pattern. That said, I think the idea of a mapperhierarchy goes nice in lieu with Fowler.

IMHO, the Mapper hierarchy is unnecessary complexity. Better to translate all HTTP requests into object/method calls in a fixed way. That's because it simplifies the Front Controller code itself, but more importantly, because it makes for a more consistent way of using URLs and HTTP requests.

Yes and no. PHP is different from other platforms because there is no single way of mapping an url. You can deal with this in one of two ways. Either you see it as an evil that must be undone by agreeing on a static mapping-method, or you accept that is the nature of PHP and you provide a framework for the different methods. We choose the latter. I think there is a point here, since all the frameworks available have their own way of mapping url's. By having a seperated mapper, it's actually possible to mix theese with eachother. Ofcourse if everybody would just agree on a standard the problem would be solved, but that's not going to happen.

If you want to show a "page", you can easly do it from one of the actions.

Recently I have begun to change my oppinion towards agreeing to that statement. Even though it's very easy to show a template from an action, it's still mental overhead if the alternative was simply creating one file. However by doing so we (I?) introduce a danger of mixing controller and view logic. It's probably better to enforce the separation by always having the Action->Template handler, rather than allowing for ServerPage's.

(BTW, I prefer the term "command". "Action" is ambigous: it it the action of the user or the software?).

I don't think Command is any less ambiguos than Action. Neither are good though, I'll agree to that.

[DougBTX]

Yes and no. PHP is different from other platforms because there is no single way of mapping an url.

An article reminded reminded me of this question, Can software have opinions?. It seems to me like there are two types of opinions you can have: ones that can be overriden, and ones which can't. Opinions are the result of making descisions, design and descision making go hand in hand.

IMO, our default mapping-method should self-contained, and it should support clean URLs.

Self-contained: it doesn't rely on framework code. It pulls data from the super globals and anywhere else it needs data from. This way, the whole thing can be replaced if someone wants another mapping method. I know, this will probably result in some code-reuse-via-copy-paste, but if three people turn up with completed mappers via cut-and-paste/their own code, we'll be in a better position so see what needs to be shared, if anything.

Clean URLs: well, this might be personal, but its the only reason I might be interested in the code.

Ofcourse if everybody would just agree on a standard the problem would be solved, but that's not going to happen.

Where "everyone" is "everyone who uses the code", think that's perfectly possible.

I don't think Command is any less ambiguos than Action. Neither are good though, I'll agree to that.

When I hear "command", I think of it as an instruction to do something. When I hear about an "action", I think that the code is doing something itself.

Which of those two do you want to have? (IMO, $_REQUEST is already a command, we don't really need to translate it into a PHP Application Command, we just need to act on it)

Douglas

[arborint]

I finally read this thread, which mostly happened while I was away on vacation but keep cropping up.

Although this is interesting and intelligent stuff, I'm going to be insufferably arrogant and disagree with the consensus.

The implementation seems too much inspired by the J2EE patterns which I find conceptually unfocused and too obsessed with "clever" object-oriented design. Fowler is much better.

Excellent. Tough criticism (followed with alternative code examples) made these threads a very worthwhile experience for me. I gained a lot of respect for kyberfabrikken, Ezku, Overrunner, etc. who contributed code and ideas to the process. We rarely agreed, but we kept hammering forward and produced interesting and useable code.

You are correct in your take on the implementation. However I think you perhaps misunderstand the goals. The reason you see it as "inspired by the J2EE patterns" is that the standard implementation that we did is a very straightforward controller architecture. There are others, such as how RoR does things, but the boring Page Controller or Front Controller/Input Controller are proven and are also the style that the implementators involved use. The part you missed (which I think is the unique part of the "skeleton" codebase) is that we made a concious effort to build things so that you are not locked into a single "way" to do your framework.

A goal of the "skeleton" code is to build a codebase from which you can roll your own framework. But since you are using common code, others can build extensions that you might be able to use. A pipe dream for sure, but we are part of the way there.

IMHO, the Mapper hierarchy is unnecessary complexity. Better to translate all HTTP requests into object/method calls in a fixed way. That's because it simplifies the Front Controller code itself, but more importantly, because it makes for a more consistent way of using URLs and HTTP requests.

The mappers are a key example of the kind of flexiblity we built in. They allow you to build you own custom style (there was an ActionPack example that did RoR style mappings) and it breaks the code into many small testable classes which is also a "skeleton" goal.

I am also not clear on what you mean by " Mapper hierarchy" because they are just plug-ins, not a hierarchy. Could you clarify that?

If you want to show a "page", you can easly do it from one of the actions. (BTW, I prefer the term "command". "Action" is ambigous: it it the action of the user or the software?).

I agree as well. Again, we have support for everything from Plain Old PHP Pages (POPPs?) through wizards, though perhaps none of it finalized.

I also prefer the term "command" as it relates to the Command pattern which is used often in controllers. "Action" is still useful term because no other word better describes the bridge from the request parameter to the controller dispached Command associated with that parameter value. When the term "action" seeps into other code it does get confusing.

All in all your criticisms are well founded and appreciated. I think the thing that we perhaps did not communicate, nor formally agree on, are the goals for the skeleton. Here are some of my thought on those goals:

- provide codebase from which experienced could roll our own frameworks

- provide one or two canned implementations that people like the original poster (cadmiumgreen where are you?) could move from script based PHP to controller based PHP.

- provide a common codebase on which extension developers could build interesting things like persistence code, ORMappers, Dependency Injection, etc.

- provide canned examples, but not the mini application examples that frameworks often do. Just small one or two page solution examples like a pager, a CRUD form page, a two page site with PHP page and a template page, etc. No fancy formatting, just the minimum code to use as a starting place do that thing.

- provide unit test for everything to produce a solid codebase and to aid future development

[dagfinn]

When I hear "command", I think of it as an instruction to do something. When I hear about an "action", I think that the code is doing something itself.

Which of those two do you want to have? (IMO, $_REQUEST is already a command, we don't really need to translate it into a PHP Application Command, we just need to act on it)

Douglas

I'm convinced that the terminology is important. The better we understand what the words mean, the greater our ability to create a design that's easy to understand because it's intuitive.

A command is a message expressing the user's intent. An action is either 1) what the user did (a user interface event such as clicking a button), 2) what the application does in response or even (in our context) 3) the code that generates the response.

Now the problem is that "command" is not used for just the message, but also for the code that responds to the message (the third meaning of "action" above). So this is still ambiguous, but at least it's conventional, since it's been used in that particular ambiguous way for decades in computing.

The word "request" means approximately the same as "command", but the HTTP request typically doesn't express the user's intent clearly enough for the purposes of a Web application. Lots of Web apps are full of code that basically tries to guess what's going on and what's supposed to happen based on a haphazard selection of request variables. Yes, that's Controller code, but making the HTTP request communicate more clearly is even more important than extracting the code into a separate Controller.

[arborint]

I'm convinced that the terminology is important. The better we understand what the words mean, the greater our ability to create a design that's easy to understand because it's intuitive.

A command is a message expressing the user's intent. An action is either 1) what the user did (a user interface event such as clicking a button), 2) what the application does in response or even (in our context) 3) the code that generates the response.

Now the problem is that "command" is not used for just the message, but also for the code that responds to the message (the third meaning of "action" above). So this is still ambiguous, but at least it's conventional, since it's been used in that particular ambiguous way for decades in computing.

The word "request" means approximately the same as "command", but the HTTP request typically doesn't express the user's intent clearly enough for the purposes of a Web application. Lots of Web apps are full of code that basically tries to guess what's going on and what's supposed to happen based on a haphazard selection of request variables. Yes, that's Controller code, but making the HTTP request communicate more clearly is even more important than extracting the code into a separate Controller.

Certainly understanding the many shades of meanings of "action", "command" and "request" is insightful, but within the domain of web software development these words have become jargon with fairly common usage:

- "action" is fairly specific to action parameters and the classes they map onto. Action parameters are different than other parameters in that they are used by a controller to directly invoke a class associated with the action parameter value.

- "command" in the discussions here usually relates to the Command pattern.

- "request" refers to the HTTP request or an class that encaptsulates it.

[DougBTX]

- "action" is fairly specific to action parameters and the classes they map onto.

Struts has a 1:1 mapping between actions and classes, doesn't meen we need to copy them.

- "command" in the discussions here usually relates to the Command pattern.

Is there much (any?) difference between a Struts-style Action and a Command object?

- "request" refers to the HTTP request or an class that encaptsulates it.

Yep.

Douglas

[dagfinn]

- "action" is fairly specific to action parameters and the classes they map onto. Action parameters are different than other parameters in that they are used by a controller to directly invoke a class associated with the action parameter value.

You may be right that "action" is more common in this context that "command", and it could be appropriate to go with the majority because it's the majority. But what I'm pointing out is that the "action parameter" is a technical name for something that expresses a more abstract concept called a command. That's why I think "command" is a better name. And Fowler seems similarly inclined.

[nacho]

IMHO,

"request" would be the encapsulation of the intructions issued to the application. This would be formed, at least, of a business "object" present in the application and a "command" (or method) we want to apply to this "object".
"command" would then be the concrete method we would like to apply to the business "object" referred to in the "request".
"action" is the fact of applying the "command" to the business "object".

E.g. (in a CRUD application):
"request" = (create|read|update|delete) an object
"command" = (create|read|update|delete)
"action" = object->command()

[arborint]

Struts has a 1:1 mapping between actions and classes, doesn't meen we need to copy them.

I wasn't implying that we should copy them, only that Struts and other frameworks have given "action" as fairly specific meaning.

Is there much (any?) difference between a Struts-style Action and a Command object?

An action does not have to result in involking a Command object. Many PHP programs use what could be called an action parameter but simple load a PHP script based on it. But in a OOP frameworks that's often how it is done because that's one thing the Command pattern is for.

[sweatje]

I wasn't implying that we should copy them, only that Struts and other frameworks have given "action" as fairly specific meaning.

Not sure I would go there, in Struts, is seems like every class has "Action" in the same somewhere: ActionForm, Action, ActionMapping, DynaActionForm... Seems like they went overboard with the term to the point of making it a bit vague again. Not that is seems to have put any kind of a dent in the popularity of the framework, after all, it is the "gold standard" of MVC frameworks.

[arborint]

You may be right that "action" is more common in this context that "command", and it could be appropriate to go with the majority because it's the majority.

Well, I wasn't saying that I liked how the words are currently used nor how appropriate their usage is. But they do have current meanings and part of the confusion is when they are given other meanings.

But what I'm pointing out is that the "action parameter" is a technical name for something that expresses a more abstract concept called a command. That's why I think "command" is a better name. And Fowler seems similarly inclined.

I tend to agree with you, but on the other hand "action" is a handy term to describe Command classes that are dispatched by a controller. Those classes can be several types of things (controllers, filter chains, views, etc.) so the more general term "action" is handy.

[arborint]

Not sure I would go there, in Struts, is seems like every class has "Action" in the same somewhere: ActionForm, Action, ActionMapping, DynaActionForm... Seems like they went overboard with the term to the point of making it a bit vague again. Not that is seems to have put any kind of a dent in the popularity of the framework, after all, it is the "gold standard" of MVC frameworks.

Unfortunately Struts is the 800 pound gorilla and the literature is filled with the term "action" whether we like it or not. Part of the confusion being discussed in this thread is when people who are not familiar with the current usage of "action" use it in different ways when talking to people who are familiar with the current usage.

[kyberfabrikken]

This would be formed, at least, of a business "object" present in the application and a "command" (or method) we want to apply to this "object".

I don't think an action nescesarily need to deal with a business-object. Nor does it need to restrict itself to deal with just one.

[nacho]

I don't think an action nescesarily need to deal with a business-object.

Well, it does by the way I look at it. Whether it is correct or not, I wouldn't know. If you prove me wrong though, I can always say I learnt something today.

Nor does it need to restrict itself to deal with just one.

I usually group objects if they become the object of the same request, that's way it is actually one.

[arborint]

Well, it does by the way I look at it. Whether it is correct or not, I wouldn't know. If you prove me wrong though, I can always say I learnt something today.

I usually group objects if they become the object of the same request, that's way it is actually one.

I think the main reason that the term "action" is used is because it is vague enough to encompass all of the different types of classes that can be executed. As I noted before, the skeleton code can dispatch Transaction Scripts in the form of PHP pages or classes, or another Controller, or a Helper class (often called Actions), etc. So when the code that can be run can be most anything, then we resort to describing the conditions under which that code is run.

[dagfinn]

Leaving the terminology aside for now, let me return to the real substance of my argument.

You are correct in your take on the implementation. However I think you perhaps misunderstand the goals. The reason you see it as "inspired by the J2EE patterns" is that the standard implementation that we did is a very straightforward controller architecture. There are others, such as how RoR does things, but the boring Page Controller or Front Controller/Input Controller are proven and are also the style that the implementators involved use. The part you missed (which I think is the unique part of the "skeleton" codebase) is that we made a concious effort to build things so that you are not locked into a single "way" to do your framework.

I don't think I missed it; at least I understand how it works. But I guess I'm questioning the need for it.

It's not a trivial question. Of course I could say that starting from this particular requirement, the implementation is fine. I guess that's what you're inviting me to do.

But let me pursue it a little bit further. The flexibility seems to be required, not to support a real-world requirement for features or programmer productivity, but simply to allow different programmers to more or less re-design the core of the system, so to speak.

Any flexibility that adds complexity makes the design a little less flexible in other ways, because it's harder to understand and therefore harder to change.

And the original poster might have been better served by something more "boring".

I guess I'm thinking in terms of what I would do if I wanted to make a framework for the real world: I would keep the implementation as minimal, robust and easy to maintain as possible.

Boring is good. If it's so obvious it's boring, we would have hit the nail on the head. That is utopia, bliss and perfection as far as I'm concerned.

Let me suggest two other options:

1. Have a standard Front Controller as a "microkernel" and add support for other "styles" on the outside, by making specialized command/action classes that would make it easy to use them.
2. Have a standard Front Controller and the flexible implementation as two completely independent, but interchangeable sets of classes. Beginners and people like me could use the standard Front Controller, and anyone who felt a real need for alternative styles could do that.

I am also not clear on what you mean by " Mapper hierarchy" because they are just plug-ins, not a hierarchy. Could you clarify that?

Since you ask specifically, it was just the first word that came to mind. When you say "plugins", it has to mean they can plug into the same place, which means they have a common interface--in the abstract sense. To me that implies two levels, even if it's not explicit in code.

- provide a common codebase on which extension developers could build interesting things like persistence code, ORMappers, Dependency Injection, etc.

This looks to me like an architectural decision to plug these things into the Front Controller. If it is, is that a wise thing to do? If not, how is it a "codebase" for these things?

[Dr Livingston]

Talking about Plugins for the moment, you need to be aware that there are Global Plugins and there are Local Plugins (ie applicable to a given request) so you need to differentiate these.

However, I don't think that the Front Controller is the correct layer to deal with Plugins, of any kind. What I mean is that you'd need some processing to know what Plugins to fetch prior to execution, and as I said some are only executable by a given request.

Do you really want that kind of logic in your Front Controller? I know I wouldn't, but I would have it a layer deeper such as the Application Controller for example

[arborint]

Leaving the terminology aside for now, let me return to the real substance of my argument.

I don't think I missed it; at least I understand how it works. But I guess I'm questioning the need for it.

It's not a trivial question. Of course I could say that starting from this particular requirement, the implementation is fine. I guess that's what you're inviting me to do.

But let me pursue it a little bit further. The flexibility seems to be required, not to support a real-world requirement for features or programmer productivity, but simply to allow different programmers to more or less re-design the core of the system, so to speak.

I think I agree with you in hindsight, but you need to understand the process we went through. Take the Front Controller as an example. We all agreed on the basics, but everyone mapped actions to classes in a different way. So we made the mappers plug-ins and that allowed us to all move forward and because we could still be able to try some of our own code on the new controller. And we discussed and learned a lot about the different mappings in the process. Now if the same group went through the process again knowing what we know now we would probably implement less flexiblity but more productivity.

Any flexibility that adds complexity makes the design a little less flexible in other ways, because it's harder to understand and therefore harder to change.

Yes, on the other hand as we found out the details of controllers are complex. That is one of the reasons why we'd all like to nail down a reasonable set of them that we could all use, because their complexity makes them difficult to get right.

And the original poster might have been better served by something more "boring".

I guess I'm thinking in terms of what I would do if I wanted to make a framework for the real world: I would keep the implementation as minimal, robust and easy to maintain as possible.

Boring is good. If it's so obvious it's boring, we would have hit the nail on the head. That is utopia, bliss and perfection as far as I'm concerned.

I agree with this as well. I think miminal, robust and easy to maintain are key. And I think if you look at FrontController and InterceptingFilter we got pretty close on those, not there, but close.

Let me suggest two other options:

1. Have a standard Front Controller as a "microkernel" and add support for other "styles" on the outside, by making specialized command/action classes that would make it easy to use them.
2. Have a standard Front Controller and the flexible implementation as two completely independent, but interchangeable sets of classes. Beginners and people like me could use the standard Front Controller, and anyone who felt a real need for alternative styles could do that.

I think refactoring the current code (or starting from scratch) to see if either or both of those directions produced something better would be useful. I would be interested in restarting on the Front Controller and being more real-world about it.

Since you ask specifically, it was just the first word that came to mind. When you say "plugins", it has to mean they can plug into the same place, which means they have a common interface--in the abstract sense. To me that implies two levels, even if it's not explicit in code.

Yes and as I explained above that was done because we could agree on everything except the mappings. I think kyberfabrikken's plugin mappers was a very workable solution to the problem we faced. But it is not that easy/natural for others to understand so re-exploring other solutions might produce something better.

"- provide a common codebase on which extension developers could build interesting things like persistence code, ORMappers, Dependency Injection, etc."

This looks to me like an architectural decision to plug these things into the Front Controller. If it is, is that a wise thing to do? If not, how is it a "codebase" for these things?

The goal was to implement the minimum yet allow extensiblity. Whether we actually achieved that or did it well? I think all involved would say it's not there yet.

I wish that you and others with similar comments like DougBTX had been involved in the process. It woud have produced better code and we would have all learned more.

[dbevfat]

I think there might be a bug in the skeleton Request class.

the condition in the constructor

if (!get_magic_quotes_gpc()) {
clean slashes
}

should not be negated, because get_magic_quotes_gpc returns true when it's on (so that's when you're supposed to clean).

just thought i'd mention it here as this thread is the official homepage of the skeleton

regards

[ParkinT]

I am out of breath!!