phpguru.org

lol! yeah - I know.

ok, ZF is good if you're talking about very large applications ("enterprise", even), but I wouldn't use it for anything less than that - "smaller" projects such as PHPBB3, OsCommerce, WordPress would suddenly become much harder to install and hack around in if they used ZF.

Note: the Model is *NOT* the database.

In many applications and frameworks the database is mistakingly mentioned as the model. The model however is your business logic. A common mistake is to mix business logic into the controller, which is a violation of MVC.

I'm not really sure what you mean by a 'whole' framework. I don't currently use any of the publicly available frameworks but I can see the logic behind them. Over the past few years I've assembled and refined a small set of files which I can use during the development of projects to get off to a good start. This is my framework. You probably have something similar whether you call it a framework or not.

I consider this a logical approach. By re-using code I save myself a lot of time. There is also some appeal in furthering this code re-use by working with others in a publicly available framework.

Is the purpose of this post to say frameworks are universally a silly idea or that they should only be built around obscure and seemingly illogical design patterns?

a framework makes sense in two ways:

- you don't need to write so much documentation for *your* way of doing it (because the documentation is already part of the framework).

- new members can join a project without having to learn *your* way of doing it, they just need to learn the way the framework does it (or, even better, they might already have experience with the framework)

so it's all about standards.

@Kae
> "smaller" projects such as PHPBB3, OsCommerce,
> WordPress would suddenly become much harder to
> install and hack around in if they used ZF.

That is not true. Please get your facts straight. A simple rewrite rule is all you need to adjust.

@Richard
I think whatever framework you use (CakePHP, ZendFramework or Symfony) - the advantage is you standardize on a concept and technique. I understand your "concern" that you can achieve the same with regular PHP code, but I am sure you agree that in 99% of all cases where people use standard PHP (no flavours added), it turns into a mess sooner or later.

That's where I see the advantages of any of those frameworks. Maintainable code.

