On Frameworks, RoR & PHP

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
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Even though GoF described mostly low-level patterns in their book, I think they summed up the idea of frameworks very nicely: while a library makes implementation decisions for you, a framework makes design decisions for you. An extensible framework makes design decisions but lets you change them; i.e. doesn't get in your way. That's extremely difficult to do, because everyone's idea of design is different.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Ambush Commander wrote:Even though GoF described mostly low-level patterns in their book, I think they summed up the idea of frameworks very nicely:
While they do discuss applications, the patterns they presented are all fairly low level OO constructs. The PoEAA was 8 years later and itemized to higher level patterns most commonly used.
Ambush Commander wrote:while a library makes implementation decisions for you, a framework makes design decisions for you. An extensible framework makes design decisions but lets you change them; i.e. doesn't get in your way. That's extremely difficult to do, because everyone's idea of design is different.
I would prefer flex points to decisions. But I think getting everything to work together is a long process and people just get frustrated and take short cuts.
(#10850)
User avatar
BDKR
DevNet Resident
Posts: 1207
Joined: Sat Jun 08, 2002 1:24 pm
Location: Florida
Contact:

Post by BDKR »

arborint wrote: ...the post-ZF/RoR/Cake/Symfony/CI world of PHP....
Its interesting that you feel that. I'm not convinced we are there yet. Perhaps we are just barely seeing the dawning of such, but not there yet. There are far too many people that haven't yet begun to feel the poison of or regurgitate the koolaid yet. The reason for this is because knowledge of the surrounding issues isn't as widespread. The article by Terry Chay that Patrick linked to is a good one forecasts the same issues that large scale Cake, Symfony, and Code Igniter (based on how you use it) implementations would face. What Alex Payne from Twitter said sums it up well.
Running on Rails has forced us to deal with scaling issues - issues that any growing site eventually contends with - far sooner

( Emphasis mine )

So perhaps the dogma that Developer Cycles are more important the Processor Cycles has an upper limit of feasability/acceptability?

But, Your reasoning for saying this seems far different from mine, but no less correct and important. In addition to what you and Patrick have said (concerning inflexibility), I've heared numerous rumblings from the same thing in the RonR camp as well (as you can see, I'm not localizing it to merely a PHP thing).

The above said, perhaps we should fork this thread off into another one and focus on the two topics above?
ev0l
Forum Commoner
Posts: 56
Joined: Thu Jun 21, 2007 1:50 pm

Post by ev0l »

BDKR wrote:
As for the scalability of RonR, I'll say that it's pretty capable given some dead serious machinery to run it on. I did a short stint at PayPerPost.com and RonR performed very well under load. But even still, it's performance ceiling is going to be far lower then anything that's not
using an object relational mapper or persistence layer.
RonR's slowness is not largely due to the ORM but to the ruby runtime. Ruby's implementation could be much faster.
BDKR wrote: One of these days someone will get smart and write an OODB that can work with Ruby, PHP, Perl, and Python via a common object exchange interface.
That has been done. http://www.garret.ru/~knizhnik/dybase.html The hardest part if getting people to use an OODB.
User avatar
BDKR
DevNet Resident
Posts: 1207
Joined: Sat Jun 08, 2002 1:24 pm
Location: Florida
Contact:

Post by BDKR »

ev0l wrote:
BDKR wrote: As for the scalability of RonR, I'll say that it's pretty capable given some dead serious machinery to run it on. I did a short stint at PayPerPost.com and RonR performed very well under load. But even still, it's performance ceiling is going to be far lower then anything that's not
using an object relational mapper or persistence layer.
RonR's slowness is not largely due to the ORM but to the ruby runtime. Ruby's implementation could be much faster.
Using an ORM (the whole impedance mis-match thing) is orders of magnitude slower then not. Ruby by itself may be slow, but I tend to believe that it's 'fast enough'.
ev0l wrote:
BDKR wrote: One of these days someone will get smart and write an OODB that can work with Ruby, PHP, Perl, and Python via a common object exchange interface.
That has been done. http://www.garret.ru/~knizhnik/dybase.html The hardest part if getting people to use an OODB.
Now that's cool. I'm going to take a look at that fer shizzle.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

BDKR wrote:Its interesting that you feel that. I'm not convinced we are there yet. Perhaps we are just barely seeing the dawning of such, but not there yet. There are far too many people that haven't yet begun to feel the poison of or regurgitate the koolaid yet. The reason for this is because knowledge of the surrounding issues isn't as widespread.
I think we are in a very different place in PHP design than a year or two ago. I attribute it to a number of things. Certainly the work done back then on things like WACT and Mojavi (which became Symfony) had an effect on introducing controller architectures to the PHP community. The slow uptake of PHP5 and the excitement of Rails caused a stir in the PHP community that lead to Cake and ZF.

