Imagine what a disaster it would be if every rails app had it's own slightly modified version of rails.
I don't know how extensible of a language Ruby is (certainly nowhere near as much as Forth and Lisp, though probably more than most other mainstream languages), but couldn't one argue that if you're building an app on top of Rails as your framework... you are, in fact, making a slightly modified version of Rails?
This is pure semantics, I know. But on the other hand, would such a thing really be bad? A Lisp web framework would be all about that, for instance.
I'm by no means a fan of PHP, but the author does have a point that it's essentially an ad-hoc templating system which lets you glue your own framework on the spot. Obviously it becomes a mess eventually, but it may be useful for small projects where you want to develop rapidly with minimal dependencies, or as a sort of Mozart coding philosophy.
I actually think it'd be very refreshing if we got more frameworks that aren't based on MVC, which instead simply give you some APIs and let you use them as you see fit. I know there are some, but they're not widespread. Although you could essentially just grab a bunch of libraries and that'd be equivalent.
I'm by no means a fan of PHP, but the author does have a point that it's essentially an ad-hoc templating system which lets you glue your own framework on the spot. Obviously it becomes a mess eventually, but it may be useful for small projects where you want to develop rapidly with minimal dependencies, or as a sort of Mozart coding philosophy.
You'd be surprised how un-messy it can be if you remove any arbitrary directory structures and arcane framework code.
A big part of making this work for me has been the adoption of "Template Animation"[1] (or DOM templating whatever you'd like to call it) which does away with the need for the server side code to "build" the interface.
Once you get rid of that, and provide an easy way for things to be split up and organised into classes, and if you avoid anything too far removed from "pure" PHP, it's really quite easy for anyone to come along and see what's going on.
Of course it gets messy if you let it get messy, though ;)
I actually think it'd be very refreshing if we got more frameworks that aren't based on MVC, which instead simply give you some APIs and let you use them as you see fit. I know there are some, but they're not widespread. Although you could essentially just grab a bunch of libraries and that'd be equivalent.
That's basically where I landed. My applications now are a bit of boilerplate configuration and a bunch of folders with class files in them, that I either write or get from somewhere else. Because the interfaces are built completely in static HTML anyway you don't get all this mess to do with where to store your "assets" and how to structure your views/templates.
PHP is an amazing tool for quick 50 line webpages.
The problem with non-MVC frameworks is that generally most programmers won't go through the hassle of making MVC style classes. MVC cuts across so many domains that there have to be some really compelling reasons to abandon it. I'm interested though, what do you like to use as an architecture alternative to MVC?
I'm not entirely sure of a concrete alternative pattern MVC for the web. I like the style of independent modules that frameworks like web.py provide, but that's not a unified pattern.
Pretty much all web design patterns are based on models and views, including MVC, HMVC, MVP, MVVM and so forth. Perhaps more of the latter two would be welcome, especially MVP.
Decentralized modules can still be quite useful for small apps. I don't think the hassle of forcing rigorous design patterns is necessary there.
Imagine what a disaster it would be if every rails app had it's own slightly modified version of rails.
I think a more appropriate analogy would be: what if there were 20 or 30 popular frameworks for building apps on Rails?
The bits that provide the consistency between Rails apps (ie. how requests get mapped to controllers, how arguments get passed into the application from the query string and how a response gets to the browser) are there in PHP already. You don't need a framework to know how PHP does those things.
It's quite painful to come across a PHP application which does these things using some sort of PHP framework you've never heard of. Even though you know how simple what's really going on is (ie. some web request is being processed, a response written and optionally some data loaded from a database or other source in between) you have to trawl through reams of documentation to find out what little spin this framework has put onto it.
Theres a lot going on in the article that I simply have no idea whats about (sorry, php is not my stack).
Probably unrelated to article, but indeed to the title: make your index.php a index.html. No, not completely static, make your application generate one. Most of your traffic hits is at your index (kinda obvious right). If you have a super dynamic index makes more sense generate a static html file with the new content, let's say, every 3 minutes, rather than generate the thing for everybody that hits your website root.
It's not exactly a secret, but sometimes people forgets completely about this. Not that useful for all scenarios though.
I'm pretty sure Rails, et al, use a single point of contact because that's kinda what web servers do.
I actually shivered a little bit thinking about an app where each url was in a new file somewhere. I mean, ack is only going to take you so far when you're trying to find out where something was implemented.
And that's to say nothing of URL passing between different URL paths.
Honestly, Django doesn't have an index.py file anywhere. Rather it has a urls.py and apart from some really gnarly projects, if you wanna know where something is implemented, you open the root urls.py file and follow the chain down to the app where your URL is being generated. That points you at a view and usually the form or model that's causing issues.
Rails, NodeJS, Django, they all do it with one entry point. That gives you maximum flexibility to decide what to do with a request once you've received it rather than already being locked into some particular approach based on path.
This is done in the "Routing" layer which also helps provide diagnostics when it comes to seeing which bit of code was engaged.
There's a term for what an app with hundreds if not thousands of loosely defined entry points is called: A mess.
I actually shivered a little bit thinking about an app where each url was in a new file somewhere. I mean, ack is only going to take you so far when you're trying to find out where something was implemented.
That's essentially what controllers are. How a URL gets mapped to a controller is somewhat moot, in reality most "pages" equate to either a file or a class somewhere.
I'm not advocating that one shouldn't have a single entry point. I'm advocating that it shouldn't be part of a centralised framework.
Aspen makes it a feature :). The code can still be organized, you can still have models and shared code. I think (although I don't use it in production) that it's quite refreshing.
Well, to be pedantic, most Django projects have a WSGI file, which is the single entry point of the application.
(The WSGI file is part of your application code, but it typically just calls django.core.wsgi.get_wsgi_application(), which returns an instance of django.core.handlers.wsgi.WSGIHandler, which is the entry point into the Django routing/despatch framework)
this could well be Java's influence, which took the C language's "main" function and hid it from the developer altogether
I don't believe Java has ever hid main. Neither does JavaFX, or J2EE, from what I've gathered working in the area. I could be wrong, and if I am, someone please correct me.
You're correct. What I was thinking of is actually the difference between C++ and Java. Whilst C++ has Object Orientation built into it, you still have to have a separate main function where as in Java you define a main method on at least one of your classes.
That'll teach me to write something without looking it up first :)
I'll update when I get back on a real computer (typing on the go right now), thanks.
Don't you need an index, or something approximating an index? Having an index lets you redirect requests which aren't to public resources (images, js, css) through that single point and by extension the url router. That's what it's for.
I actually don't mind an index.php with some gnarly procedural code. Sometimes code has to do what it has to do, and it doesn't always have to be pretty.
Access to static, public resources (images, js, css) should not be run through any dynamic language. Let the web server do what they do well: serve files. Or better yet, push that junk to a CDN.
Yeah, I wasn't clear, sorry, lack of sleep. It's usually .htaccess that either serves the static file or routes requests which don't hit a resource into index.php... but to me, that process, including .htaccess and an index file, would have to be an integral part of the framework.
The part that casually drops "PHP as a config language" is where this jumped the shark for me. I guess this isn't the worst practice I've seen in PHP, but it's definitely a notable one.
I guess it depends on what the use case is for configuration, but I'm envisioning times you want to allow for user/developer configurability of your program, or an installation being able to write out values that your program can use in its execution. Do you really want full programming language tools in your configuration level? Do you want an installation routine writing out a php script, or should it just serialize a config object to json / yaml?
I don't really have a problem with caching application writable config as something like serialized json or something like that, but I really dislike composer's configuration file format.
hmm, I think maybe we had different things in our minds regarding what a config script is.
I certainly don't think that the web server should be writing out executable php scripts, if that is what you are asking?
OTOH, I have seen many examples of php configuration files done by simply setting values in an array, looking up other values from other places and so forth - i.e., an executable configuration file written in php.
I think it is a bit of a jump though to assume that the author was suggesting that the web server be able to write executable php files?
I can't read this without thinking that the author isn't paying attention to the rest of the PHP community. Every point on the checklist is what composer was built to solve and it can be used without any framework. Even in terms of package creation, PSR-4 allows the author of a package to define their own directory structure and inform the autoloader what that structure is.
It's great to revisit assumptions, like using one index.php file for a whole project, but I think that's an area where talking to lots of people leads to the best solution.
I can't read this without thinking that the author isn't paying attention to the rest of the PHP community. Every point on the checklist is what composer was built to solve and it can be used without any framework.
I don't really like composer so I wrote my own package manager[1], but you could just as easily use composer with the cut down "framework" that RocketSled became if you preferred it. And yes, composer (and RocketPack) can be used without a framework. That's sort of the point: PHP doesn't need a "framework" as such, just various tools of choice (like composer if that's your bag).
in terms of package creation, PSR-4 allows the author of a package to define their own directory structure and inform the autoloader what that structure is
Actually, PHP allows you to do that with spl_autoload_register.
I find the "PSR-*" conversations to be pretty pointless and not very interesting. I have a basic autoloader that I wrote and I'm happy with ... BUT in PHP anyone can use any autoloading implementation that they like very simply. There doesn't need to be a standard way of doing things, so long as you provide me with something like a "bootstrap" or autoloader file that I can include in my project and have everything "Just Work(TM)".
The only time it becomes a challenge is if you're working within a framework which dictates your directory structure and/or the main entry point of the application. If I'm just creating my own index.php I can include whatever packages, autoloaders, whatever very simply.
Rails made php start using mvc? I'm not the only one thinking that's completely wrong, right? I was writing mvc based web apps in php long before rails arrived.
35 comments
[ 2.6 ms ] story [ 84.2 ms ] threadYet another, it's not a framework, it a mess, just copy some files, edit them, whatever, the framework is your application. So zen.
Imagine what a disaster it would be if every rails app had it's own slightly modified version of rails.
I don't know how extensible of a language Ruby is (certainly nowhere near as much as Forth and Lisp, though probably more than most other mainstream languages), but couldn't one argue that if you're building an app on top of Rails as your framework... you are, in fact, making a slightly modified version of Rails?
This is pure semantics, I know. But on the other hand, would such a thing really be bad? A Lisp web framework would be all about that, for instance.
I'm by no means a fan of PHP, but the author does have a point that it's essentially an ad-hoc templating system which lets you glue your own framework on the spot. Obviously it becomes a mess eventually, but it may be useful for small projects where you want to develop rapidly with minimal dependencies, or as a sort of Mozart coding philosophy.
I actually think it'd be very refreshing if we got more frameworks that aren't based on MVC, which instead simply give you some APIs and let you use them as you see fit. I know there are some, but they're not widespread. Although you could essentially just grab a bunch of libraries and that'd be equivalent.
You'd be surprised how un-messy it can be if you remove any arbitrary directory structures and arcane framework code.
A big part of making this work for me has been the adoption of "Template Animation"[1] (or DOM templating whatever you'd like to call it) which does away with the need for the server side code to "build" the interface.
Once you get rid of that, and provide an easy way for things to be split up and organised into classes, and if you avoid anything too far removed from "pure" PHP, it's really quite easy for anyone to come along and see what's going on.
Of course it gets messy if you let it get messy, though ;)
I actually think it'd be very refreshing if we got more frameworks that aren't based on MVC, which instead simply give you some APIs and let you use them as you see fit. I know there are some, but they're not widespread. Although you could essentially just grab a bunch of libraries and that'd be equivalent.
That's basically where I landed. My applications now are a bit of boilerplate configuration and a bunch of folders with class files in them, that I either write or get from somewhere else. Because the interfaces are built completely in static HTML anyway you don't get all this mess to do with where to store your "assets" and how to structure your views/templates.
[1]http://www.workingsoftware.com.au/page/Your_templating_engin...
The problem with non-MVC frameworks is that generally most programmers won't go through the hassle of making MVC style classes. MVC cuts across so many domains that there have to be some really compelling reasons to abandon it. I'm interested though, what do you like to use as an architecture alternative to MVC?
Pretty much all web design patterns are based on models and views, including MVC, HMVC, MVP, MVVM and so forth. Perhaps more of the latter two would be welcome, especially MVP.
Decentralized modules can still be quite useful for small apps. I don't think the hassle of forcing rigorous design patterns is necessary there.
I think a more appropriate analogy would be: what if there were 20 or 30 popular frameworks for building apps on Rails?
The bits that provide the consistency between Rails apps (ie. how requests get mapped to controllers, how arguments get passed into the application from the query string and how a response gets to the browser) are there in PHP already. You don't need a framework to know how PHP does those things.
It's quite painful to come across a PHP application which does these things using some sort of PHP framework you've never heard of. Even though you know how simple what's really going on is (ie. some web request is being processed, a response written and optionally some data loaded from a database or other source in between) you have to trawl through reams of documentation to find out what little spin this framework has put onto it.
Probably unrelated to article, but indeed to the title: make your index.php a index.html. No, not completely static, make your application generate one. Most of your traffic hits is at your index (kinda obvious right). If you have a super dynamic index makes more sense generate a static html file with the new content, let's say, every 3 minutes, rather than generate the thing for everybody that hits your website root.
It's not exactly a secret, but sometimes people forgets completely about this. Not that useful for all scenarios though.
I actually shivered a little bit thinking about an app where each url was in a new file somewhere. I mean, ack is only going to take you so far when you're trying to find out where something was implemented.
And that's to say nothing of URL passing between different URL paths.
Honestly, Django doesn't have an index.py file anywhere. Rather it has a urls.py and apart from some really gnarly projects, if you wanna know where something is implemented, you open the root urls.py file and follow the chain down to the app where your URL is being generated. That points you at a view and usually the form or model that's causing issues.
This is done in the "Routing" layer which also helps provide diagnostics when it comes to seeing which bit of code was engaged.
There's a term for what an app with hundreds if not thousands of loosely defined entry points is called: A mess.
That's essentially what controllers are. How a URL gets mapped to a controller is somewhat moot, in reality most "pages" equate to either a file or a class somewhere.
I'm not advocating that one shouldn't have a single entry point. I'm advocating that it shouldn't be part of a centralised framework.
(The WSGI file is part of your application code, but it typically just calls django.core.wsgi.get_wsgi_application(), which returns an instance of django.core.handlers.wsgi.WSGIHandler, which is the entry point into the Django routing/despatch framework)
I don't believe Java has ever hid main. Neither does JavaFX, or J2EE, from what I've gathered working in the area. I could be wrong, and if I am, someone please correct me.
That'll teach me to write something without looking it up first :)
I'll update when I get back on a real computer (typing on the go right now), thanks.
I actually don't mind an index.php with some gnarly procedural code. Sometimes code has to do what it has to do, and it doesn't always have to be pretty.
and in that context, it is perfectly reasonable, I think.
what issues do you have with the idea exactly?
I certainly don't think that the web server should be writing out executable php scripts, if that is what you are asking?
OTOH, I have seen many examples of php configuration files done by simply setting values in an array, looking up other values from other places and so forth - i.e., an executable configuration file written in php.
I think it is a bit of a jump though to assume that the author was suggesting that the web server be able to write executable php files?
It's great to revisit assumptions, like using one index.php file for a whole project, but I think that's an area where talking to lots of people leads to the best solution.
I don't really like composer so I wrote my own package manager[1], but you could just as easily use composer with the cut down "framework" that RocketSled became if you preferred it. And yes, composer (and RocketPack) can be used without a framework. That's sort of the point: PHP doesn't need a "framework" as such, just various tools of choice (like composer if that's your bag).
in terms of package creation, PSR-4 allows the author of a package to define their own directory structure and inform the autoloader what that structure is
Actually, PHP allows you to do that with spl_autoload_register.
I find the "PSR-*" conversations to be pretty pointless and not very interesting. I have a basic autoloader that I wrote and I'm happy with ... BUT in PHP anyone can use any autoloading implementation that they like very simply. There doesn't need to be a standard way of doing things, so long as you provide me with something like a "bootstrap" or autoloader file that I can include in my project and have everything "Just Work(TM)".
The only time it becomes a challenge is if you're working within a framework which dictates your directory structure and/or the main entry point of the application. If I'm just creating my own index.php I can include whatever packages, autoloaders, whatever very simply.
[1] https://github.com/iaindooley/RocketPack
http://www.google.com/trends/explore#q=Ruby%20on%20Rails%2C%...