If you like MVC - totally debatable. Why not, is my opinion on the subject. Even not so skilled or less experienced developers understand the concept and this is the second reason to select a framework - instant productivity. (Reads like an a cheesy advertisement, but found it to be true. I've seen it myself in multiple projects so far.)

I've worked with MVC for close to a decade now (originally in perl). Sure, you can build "MVC Frameworks", but when it comes down to the nuts and bolts, you don't need much. The model is typically just a class that has methods for accessing your data. The view can be PHP files or scripts written using your favorite templating engine (Smarty, PHPTAL, etc.). The main functionality that you need to deliver for MVC, however, is the Controller -- the functionality for determining what models and views are going to be used. The simplest "MVC Frameworks" offer just that: a controller. I myself ported CGI::Application to PHP, and it offers just that, a controller.

That said, when all you have is a controller, some home brewed model classes, and a template engine, you don't have much, and you have to do a lot of your own plumbing. A good MVC framework will offer much more -- ways to abstract the request and response so you can test your applications; flexible mapping techniques to map URLs to specific controllers and actions; a rich view layer providing layout capabilities, placeholders, partials, etc; AJAX integration; and ways to provide alternate output formats on request (for REST, AJAX, and more). Once you have that sort of rich functionality for your controllers and views, you'll often want the same sort of convenience for your model... and may find that your models aren't always databases, but may be web services, feeds, text, images, etc.

So, my point is that, to quote you, MVC may seem "like the logical way to do things" and not require a framework, but frameworks tend to spring up around MVC to make things simpler and more convenient.

Additionally, as others have pointed out, frameworks tend to create coding standards and conventions. With these and the rich variety of components available, coding using a framework tends to lead to, in the end, less and more maintainable code (though you may have more files and a more complex directory hierarchy).

Ivo:

You're confusing a three tier architecture (ala Model, View, Controller) with a four tier architecture (ala Model, Domain, View, Controller).

> Note: the Model is *NOT* the database.
>
> In many applications and frameworks the
> database is mistakingly mentioned as the model.
> The model however is your business logic. A
> common mistake is to mix business logic into
> the controller, which is a violation of MVC.

You are correct in that the model should not be called the DB because although one method of persistence could be DB it could also be a web service or flat file. However, the Model is the abstraction of your persistance mechanism which is certainly no place for business logic as it ties an implementation to a policy.

In abscence of a Domain tier the best place for policy (aka business logic) is the controller. When you've got a Domain tier then it should be used for policy to avoid coupling application workflow to policy.

Mike: I disagree,

in a 3-tier approach, the best place for business logic is the model. Say you are making a hotel reservation system. The view is the layout of your reservation engine, while the controller handles the application flow when, say, making a reservation.

The model in this case represents the business logic of a Reservation, with all business rules associated to it. These business rules are based on database data for a large part but also on code.

This way, your Reservation model is reusable in multiple applications, in the frontend reservation system for end users (with its own V and C) and in the backend reservation system for the hotel owners.

@Mike

> In abscence of a Domain tier the best place for
> policy (aka business logic) is the controller.

I disagree also, I generally follow the "skinny controller, fat model"-approach. Because controllers are app specific and modules are meant to be modular (= reusable code).

> I'm not really sure what you mean by a 'whole'
> framework. I don't currently use any of the
> publicly available frameworks but I can see the
> logic behind them.

I can't. I can however (of course) see the point in code reuse.

> Over the past few years I've
> assembled and refined a small set of files which
> I can use during the development of projects to
> get off to a good start. This is my framework.
> You probably have something similar whether you
> call it a framework or not.

I do, and I do. Perhaps not what many would call a framework, but I don't really care. http://dictionary.reference.com/browse/framework

> I consider this a logical approach. By
> re-using code I save myself a lot of time.
> There is also some appeal in furthering this
> code re-use by working with others in a
> publicly available framework.

Granted.

> Is the purpose of this post to say frameworks
> are universally a silly idea

Not at all.

> or that they
> should only be built around obscure and
> seemingly illogical design patterns?

Nope.

Lars Pohlmann:
> a framework makes sense in two ways:
>
> - you don't need to write so much documentation
> for *your* way of doing it (because the
> documentation is already part of the
> framework).

But if you write it so that your code or methodology is straightforward, you won't need to document it, (much).

> - new members can join a project without having
> to learn *your* way of doing it, they just need
> to learn the way the framework does it (or,
> even better, they might already have experience
> with the framework)

A PHP developer really shouldn't have to learn how require_once() code works... :-)

> so it's all about standards.

Standards do not mean that something has to be (over) complicated though.

> I think whatever framework you use (CakePHP,
> ZendFramework or Symfony) - the advantage is
> you standardize on a concept and technique. I
> understand your "concern" that you can achieve
> the same with regular PHP code, but I am sure
> you agree that in 99% of all cases where people
> use standard PHP (no flavours added), it turns
> into a mess sooner or later.

Most of the time yes, but with a little (or a lot) discipline, it needn't.

> That's where I see the advantages of any of
> those frameworks. Maintainable code.

You can write maintainable code without a traditional framework. Although in the process of doing so you would tend to create one without intending to.

> If you like MVC - totally debatable. Why not,
> is my opinion on the subject. Even not so
> skilled or less experienced developers
> understand the concept and this is the second
> reason to select a framework - instant
> productivity.

That's why I use PEAR (that and a lot of my own code is in there) - lots of freely available high quality code. All you really need to do is cut and paste from the PEAR website.

> Additionally, as others have pointed out,
> frameworks tend to create coding standards and
> conventions.

It could be argued that you should have these with or without an MVC framework.

> With these and the rich variety of
> components available, coding using a framework
> tends to lead to, in the end, less and more
> maintainable code (though you may have more
> files and a more complex directory hierarchy).

I disagree. For all of the projects I've worked on big and small, all I've needed were a few directories, such as htdocs, includes, and templates. Keeping them tidy just takes a little self-discipline.

I think the advantage of using such a framework is that even though one may have the best intentions of doing things "right," unless you are sometimes forced to do something a certain way, you'll begin to break your own rules.

Using a framework such as Code Igniter takes some of the architecture thinking out of the picture for you as well so you can get down to coding the fun stuff. Add some code-generation on top of that with something like "Ignition" and you've got a running application rather quickly and once again, you can get to coding "the good stuff" instead of worrying about things like persistence, session control etc.

Some frameworks however do take their "organizational efforts" a bit far...(like Rails IMHO)...and decisions of the frameworks authors get in your way.

I think thats why I prefer Code Igniter to any other framework I've used to day. It forces you into a pattern, but then gets the hell out of your way so you can do your thing.

Just my 2 GB...

> I think the advantage of using such a framework
> is that even though one may have the best
> intentions of doing things "right," unless you
> are sometimes forced to do something a certain
> way, you'll begin to break your own rules.

Breaking rules isn't so bad, but how much you disregard them is what makes the difference. Personally I think that getting things done quickly, (whilst not creating unmaintainable code) is more important than forcing yourself to write code a certain way.

> Using a framework such as Code Igniter takes
> some of the architecture thinking out of the
> picture for you as well so you can get down to
> coding the fun stuff.

Once you've got a "framework" hammered out though, you should be able to reuse it without thinking.

I think thats why I prefer Code Igniter to any
> other framework I've used to day. It forces
> you into a pattern, but then gets the hell out
> of your way so you can do your thing.

Any code that forces me into a particular way of coding can go blow. To put it poltely... :-)