I also think there has been and is a general movement in web development evinced by the creation of things like Rails and Groovy, and the continuing popularity of PHP. I am not sure exactly how to describe this movement in software design because it is an amalgam of things like Extreme Programming and the Open Source movement and the general explosion of the number of people around the world doing programming. But it is in part that many of the things that "computer scientists" used to consider bad or beneath them have been embraced as the best way to actually do things. It is as if worse is better. How can an admittedly crappy programming language like PHP -- that software development's best and brightest look down their nose at -- be so darn useful and popular.

The interesting difference for me between a year or two ago and today is that all the current frameworks are MVC-style Controller Architectures. That is a huge leap. And the current crop are a pretty incestuous bunch. I don't think there is much dissent about whether this is the right direction to go for serious development in PHP. Nor is there anywhere near the level of explaining the patterns associated with Controller Architectures, or arguing Procedural vs OOP. That's why I think it might be interesting to have a discussion about how the third generations of PHP frameworks might be designed.
BDKR wrote:The article by Terry Chay that Patrick linked to is a good one forecasts the same issues that large scale Cake, Symfony, and Code Igniter (based on how you use it) implementations would face.
...
So perhaps the dogma that Developer Cycles are more important the Processor Cycles has an upper limit of feasability/acceptability?
I don't really have anything bad to say about Ruby or Rails and would like to focus on the current state of frameworks in PHP.

On the subject of Developer Cycles vs Processor Cycles I think it is important to be clear that the axiom is that Developer Cycles are more more expensive than Processor Cycles. That means that a million Processor Cycles cost the same as, say, a thousand Developer Cycles. But it does not mean that when you grow to a billion Processor Cycles that you can still get away with a thousand Developer Cycles.
(#10850)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Here is a semi-interest squabble between Ruby and Python that may be of interest to this discussion. The question of TIMTOWDI vs Constraints is an important one to PHP framework developers where I think we want to have a little of both. I think we may have a purer understanding of the issue because PHP provides neither some of the advanced constructs or constraints of either of those languages -- forcing us to (perhaps) a more honest middle way.

http://www.baus.net/rails-wrong-language
(#10850)
ev0l
Forum Commoner
Posts: 56
Joined: Thu Jun 21, 2007 1:50 pm

Post by ev0l »

arborint wrote: That's why I think it might be interesting to have a discussion about how the third generations of PHP frameworks might be designed.
Like Seaside and Phaux .

I think the next generation of frameworks are going to have some fundamental similarities.
  • Statefulnes.
    Callbacks.
    Highly reusable component architecture.
    HTML being generated programatically with a heavy reliance on CSS
This is going to mean the death of...
  • Templates
    "Meaningful" URL's that have no meaning
    Traditional MVC
    Page based development (it will just be components embedding or calling other components using callbacks)
Stateful frameworks that have highly reusable component architectures will finally fulfill the full power of object oriented programming in the web development space.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

And as no surprise to you I think you have it wrong and your second list is biased. I think the way to prove who is right is to develop to very simplified frameworks that demonstrate it done both ways and let out studio audience decide. You will need to fill out the specs you have started and the we will need to specify a couple of use cases.

I would redo you second list as:

Generally Stateless
Dispatched
Defaults by convention but runtime changable because everything is lazy loaded
Highly reusable component architecture (no fair that only you get this ;))
HTML from designer editable templates
MVC with hierarchical V and C
Module and Layout based development

And if you prove me wrong I will consider it a win and happily change to your callback style -- and be the smarter and better developer for it. ;)
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

his is going to mean the death of...


Templates
"Meaningful" URL's that have no meaning
Traditional MVC
Page based development (it will just be components embedding or calling other components using callbacks)


Stateful frameworks that have highly reusable component architectures will finally fulfill the full power of object oriented programming in the web development space.
How are templates going the way of the dinosaur?

Clean URL's I would have agreed a while ago, but d11 made an intersting point a while back. He suggested that users feel more comfortable with clean URL's and are more likely to use it to navigate; thus the clean URL should be considered part of the interface.

So until browsers come standard with no address bar...his point is at least an valid argument as to why clean URL's should be chosen over not.

Traditional MVC doesn't apply to the web...it's why I was most confused in reading books or articles that disscussed MVC for PHP. IMHO most developers who write articles on MVC for PHP or web are simplying repeating verbatim what they have read about MVC in books for Java or C++.

I would be interested in reading your interpretation as to how MVC applies to PHP, either as your own article or an article you have read and agree with.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

While I don't think templates are going to leave us any time soon (they're very convenient and allow for quick prototyping), I do think we'd be better off if we jettisoned the idea. In its essence, written HTML is a serialized form of the DOM. Browsers have recognized this for the longest time: they don't try to regexp the document in a viewable form, they parse it into a DOM and work off of that. Developers/servers, not so much. Templates make a hack of the process by putting data straight into serialized form, and usually don't have a very good handle the actual language they're writing into (this can mean silly things like unclosed tags to dangerous things like XSS).

Generating HTML makes so much more sense, and PHP 5 give developers lots more tools to do this job. You've got XSLT, for sure, but you can also roll your own object-oriented HTML generation system. And one of the great things about that is that it forces you to put your data into some standardized form (for XSLT, it's another DOM) which means that you can easily convert it to other forms: small jumps between HTML and XHTML to large jumps from RSS to HTML. The templates that do a good job at this sort of thing are the ones moving towards the more automated generation of HTML (features that indicate this are lots of small templates, a unified API for accessing template variables, etc)

Clean URLs are a pain to type, but who types in URLs these days?
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

Hockey wrote:
his is going to mean the death of...


Templates
"Meaningful" URL's that have no meaning
Traditional MVC
Page based development (it will just be components embedding or calling other components using callbacks)


Stateful frameworks that have highly reusable component architectures will finally fulfill the full power of object oriented programming in the web development space.
How are templates going the way of the dinosaur?

Clean URL's I would have agreed a while ago, but d11 made an intersting point a while back. He suggested that users feel more comfortable with clean URL's and are more likely to use it to navigate; thus the clean URL should be considered part of the interface.

So until browsers come standard with no address bar...his point is at least an valid argument as to why clean URL's should be chosen over not.

Traditional MVC doesn't apply to the web...it's why I was most confused in reading books or articles that disscussed MVC for PHP. IMHO most developers who write articles on MVC for PHP or web are simplying repeating verbatim what they have read about MVC in books for Java or C++.

I would be interested in reading your interpretation as to how MVC applies to PHP, either as your own article or an article you have read and agree with.
You've missed the point RE: meaningful url's. What ev0l is pointing out, is that you do not need a meaning ful URL for every page. Example is these forums - posting.php. That's a meaningful URL, but has no meaning.

Templates are the age of the dinosaur. Until you stop using them it's very difficult to see this. They are a waste of developers time, when the developer could be using a markup generator that can easily switch between (X)HTML, XML, even plain text - where you would normally need a template for each.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

Jenk wrote:
Hockey wrote:
his is going to mean the death of...


Templates
"Meaningful" URL's that have no meaning
Traditional MVC
Page based development (it will just be components embedding or calling other components using callbacks)


Stateful frameworks that have highly reusable component architectures will finally fulfill the full power of object oriented programming in the web development space.
How are templates going the way of the dinosaur?

Clean URL's I would have agreed a while ago, but d11 made an intersting point a while back. He suggested that users feel more comfortable with clean URL's and are more likely to use it to navigate; thus the clean URL should be considered part of the interface.

So until browsers come standard with no address bar...his point is at least an valid argument as to why clean URL's should be chosen over not.

Traditional MVC doesn't apply to the web...it's why I was most confused in reading books or articles that disscussed MVC for PHP. IMHO most developers who write articles on MVC for PHP or web are simplying repeating verbatim what they have read about MVC in books for Java or C++.

I would be interested in reading your interpretation as to how MVC applies to PHP, either as your own article or an article you have read and agree with.
You've missed the point RE: meaningful url's. What ev0l is pointing out, is that you do not need a meaning ful URL for every page. Example is these forums - posting.php. That's a meaningful URL, but has no meaning.

Templates are the age of the dinosaur. Until you stop using them it's very difficult to see this. They are a waste of developers time, when the developer could be using a markup generator that can easily switch between (X)HTML, XML, even plain text - where you would normally need a template for each.
Although not impossible (perhaps we have different uses) it's not practical in my situation. Templates (as AC has said) are serialized versions of DOM. However, have you ever tried editing a DOM using a WYSIWYG? Mosy WYSIWYG expect a HTML string or file, not a DOM.

Unlike a DOM a static HTML file is portable and accessible by many applications. If you need to allow end users to change the layout of a web site, etc storing that in a HTML file is by far, the only way to go. As for templates being a waste of developers time. Developers ideally shouldn't ever touch HTML, so why are they wasting your time? Tools like Dreamweaver, etc output and work with HTML not a DOM, not directly anyways.

Using a template, it's easy to switch between XHTML, HTML or PDF for that matter. At least, I have devised a way to separate these dependencies in my own applications. :)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Jenk wrote:You've missed the point RE: meaningful url's. What ev0l is pointing out, is that you do not need a meaning ful URL for every page. Example is these forums - posting.php. That's a meaningful URL, but has no meaning.
The original argument was a straw man because I have never heard anyone say that you should have all meaningful URLs. It is as silly as me saying that ev0l is proposing than no URL has any human readable meaning at all.
Jenk wrote:Templates are the age of the dinosaur. Until you stop using them it's very difficult to see this. They are a waste of developers time, when the developer could be using a markup generator that can easily switch between (X)HTML, XML, even plain text - where you would normally need a template for each.
They don't take any of my time. A designer builds the layout templates and the site owners directly edits the content templates (WYSIWYG) -- I rarely touch any of them. Mostly I am involved in defining the initial CSS and they take it from there.
(#10850)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

Designers shouldn't be touching markup. Designers use CSS, plus images (Photoshop etc.)

Do your designers also create your XML feeds? (RSS, Atom, Sage, etc)
Post Reply