Richard: one thing that a number of people are pointing out is that with a mainstream framework, you can bring on new developers who have experience in that framework, and they can hit the ground running -- instead of needing to learn how the in-house framework works. Sure, they may "force" you to code in a particular way, or using particular conventions (Zend Framework actually is nice that way, as it uses PEAR standards -- if you code towards PEAR CS, you'll be okay with ZF typically) -- but it's better to conform to standard coding styles than to invent your own.

Additionally, why re-invent the wheel? If somebody else has done it and done it well, why bother coding your own? That's just adding to your development, and adding another code base you need to maintain.

It's about making sure that your *team* of developers can work and play well together and be productive, and that new members to the team can be productive immediately.

PHPGuru ? and you don't have experience of simple design patterns? Come on guys, learn some and then you'll stop creating the horrific mess of code already mentioned here, like PHPBB3 or Wordpress.

Also ZF is not a framework! Its a component library just like PEAR (but not over designed and badly implemented) or like ezComponents - who have the grace to call their library what it is!

> PHPGuru ? and you don't have experience of
> simple design patterns?

MVC isn't "simple". And the decision not to use something should not be confused with lack of experience.

> Come on guys, learn
> some and then you'll stop creating the horrific
> mess of code already mentioned here, like PHPBB3
> or Wordpress.

Well I didn't create those apps.

> Also ZF is not a framework!

Strange; what's it called again?

> Its a component
> library just like PEAR (but not over designed
> and badly implemented)

I think PEAR is great. And you don't have to signup to the "PEAR" way - you can just copy and paste from the website into your own codebase.

Richard Heyes:

> > With these and the rich variety of
> > components available, coding using a
> framework
> > tends to lead to, in the end, less and more
> > maintainable code (though you may have more
> > files and a more complex directory
> hierarchy).
>
> I disagree. For all of the projects I've worked
> on big and small, all I've needed were a few
> directories, such as htdocs, includes, and
> templates. Keeping them tidy just takes a
> little self-discipline.

I think you may have misread this. The initial point was that a framework typically involves more files and directories but less code that is more maintainable. At least that is how I read it.

> Also ZF is not a framework!

Strange; what's it called again?

I would say you are both right. I've never used it but from what I've read Zend framework can be used as a framework but it is built from small blocks which can be used individually. If you use it like that then it is more a library than a framework.

I think its bad enough that PHP doesn't get the respect from the development community that it deserves its things like this:

"I think PEAR is great. And you don't have to signup to the "PEAR" way - you can just copy and paste from the website into your own codebase."

That give other developers that PHP is just a big mess of functions etc. I'm all for "rolling your own" and doing things your own way, but in the long run, thats only going to get you so far. Someone mentioned that having someone else come on board and being able to hit the ground running is an asset and i tend to agree.

MVC is indeed simple...very simple. If rolling your own is the way you want to go, more power to you. I'm going to bet however that doing this in a larger development shop won't fly.

How can we compete with the Java's of the world if we're all doing something different and in most cases, not even similar. In the Java world most are using Struts or Faces. I don't know of many people who write/have written their own framework in-house, mainly due to time constraints and standards/best practices.

Finally, I'll address the following: "Breaking rules isn't so bad, but how much you disregard them is what makes the difference. Personally I think that getting things done quickly, (whilst not creating unmaintainable code) is more important than forcing yourself to write code a certain way."

I agree, we all know when to break rules, etc. However, I can guarantee that that established frameworks such as Code Igniter, CakePHP, Symfony, Prada, etc can get things done ALOT quicker and ALOT cleaner than any home-grown app simply because these established have a following for more than just the author. For example...I can have a fully functioning app with CRUD functionality up in minutes using CI & Ignition. Same story with things like Django and Rails, or CakePHP, etc.

If speed of development is all you're worried about...why not use Rails, (not that I'm a big fan, but you do get going fast AND its REAL OO from the ground up).

Not to beat a dead horse, (too late I know) but I highly suggest checking out an established framework. I think you'll see that they still allow and awful lot of freedom for you to do your thing, results in cleaner and more maintainable code, and allows you to do it all quickly.

Richard Heyes:
> > Also ZF is not a framework!
>
> Strange; what's it called again?
>

lol delicious wit! Seriously, its not - but you should definitely check it out, especially if you love PEAR stuff.

You can just include some of their files and have access to a wealth of features. It has better documentation than PEAR, isn't as heavyweight (on the whole), its cleanly and loosely architectured (thats just a good thing, you may not care why it just is).

You don't even have to touch the MVC part! You should also check out ezComponents as well - they also have a fantastic array of features that are also cleaner, leaner and somewhat meaner than PEAR (both are cut from PHP5 cloth only).

Also, increasingly these technologies are being adopted by your future employers so why not learn something new today.

Whoa...my comment didn't come across very well at all....I must have had some bad text editing going on...damn touchpads...

so just ignore me...sorry for the clutter.

I think it is a mistake to claim that frameworks are built around the concept of MVC. This is a single design pattern, and while it may inform the way a framework expects your code to be organized, it is a relatively trivial part of what frameworks actually bring to the table.

The main justification I can see for frameworks (and I too find it a little odd to be saying this on a site called phpguru), is the way that they provide a unified approach (and code libraries) for the concerns that are shared by almost all web applications. Things like:
- data access
- authentication
- authorization
- data validation
- i18n/l10n
- user preferences
- etc.
I would argue that anyone that reinvents those components for every new application is foolish and anyone that doesn't is using a framework of some sort.

Too often I think, MVC is conflated with structuing your code into a three tier separtion of concerns, and since structuring your code, and seperation of concerns is good, MVC is good. However, MVC as a pattern wasn't designed around the web problem, and doesn't (to my mind) solve it very effectively.

A good post (with some good links) on the subject is http://iandavis.com/blog/2007/09/mvc-obscures-the-mechanics-of-the-web

A major problem with MVC as a pattern for web development (particulary webdev with PHP's shared-nothing architecture) is that it was designed for a desktop environment, where the application is instantiated once, and then the state of the application is continually updated by user interaction. With a PHP web app, the application is ideally as stateless as possible, and is instantiated anew on each request. So MVC doesn't seem great for web apps from that perspective.

Keith: I disagree. With the rise of XHR as a fundamental part of most web 2.0 apps, web applications are increasingly event oriented, regardless of the shared nothing architecture. Additionally, most frameworks provide a way to map a URL to a specific resource in the application, which makes the semantics of the URL make *more* sense, particularly when it comes to REST services or allowing a resource to have multiple views based on request parameters.

Hi Matthew. XHR makes an application seem more stateful on the client-side, but on the server side, it's the same - the 'application' is instantiated on each request.

I agree that URIs representing resources, which can have multiple representations does make a lot of sense, but you don't need to buy into the whole of MVC to get a resource / representation seperation.

Ivo & Till;

I see your POV but still disagree. I far more frequently re-use my models across applications than I do controllers. My controller is typically implementation specific where-as my models aren't.

If the policy is implemented in the model I either need to make it configurable or I need to alter the model to make changes to policy across applications.

I could extend the model but thats not really any different to implementing it in a domain layer.

Anyway; We're digressing ;)

On the subject of MVC frameworks I think its just buzzwordization.

MVC is a simple concept; simple enough to be common sense IMO. Rasmus Lerdorf illustrated this perfectly here http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework.html

Frameworks are toolkits. Their sole purpose is to make a developers life easier. If a frameworks primary touting point is MVC it's probably on the crappy side.

lifewithryan:
> I think its bad enough that PHP doesn't get the
> respect from the development community that it
> deserves its things like this:
>
> "I think PEAR is great. And you don't have to
> signup to the "PEAR" way - you can just copy
> and paste from the website into your own
> codebase."
>
> That give other developers that PHP is just a
> big mess of functions etc. I'm all for
> "rolling your own" and doing things your own
> way, but in the long run, thats only going to
> get you so far. Someone mentioned that having
> someone else come on board and being able to
> hit the ground running is an asset and i tend
> to agree.

I agree that having someone get quickly up to speed is an asset, but, for example, if they've not used any particular framework then it really doesn't matter what you use. Granted that they're more likely to have used a public one if at all but this shouldn't (I think) be the sole factor in your decision.

> How can we compete with the Java's of the world
> if we're all doing something different and in
> most cases, not even similar. In the Java
> world most are using Struts or Faces. I don't
> know of many people who write/have written
> their own framework in-house, mainly due to
> time constraints and standards/best practices.

How can we compete with Java? I really don't care about Java, or competing with Java.

> If speed of development is all you're worried
> about...why not use Rails, (not that I'm a big
> fan, but you do get going fast AND its REAL OO
> from the ground up).

Well getting/hiring good PHP developers is (I bet) easier than getting good Rails developers. Simply because it's far more popular.

> MVC as a pattern wasn't
> designed around the web problem, and doesn't
> (to my mind) solve it very effectively.

Well I'm not an advocate of being forced into a particular way of doing things, but the script/database/template way has worked well for me for some time now, and if that happens to correlate to the MVC pattern, then so be it.

> With a PHP web app, the
> application is ideally as stateless as
> possible

I don't think so. And I'm sure that's why sessions were so desired, and why they were emulated in PHP3. Could you realistically handle a login (for example) without some sort of persistent state?

> So MVC doesn't seem great for web apps
> from that perspective.

Well assuming the script/database/template method I use is aactually MVC, I would have to disagree. This system has worked well for me for some tims now.

@Richard

> Well getting/hiring good PHP developers is (I
> bet) easier than getting good Rails developers.
> Simply because it's far more popular.

Hiring developers is not the point. PHP may be more popular, but the only people I know that see PHP, or even hear it suggested as a solution for anything, are other PHP developers.

Java pays my bills (sadly...and I'm working PHP into my current assignment, but its slow going). Therefore I attend the Java conferences etc and those people do Rails presentations all the time...at a Java conference. So I asked the head honcho at No Fluff Just Stuff why they'll do Rails stuff at a Java conference, (this was before JRuby caught on), and I got looked at with a smirk, (we'll call it a very nearly a laugh) and he said to me...we just haven't done it.

This tells me that people outside the PHP world still think we're all a bunch of cowboys, doing things without really thinking about design etc. And here we are, talking about re-inventing the MVC wheel...

PHP isn't going anywhere, you and I both know that, but I feel a wider adoption of common frameworks can only help us along...

> This tells me that people outside the PHP world
> still think we're all a bunch of cowboys, doing
> things without really thinking about design
> etc. And here we are, talking about
> re-inventing the MVC wheel...
>
> PHP isn't going anywhere, you and I both know
> that, but I feel a wider adoption of common
> frameworks can only help us along...

Yup, agree 100%. This blog post is an illustration of why I find it so hard to recruit skilled senior-level PHP developers who actually understand and apply concepts like object-oriented design. The PHP community tends to run to the trenches plugging their ears and screaming "over-engineering!" when anyone starts talking about design patterns. Well, there are people in the "real world" that are actually working on the type & scale of PHP applications that *require* thinking and talking about application design, request processing pipelines, request & response format abstraction, etc. And there are those of us who happen to use PHP and actually *enjoy* talking and thinking about these things.

This pervasive attitude of "if I have have never needed feature X how could anyone else?" coming from syndicated, senior members of the PHP community really does a disservice to those of us who are serious about pushing PHP to become a language that accommodates developers who *do* actually care about software design.

> > Well getting/hiring good PHP developers is
> (I
> > bet) easier than getting good Rails
> developers.
> > Simply because it's far more popular.
>
> Hiring developers is not the point.

It's very much the point if you're an IT manager. Selecting a niche technology which you can't get the staff for is a rather bad business decision.

> PHP may be
> more popular, but the only people I know that
> see PHP, or even hear it suggested as a
> solution for anything, are other PHP
> developers.

Well yes. Developers will naturally tout the advantages of their preffered language. So what if it's seen by the rest of the community as a "poor mans choice", it provides results.

> This tells me that people outside the PHP world
> still think we're all a bunch of cowboys

If they're other programmers who don't hold the purse strings, I don't really care. :-)

> And here we are, talking about
> re-inventing the MVC wheel...

Really? I'm not talking about re-inventing anything.

> PHP isn't going anywhere, you and I both know
> that

You're talking rubbish. PHP is well fortified in the web development world, and even if it was to disppear tomorrow, PHP work wouldn't dry up for a number of years.

> > Hiring developers is not the point.
>
> It's very much the point if you're an IT
> manager. Selecting a niche technology which you
> can't get the staff for is a rather bad business
> decision.

It shouldn't be the point, though. Not of a discussion on design patterns. And I would argue, as someone that does recruit developers, that the market (at least on the East Coast) is really pretty dismal if you actually want application design skill. And I do.

> > This tells me that people outside the PHP
> world
> > still think we're all a bunch of cowboys
>
> If they're other programmers who don't hold the
> purse strings, I don't really care. :-)

But I do. (And I think you should!) I care because I actually find it hard to hire PHP developers who do more than hack together code. And that, I would argue, is because PHP is seen by the rest of the world as indeed a bunch of highschool kids coding websites.

> > And here we are, talking about
> > re-inventing the MVC wheel...
>
> Really? I'm not talking about re-inventing
> anything.

Your blog post would suggest otherwise. It sounds a lot like you're saying "why would someone need to use a framework when they can create it themselves?"

That sounds exactly like the words every framework pioneer utters before they set out to reinvent the wheel. (I don't think reinvention is all bad, though.)

> > PHP isn't going anywhere, you and I both
> know
> > that
>
> You're talking rubbish. PHP is well fortified
> in the web development world, and even if it
> was to disppear tomorrow, PHP work wouldn't dry
> up for a number of years.
>

It sounds like you're both agreeing here! :) As for whether more framework usage would would help the language along, I don't see how you can really disagree there. Look where Rails got Ruby. I think ZF, eZ Components (arguably both are probably more component toolkits than frameworks) are great standard bearers for frameworks in PHP. And the various Mojavi clones like Symfonay or Agavi really do make for very fast application development. And we like fast -- especially when it's goes along with maintainable, extensible code.

> Yup, agree 100%. This blog post is an
> illustration of why I find it so hard to
> recruit skilled senior-level PHP developers who
> actually understand and apply concepts like
> object-oriented design.

Well thank you, and there's a balance to be struck between architecture and practicality. PHP developers, I think, edge towards practicality. I'd have to say from a business perspective that the latter is probably more desirable, albeit without creating an unmaintainable pile of crap.

> And there are those of us who
> happen to use PHP and actually *enjoy* talking
> and thinking about these things.

I'd say you need to get out more... :-)

> > Yup, agree 100%. This blog post is an
> > illustration of why I find it so hard to
> > recruit skilled senior-level PHP developers
> who
> > actually understand and apply concepts like
> > object-oriented design.
>
> Well thank you, and there's a balance to be
> struck between architecture and practicality.
> PHP developers, I think, edge towards
> practicality. I'd have to say from a business
> perspective that the latter is probably more
> desirable, albeit without creating an
> unmaintainable pile of crap.

No problem ;) Of course there's a balance. And I disagree with you completely over which one is a better investment from a business perspective. But that depends highly on the types of products you build (and how you need to test them, maintain them, upgrade them, etc.). I will readily admit that for a different development environment, a more practical & less engineed approach may be prudent. I wouldn't want to work for that company, though.

> > And there are those of us who
> > happen to use PHP and actually *enjoy*
> talking
> > and thinking about these things.
>
> I'd say you need to get out more... :-)

Fair enough :)

> PHP is seen
> by the rest of the world as indeed a bunch of
> highschool kids coding websites.

Perhaps once (in the time of PHP3), but I don't think it is anymore.

Richard,

You've got blinders on man, if you think PHP gets any respect from people in the Ruby/Java/.Net world.

I challenge you to go to any one of those groups of people and even mention it. You'll get a funny look that so evidently reads: "Get out of here you hack."

This mainly because those types of folks STILL think PHP is stuck in the PHP 3 world and we're not. Well MOST of use aren't.

You've hit the nail on the head though...practicality is a good thing, as long as you don't sacrifice maintainable code. All I'm saying is that as PHP advocates, adopting some more "common" frameworks can only HELP how we are viewed in the development world. Ask any non PHP developer why they think PHP is even popular and the _only_ thing you'll hear back is that its cheap to use because it comes with the majority of cheap hosting solutions and that any "script kiddie" can copy & paste script code...

Many PHP devs are still using plain old scripts to do things, which certainly has its place, but I think we need to start showing the rest of the world that OOPHP and MVC-PHP architecture is certainly viable on sites other than personal blogs and mom & pop shops.

lifewithryan:
> You've got blinders on man, if you think PHP
> gets any respect from people in the
> Ruby/Java/.Net world.

To be honest, I'm not that bothered. Those worlds are far enough away from me for me not to care. PHP is extremely quick to market without necessarily forcing you into writing poor code. You can, but that's down to the individual developer I think.

> I challenge you to go to any one of those
> groups of people and even mention it. You'll
> get a funny look that so evidently reads: "Get
> out of here you hack."

Mmmm. People with personality problems? :-) I've worked mainly in small businesses where speed to market is extremely important (crucial in one case), so scientific value takes a backseat to "practicality".

> This mainly because those types of folks STILL
> think PHP is stuck in the PHP 3 world and we're
> not. Well MOST of use aren't.

Granted, though I've seen some pretty awful "code" over the years.

> You've hit the nail on the head
> though...practicality is a good thing, as long
> as you don't sacrifice maintainable code. All
> I'm saying is that as PHP advocates, adopting
> some more "common" frameworks can only HELP how
> we are viewed in the development world. Ask any
> non PHP developer why they think PHP is even
> popular and the _only_ thing you'll hear back
> is that its cheap to use because it comes with
> the majority of cheap hosting solutions and
> that any "script kiddie" can copy & paste
> script code...

Sure, though I think "speed to get something up and running" will also be very near the top.

> Many PHP devs are still using plain old scripts
> to do things, which certainly has its place, but
> I think we need to start showing the rest of the
> world that OOPHP and MVC-PHP architecture is
> certainly viable on sites other than personal
> blogs and mom & pop shops.

Not quite sure what you're advocating, but PHP can be used to create large well structured applications, which edge towards science rather than practicality. Sure the majority of poeple using PHP are using it for smaller sites, but that by-no-means everyone is. Take Yahoo for example.

>Not quite sure what you're advocating, but PHP can >be used to create large well structured >applications, which edge towards science rather >than practicality. Sure the majority of poeple >using PHP are using it for smaller sites, but that >by-no-means everyone is. Take Yahoo for example.

I think you and I are in total agreement here...but its the perception that I'm referring to. You and I both know that PHP is more than sufficient for larger apps, etc. The problem is, once you step outside of our PHP world and look back in with Java glasses, etc...you'll see that the only people that realize what PHP is capable of, are those using it. In a way that is fine with me, but you get tired of having others look down on you for even suggestion PHP can hold its own against the Java's of the world. Hell I prefer PHP hands-down over anything else I've used and Code Igniter has helped me convert several other developers over to PHP from other languages. They were shocked to see that PHP had "MVC" frameworks, let alone doing anything OO.
Anyway, sounds like we both agree that PHP is very capable...where we're not agreeing is so much is on the usefulness/necessity of common frameworks instead of the roll-your-own philosophy. Unless there is absolutely something you need to do that can't be done with a given framework, I see the DIY framework approach as just an excercise in academia...or "to see if you can do it"

"Been reading this page: http://en.wikipedia.org/wiki/Model-view-controller and it seems the techniques that I employ are somewhat similar, well, according to other people at least. And they are (as I understand it): Model - the database, View - the template, Controller - the PHP script. Not exactly rocket science when you come to think about it. "
Actually, you misunderstand it. If you don't get or need the concepts of the Domain and the Presentation then you probably don't need MVC and couldn't implement it if you did. MVC is a deceptively simple pattern, but the effects of these two simple separations inform a multitude of implementation decisions.

"And why you would feel the need to create a whole framework around this concept is somewhat beyond me"
I get the sense that you would question why anyone would create a framework around any concept. ;) Yet here are all of these MVC frameworks being built in every language. What are the profound ideas that so many smart people have discovered in this pattern that you don't seem to be able to comprehend?

"to me it seems like the logical way to do things. Doesn't it to you?"
MVC is actually not "logical" in the sense you are using the word to mean "obvious." In fact it is quite counter-intuitive and unlike most patterns strangely broad in its meaning. That makes it difficult to pin down to a exact set of dependencies and separations.

"Note (4th March 2008) I just found Rasmus Lerdorfs' blog and his recent post about MVC. I didn't crib from it I promise - it's just a strange coincidence. Also well worth a read though."
That "recent post" is over two years old. It is also a very pro-MVC post from someone with sophisticated knowledge of complex implementations.