Topic: The great big friendly methodology debate

There has been the start of a very interesting discussion here regarding PHP, Ruby, and the advantages and disadvantages of a full OOP approach to developing websites versus the procedural technique favoured by many web developers. I think a lot of web developers have an approach similar to opus:

opus wrote:

... PHP works so well for me, and has always worked well for me.  I know exactly how to do everything that I want, and if I don't, I know exactly and where I need to turn and how I need to go about finding out ... It's pure pragmatism and convenience.

For many, pure-OOP methods are overkill, too complex, too far removed from the procedural nature of most websites, or outside the developers' realm of experience. Add to that the fact that the most popular scripting language on the web (PHP) has traditionally been a very procedural language (bit of HTML, bit of PHP, bit of HTML, bit of PHP etc) and you can see why there seems to be a vast chasm between web development and traditional application development. However, things are changing.

My own preference is for a mix-and-match approach, using the power of classes to encapsulate related properties and methods in a handy packet for use by procedural code in each web page. Each class I generally put in a single file which is then included on each page, or at least I include the classes I need for that page. It works OK for me, and means that useful classes (for a product, an uploaded user file etc) can be reused in other projects. (Sample code is available for this technique if you're really interested). Which means, just like Robert said:

Robert Evans wrote:

I could stop rewriting everything and just package things up in classes and create new objects whenever I needed them. I could abstract common actions into classes and implement them into my own library so that I could use them for future projects.

So, sorry Robert, I don't agree with this:

In my experience, procedural is fine, but you will end up with duplication in your code; you will rewrite pieces (or cut and paste) to use in future projects ... It doesn't bother me if people, like yourself, want to do procedural style coding with some OO mixed in here and there. If you want to do more work, that's fine by me.

Surely there's not much difference between this (C# asp.net):

using System;
using System.Text;

and this (PHP, obviously):

<?php
require_once("product.class.php");
require_once("userfile.class.php");
?>

Each page (remember we're talking in the context of web applications) needs to have access to a set of central code (classes, functions, whatever), and so the old procedural method of including that central code works fine. So, is there something I've missed? I have, compared to the great people here, next to no experience and definitely no qualifications on anything to do with development. So I've come up with my solutions using nothing but experimentation, and the help of the wonderful web community. Can the pure-OOP developers on this list (yes, you Ruby people) share any wisdom that could help me, and probably lots of others like me, write our apps better? This could be a really useful discussion if it helps people to do their jobs better and more easily.

Robert summed it up nicely:

Robert Evans wrote:

It honestly has nothing to do with any language being "bad" ... For some people OO just won't ever due. It doesn't click with their thinking style. With PHP, it is a good step into more of an introduction to OO, if the PHP programmer wants to use it. When it comes down to, whatever gets the job done well with quality is the way to go.

Absolutely, we're all here to do a good job. The technology - even the methodology, should be chosen to make sure the products we create are the very best they can be.

Re: The great big friendly methodology debate

Ok, how shall I start. One reason why many PHP programmers might find the Object Oriented approach to be difficult to grasp and understand its advantages, is because PHP's use of OO is rather cumbersome. It's not to say that it was built wrong, in the sense that it doesn't work, rather it can make a programmers life more difficult. Because of this, I believe, it keeps many people from pursuing OO and thinking that all OO programming languages are the same. Well, one would be wrong.

It starts with this key difference: most everything in PHP is a native variable type, while in Ruby everything is an object. There is a significant advantage in this difference alone. Everything in Ruby is an object, hence everything in Ruby has a method associated with it that can be called on the object. Another advantage is that if say the String class that comes with Ruby doesn't supply a method I need, I can reopen the String class in my own application, define a method and close the class. This is called a mixin, something you cannot do with PHP, you'd have to rely on inheritance instead.

Your example above, between C# and PHP, has several problems. 1) a comparison of C# and PHP, isn't really a good comparison, and 2) it's too simple of an example to actually study. In a comparison between a program written in PHP and Ruby, by advance programmers of each respective language, has shown that Ruby has far less lines of code. This is what I meant when I said, "if you want to do more work, that's fine by me."

There was day that everyone said that Java could never overtake C++ as the dominant language of choice. Yet, today, Java is. There will always be nay sayers, people who don't want to change for whatever reason: too hard, don't want to learn, feel their livelyhood threatened, like pain.

There is a flip side of this, that goes back to my point of picking the right language for the job. If I was going to write a very small, script to be integrated into a PHP site, I wouldn't write it in Ruby, but rather PHP. If I was going to write a new application for the web, I'd write it in Ruby because it is more efficient for me to do so and it can be for anyone who gives themselves a chance to learn the language.

In all honesty, Javascript is a better written language than PHP, but it isn't a server-side language like PHP is. If you have never programmed before what is easier to read:

for($i = 0; $i <= 10; $i++) {
    echo $i;
}

or

1.upto 10 do |x|
  puts x
end

Obviously, one who has never seen code before could understand that 1.upto 10 does something like counting 1 to 10. That would be another point that Ruby was designed, and this is how the creator Matz puts it, "for humans first, machines second". He tried to make Ruby code resemble english as much as possible.

I have seen a lot of people say they are happy where they are with PHP. That makes me think that they haven't done any large scaled applications to see how PHP can cause one spend more time focusing on the language and less time focusing on the actual application. Ruby was designed to get out of you way so you can focus on the application. Also, Ruby is fairly young, in the respects of being a well known language. Even though it dates back to when Java was released, it has primarily existed within Japan and had not ventured westward. It also hasn't had a large scaled company pumping millions of dollars into it to get it accepted and known.

The current push you are seeing with Ruby and Rails is purely on the backs of developers who are now enjoying what they are doing. There is no company pumping millions of dollars into making Ruby mainstream, like Sun did with Java. There is reason why so many developers are happy when coding in Ruby and why Ruby is fastly becoming adopted by many people and companies alike.

Re: The great big friendly methodology debate

I would like to add, in addition to Ruby being a hit to many developers, there are now ports to Ruby.cl, Ruby.NET, JRuby, and a few others.  Ruby is becoming huge, and there is a reason behind that.

As for the require_once example... this doesn't show OO at all.  That is just a file include, Ruby has that too: include "something".  I think OOP is just a hugely misunderstood topic in the web development space, largely because it is a somewhat advanced topic (not saying if you don't understand it you aren't smart).  Because it is such an advanced and mind twisting change, its tough.  PHP's main target has always been average Joe teaching himself to program (nothing wrong with that).  To top it off as Robert said, PHP's OO support is fair at best.  I think that bundled with PHP's core audience pushes the majority of the community away from it.  I hate OO in PHP, yet love it in Ruby where it feels right.

As for the comment, "if it works for me then why bother"?  Thats a ridiculous statement from a seasoned web developer.  That is not a reason to not learn and use something else.  Thats like saying Assembler (a bit of a stretch I know) will do fine, because it works for me.... it might work, but if your competition is cranking the same thing out in half the time.. its no longer working.

OOP is a tough concept to grasp.  If it wasn't for some schooling (in Java), I don't think I would have taken to it so greatly.  I think it is a concept every programmer should grasp (maybe not ALWAYS use, but have available).  There is a reason the desktop software development world has switched to OOP, and we as web developers have as much, if not more to gain from its advantages.

Last edited by RayCMorgan (2006-10-07 18:52:28)

In the beginning God created the heavens and the earth. [Gen. 1:1]

Re: The great big friendly methodology debate

Thanks for your comments, Robert and Ray. I can see two things: firstly I haven't explained what I'd like to learn very well at all, and secondly that you are (like all Ruby programmers I've talked with so far) in love with the language. I'm not disagreeing that Ruby is a great language, what I've seen of it is very impressive, and that you can do more with less code. What I am questioning is whether a complete OOP approach is actually the right thing for web development. After all, we deal in pages that are - by the very nature of HTTP - transitory and stateless. Does a pure OOP model actually make sense for this kind of application?

My simple example with the include scripts above tried to explain that whether you use an OOP model or a procedural model when building web applications, you still meet the problem of having to include central code repositories - whether they are classes or just sets of functions - in your pages. Therefore in my experience a lot of time, effort and lines of code can be saved by clever encapsulation of methods and properties - regardless of your methodology.

I've got quite a lot of experience writing Javascript, in which everything is an object (like Ruby). Therefore I understand the extending classes thing pretty well - and the Prototype library (my favourite so far) does this to great effect. However I realise that Javascript is limited to one page, it being a client-side technology. In that regard it is akin to traditional application development which is all self-contained and never meets the problems of state or reloading entire apps (which is basically what happens when someone requests a new page in a web application).

Do you see what I mean? It's quite a slippery question to ask, and I know what your answer will be smile but still I'd like to find out HOW (not why) Ruby does what it does on a page-by-page basis. Code examples may well be necessary.

Thanks for your help in this, guys.

Re: The great big friendly methodology debate

Personally I believe the web is more object oriented then procedural.  Though be fore I explain, I think this revolves around web based applications vs more of a standard "web page" type site.  I am more of a developer of web applications, and in this you will see that lean.  Though I find OOP much in line with web applications, I can see the procedural approach for a none web app web site.  Though, even in that, personally I would prefer developing in a OO language just because after working with OO for awhile, you just start thinking in it :-P.

Alrighty, now on with my example of why I think OO suits the web better.

Firstly I think of a web app (or web site) as just an interface for data.  Thats it.  There is data over there (in a DB, filesystem, etc) and the user over here wants to view and manipulate it.  This is reason #1 for me thinking OO is for the web.  I think data is best represented as an object, not as functions manipulating unstructured data.

Take Rails for example.  Everything in the database has what is known as a Model class.  A object representing the table of data in the database.  I think it looks better, easier to understand, and WAY easier to maintain like this.

Say you have a persons table in the database.  With a name, phone, password.  I actually don't know of a good way to use none OO to structure this.(note all code is going to be in Ruby due to my familiarity with it over PHP, you should be able to get the point though)

class Person
  attr_accesor :name, :email, :password #making 3 variables, all publicly accessible outside of the class.
end

person = Person.new(#.. Draw from database...#)
person.name #name
person.email #email
...

This seems like the best way to model data.  For both online and off.  Rails takes this a whole level farther.  Quick example given the same 'persons' table.

#in /app/models/person.rb
class Person < ActiveRecord::Base
end

#in /app/controllers/persons_controller.rb
class PersonsController < ApplicationController
  def index
    @person = Person.find(:all) #set the variable to an array of all persons from persons table in DB
  end
end

#in /app/views/persons/index.rhtml
<html>
<head></head>
<body>
  <% @person.each do |person| #loop through each person in @persons setting the current value to person %>
    <p><% person.name %>, <% person.password %>, <% person.email %></p>
  <% end #end loop %>
</body>
</html>

So other then getting a little carried away.. I hope you noticed a few things the OO brings to the world of the web in that last example.  Right of the bat the biggest thing is separation.  On that, most of the separation rules can be defined in a higher class, leaving the lower 'descendants' of that class free from worrying about it.  Another good part of separation is the fact it forces separation of Model (data) and Controller (requests), leading to correctly designed applications for easy maintenance and readability.  I think that the mindset of we are serving single pages, is a wrong mindset, at least with web apps.  I think there are many things that can be abstracted outside the scope of a 'page'.  Main the data, but what goes in and out I think can also be structured (the controllers in Rails).  The thing that isn't really like OO, would be the templates, obviously.  This is because they are just the UI to interact with the Data, nothing else.

So yes, OOP makes great sense for the web.  I actually think it will help someone get over the web as a bunch of pages, mindset.  I heard of that for the longest time.. "stop thinking of the web as pages".  The problem was, thats all they said.  They never told me what to start thinking of it as.  Here is what I have come to learn.  Think of the web as Data, and the clients UI interacts with it.  So its not in a page model, but a request model.

Closing thoughts (you can tell I want to become a Pastor, I have like 4 closing segments :-P), what do I consider a "Web application"?  I think the line is draw right down the middle of blogging software.  Some custom blogging solutions are so simple that they don't need to follow the Data/Request model and it doesn't hurt them.  Others (wordpress, Mephisto, etc) I would consider a Web App, due to the complexity (multiuser, multisite, categories/tags, assets, etc.).  MySpace, Facebook, Flickr, Basecamp, CrossConnector (little plug for Ryan!), and the lot, I consider web apps.

Now like a good pastor I pray for 10 minutes shoving every last thought I forgot to mention to you in my sermon and the recap the lesson.....!

In the beginning God created the heavens and the earth. [Gen. 1:1]

Re: The great big friendly methodology debate

Thanks Ray, that's really useful. I suppose as that was your "sermon" I should say a hearty "Amen, preach it!" wink

The good news is that I'm doing pretty much what you described. Sample code from the e-comerce system I'm working on today below:

// general system settings, URLs, password etc
require_once "system.class.php";

// the database connection details, and methods to get/set data
require_once "db.class.php"; 

// loads the correct template, and sets methods to do various standard things - set
// the title, enable/disable the Javascript framework etc
require_once "page.class.php";

// methods and properties for the current user - save details, reset password etc 
require_once "user.class.php"; 

// the users shopping basket, add item, remove item etc
require_once "basket.class.php"; 

// general functions: THIS ISN'T OOP, just plain vanilla functions to validate email
// addresses, querystring parameters etc. See notes below
require_once "functions.php"; 

// create the new system
$system = new System;

// create the database connection
$conn = new DB;

// create the users basket
$basket = new Basket;

// create the page
$page = new Page;

// set the page body
$page->body = "<h1>Welcome</h1><p>Welcome to my lovely shop.</p>";

// show the basket
$page->body .= "<h2>You have ".$basket->numItems." items in your basket.</h2>";

// get the list of categories
$conn->sql = "select category from categories;";
$conn->open();

// loop the rows
while ($row = $conn->getRow($conn->recordset)){
$page->body .= "<p>".$row["category"]."</p>";
}

// finally, draw the completed page
$page->draw();

Obviously I've missed out a load of error checking and shortened the SQL and loop bit to make it readable. But you get the drift. So, is this OOP? I would guess so, but I'm still not sure if I'm capturing everything I could in classes.

For example, in my functions.php file I have a load of standard functions that validate email addresses, validate querystring parameters, things like that. Now I suppose I could wrap them up in a class, but the problem I have is making every class aware of and able to use every other classes methods and properties. That's a problem with PHPs inheritance, and I've not yet found a satisfactory solution (although setting every property to be a global static seems to work, similar to your :variable code above).

You'll have noticed al my classes have their own PHP file. I find that makes it easier to keep track of things, include what I need and not other stuff (and therefore save compiling cycles), and version the classes if I want. That means sharing methods and properties is a bit tricky. Would it be better to wrap everything up in a superclass, so it the entire system is just one class (a la .net)? How does Ruby handle that? Any PHP gurus out there? What do you do?

The biggest problem, and this is something that amazingly Microsoft have tackled pretty well, is making the entire page an object. In the Ruby code above you hard-coded your HTML, interspersed with Ruby. That's exactly what I've been doing for years, just not with classes. So I've tried to go one step further by incorporating a home-grown templating system in my apps that gives me access to methods like setTitle(), setJavascriptInclude() and properties like bodyID and bodyClass. Obviously I could take the page's methods and properties to the nth degree, but in general I leave little HTML to the processing page as possible - everything I can is put in the template file.

So, can you see any big shortcomings in this method? Would you class this as OOP, or a wierd hybrid?

Oh, and thanks for the great discussion smile

Re: The great big friendly methodology debate

Here are a few benefits of OOP:

# Analysis and Design Made Easier
# Code Reuse
# Ease of Maintenance and Enhancement
# Iterations Fewer and Shorter

I like to think of OOP in a similar way that I think about Content, Style, and Behaviour. Sure, I can mix my XHTML and CSS in file. I can even add my Javascript right into my XHTML/CSS soup. One of the many problems with this, is that the maintainability of my code has become more difficult. I have made my job harder by just throwing everything together and not thinking about the design of my code.

OOP is really about the design of your code and the maintainability of your code for future reuse. It can also make your code easier to read, and in many cases it can increase performance. Abstraction and encapsulation of code benefits you just as much as having separate XHTML, CSS, and Javascript files can, when it comes to making changes, additions or refractoring of your code.

One problem with your approach to the web is seeing it as only pages. This is a 1990's way of thinking, and I mean no offense, but things are rapidly changing right now in how we use the internet. More applications are being deployed on the internet than on the desktop, and this isn't going to change, but rather continue with an increasing effort. It is all about portability.

I've heard reports that Microsoft is looking to move its Office software from the desktop to the web, via a monthly subscription service. We have online banking systems, accounting systems, contact managers, content systems, etc. Our data, is rapidly becoming more portable. So, the idea that the web is like pages, is really a thing of the past. The day of designing applications that are like desktop applications is here to stay and OOP is the obvious method of developing these applications for scalability and performance.

If you are developing web sites, with static pages, then procedural will do just fine. If you are developing applications, OOP is really the way to go.

Re: The great big friendly methodology debate

Thanks Robert, good explanation of Page vs Data thinking.

Chris, I would probably classify that as a hybrid.  I am defiantly glad you were able to OO your Data models, that is the big one.  The problem comes in with the functions.php (obviously).  The problem with something like this is there is little structure and it will have scoping issues, so you start getting lots and lots of functions.  That method isn't horrible, many good systems work that way (wordpress to be one).  I think its just you have to be wary of what you are putting in there.

Take for example the email validation (or any validation functions).  Should this function really just be floating around?  Wouldn't it make sense if that belonged to the User class?  So you could do something like user.valid, which would check for any errors and if none return true.  Here are two examples, good and bad. (this is going to be in wanna be PHP, so if there are little PHP errors, my bad)

//create new user and populate
$user = User.new();
$user.name = "Tom";
$user.email = "tom@gmail.com";

if ($user.valid) //checks to see if email is valid and a name is present
  $user.save; //saves user to database

And the bad

$user = User.new();
$user.name = "Tom";
$user.email = "tom@gmail.com";

if (valid_email($user.email) && not_blank($user.name)) //notice this line
  $user.save;

You see on the bad side, the validation is taken outside of the scope of the User model, which is something only the model should deal with.  All things Data (input/output, validation, preset values, etc) need to be contained in a Model class.  This makes life better.  Easier to maintain, extend, control, use, and make APIs with.

Now the trouble turns to PHP sucky OO model.  PHP doesn't have mixins like Ruby, which makes life a tad harder.  You are really going ot have to think of your domain model.  I think a decent way would to use classes to 'scope' the different kind of functions at least, instead of a bunch of random functions laying around. Example:

class Validation {
  function email($email) {
    //...validate email
  }

  function blank($string) {
    //return false if $string is not blank or nil, else true
  }
}

//model..
class User {
  //....
  function valid() {
    if (Validation::email($self->email) && !Validation::blank($self->name))
      return true
    return false
  }
}

So by separating the functions.php into multiple scoped class level methods, you create a layer of maintainability.  I would spilt these each into separate files also, this will allow your brain to just thing "ok this need a validation... validation.class.php... go".

Hope this helps.

In the beginning God created the heavens and the earth. [Gen. 1:1]

Re: The great big friendly methodology debate

Great thread here. I am left wondering if there are some things you guys feel PHP does better than Ruby, or instances where you would deem it more appropriate.

Re: The great big friendly methodology debate

I would use PHP for very basic dynamic sites.  Including headers/footers, at max very simple DB queries.  Personally I don't really like the feel of PHP, and try to stay away from it, I got enough of it awhile back.  If I could easily do those things in Ruby, then I would never use PHP.  The trouble is there is very little in the works to make very simplistic sites.  Though there are a couple, which I will have to look into.  Another thing is when a client refuses to budge from PHP, or from a server that doesn't offer Ruby.  Thats about it.  In my little world, I wish I could work solely in Ruby, it is just that awesome.

In the beginning God created the heavens and the earth. [Gen. 1:1]

Re: The great big friendly methodology debate

Yes, great thread.

Firstly in response to Ace of Dubs: I would largely concur with Ray. PHP is great for sites that require basic dynamic scripting as it is very easy to get into. You can do much more complex stuff - Ray and I have both posted some pretty advanced examples of what you can do in PHP - but it is harder to do than, for example, Ruby. The other thing PHP really kicks donkey in is it's awesome range of built-in functions. You need to do something to a string or an integer? Chances are PHP has the exact thing you need as part of its core library.

OK, back to the discussion. Ray, thanks for the encouragement. I got halfway through your post and thought "But I need these methods to be available to more than just the User class!" and then you gave the answer smile The validation class idea (or even just a general string manipulation class) is something I've used on a couple of projects and it works well. I've met up with PHPs limitations with regard to inheritance (why oh why can't I have a list of inherits values like .Net? Does Ruby do that?) when doing that, and I'm not sure what the performance overhead is when using potentialy hundreds of static properties and methods without ever initiating an instance of a class. That's a bit of a wooly question, though, so I doubt I'll get an answer.

Robert, I'm afraid I don't quite agree with this:

Robert Evans wrote:

One problem with your approach to the web is seeing it as only pages. This is a 1990's way of thinking, and I mean no offense, but things are rapidly changing right now in how we use the internet. More applications are being deployed on the internet than on the desktop, and this isn't going to change, but rather continue with an increasing effort. It is all about portability.

Just to clarify: I am NOT saying that OOP doesn't have a very important place in the future of the web, without a doubt it does for all the reasons you have stated. What I am failing to see at the moment is why web developers shouldn't see web applications as collections of pages. After all, that's what they are unless you're writing a single-page app with oodles of client-side script to send and receive data that then update parts of that page (AJAX, basically). However I've not seen many of these apps, and certainly een the most Web 2.0 of my systems has multiple pages.

I understand that we have to be aware of different output formats - not just HTML pages, but web services, XML files, JSON etc etc - but surely an understanding and appreciation of the main output of a web application is crucial to making sure that app is as widely received as possible? Remember, when we're building web apps the ONLY things the users browser ever sees is the CSS, Javascript and HTML pages. Despite the huge changes afoot on the web right now I don't see the HTML page model disappearing anytime soon.

Do you get what I mean? What I'm saying is let's use OOP but within the HTML page model that websites are built on. This would be using the include capabilities of any scripting language that we've all be using for years to centralise code. That code could be classes; as I demonstrated above I've been mainly using OOP techniques rather than procedural ones for several months. Check out my last post, you'll see I've even wrapped up each HTML page into it's own object:

ChrisT wrote:

The biggest problem, and this is something that amazingly Microsoft have tackled pretty well, is making the entire page an object. In the Ruby code above you hard-coded your HTML, interspersed with Ruby. That's exactly what I've been doing for years, just not with classes. So I've tried to go one step further by incorporating a home-grown templating system in my apps that gives me access to methods like setTitle(), setJavascriptInclude() and properties like bodyID and bodyClass. Obviously I could take the page's methods and properties to the nth degree, but in general I leave little HTML to the processing page as possible - everything I can is put in the template file.

Using a similar idea I could create an XML or JSON object that then has it's content set by my other data classes. Don't you agree this is a step in the right direction?

Re: The great big friendly methodology debate

First of the web as a page.  Again, I think it has to do with thinking of the web as data and requests.  Though in reality this actually isn't much different then think of the web as pages and data.  The big change is actually, wording (as simple as that might sound).  instead of thinking of pages, you think requests.  How does this help us, because after all it is just a word.  Well it helps release the idea of the web for web browsers only.  In the web browser, everything is a page, correct, but say I have a desktop application that uses the web application to interact with, this desktop application doesn't see it as pages, rather requests.

So whats wrong with thinking of it as pages?  You will get a double layered application where one layer/half works with the page model of the browser the other works with the api/web service.  You get something like this:

        Browser
(get page)   /\
    ||           ||
    \/      (return page)
    Application
     /\     (return data)
     ||          ||
(get data)   \/
   Desktop Client

This theory creates a web application that needs two layers, not fun.  Now switching the words, lets think of EVERYTHING as a request.  Browsers are making a request (which could be for a full page, AJAX request, etc.), Desktop Clients are making requests, other services are making requests, etc..  Now we can simplify the application into something like this:

Browser, Web Service, Desktop Client
   (get request)        /\
         ||                  ||
         \/            (return request)
        Web Application

[I hope the diagrams come out well...]

Now we got rid of the extra layers of complexity (and maintenance)!  Everything goes in on one side and comes out the same (though in a different format, html, javascript, xml, etc.  this should be automated by the application).  Here is an example in Rails (which will make you want to use Rails :-P):

class PeopleController < ApplicationController
  def index
    @people = People.find(:all) #return an array of all People in Database
    respond_to do |format| #don't be scared by this, you can kind of look passed it
      format.html #render /app/views/people/index.rhtml if the request is for html
      format.js   #render /app/views/people/index.rjs if the request is from an AJAX request
      format.xml { render :xml => @people.to_xml } #renders the people as xml
      #... etc ...
    end
  end
end

This is advanced, so don't try to think about it too much.  All it does is render the appropriate thing depending on what was 'requested'.  This allows someone to write the functionality once, and respond to anything, depending on what was requested.

So to sum this up, page vs request methodologies:  they really aren't any different, it is just using a different word to allow yourself to recognize things.  It helps you think of web development differently.  The practice is roughly the same, its just a shift in how you think of things, thats it, in the end it is just a word, but the wording makes all the difference.

---

Now to answer you question on how Ruby does inheritance.  There are 2 "containers".  A class and a module.  A module is like a class but cannot be instantiated. So you can't do module.new, an error occurs.  There is no multiple inheritance, so to get around this Ruby uses something called mixins.  It basically takes a class, and adds the functionality of a module to it.

module Foo
  def say_hello
    puts "hello"
  end
end

class Bar
  include Foo

  def say_goodbye
    puts "goodbye"
  end
end

foo = Foo.new #error
bar = Bar.new
bar.say_hello #"hello" <- this comes from Module Foo, using it as a mixin
bar.say_goodbye #"goodbye"
In the beginning God created the heavens and the earth. [Gen. 1:1]

Re: The great big friendly methodology debate

This is all a bit over my head, and outside my area of expertise. I just wanted to chime in and say that Ray is the king of ASCII diagrams. smile

Give me liturgy or give me death.

Re: The great big friendly methodology debate

Haha, hey thanks a lot!

In the beginning God created the heavens and the earth. [Gen. 1:1]

Re: The great big friendly methodology debate

ChrisT wrote:

Just to clarify: I am NOT saying that OOP doesn't have a very important place in the future of the web, without a doubt it does for all the reasons you have stated. What I am failing to see at the moment is why web developers shouldn't see web applications as collections of pages. After all, that's what they are unless you're writing a single-page app with oodles of client-side script to send and receive data that then update parts of that page (AJAX, basically). However I've not seen many of these apps, and certainly een the most Web 2.0 of my systems has multiple pages.

Developers can see the web as bunch of pages, if they so choose, but I think they would be missing a lot of the of the finer details of the web architecture. A static web site of 5 pages, is just merely pages. With pages, little if any interaction between the site and user takes place. There may be a form that takes input and stores it, but no real interaction like we see with desktop applications. Applications, interact with users. Applications provide solutions to problems. Pages serve information, but not working solutions to help solve problems.

If we are going to get caught in semantics that a page is a page regardless of what it does, then everything is a page regardless. But, what I have been talking about is a way of seeing the internet for what it is: A global community that has real problems and real needs that need to be solved for their day to day activities and businesses. Thus, I can provide more than a mere page that can interact with a community of people to help solve their problems.

A simple example: Campfire. If campfire was a page, it would only provide information, not allow a group of people to interact with it and each other. The software keeps records that can be viewed at any time. It connects people with people. It solves a real problem.

Now, maybe you view pages differently than I have explained here, which is how I view them. As Ray said, it is a way of thinking about our online environment and realizing it is more than just a text holder.

ChrisT wrote:

I understand that we have to be aware of different output formats - not just HTML pages, but web services, XML files, JSON etc etc - but surely an understanding and appreciation of the main output of a web application is crucial to making sure that app is as widely received as possible? Remember, when we're building web apps the ONLY things the users browser ever sees is the CSS, Javascript and HTML pages. Despite the huge changes afoot on the web right now I don't see the HTML page model disappearing anytime soon.

From my view point, I'd be thinking how we can make the browsers see more than just those technologies you've listed and the few others that it also understands. It isn't that HTML is going anywhere, or even about *replacing* any technology. It is about how we *perceive* the web that can make all the difference.

There is a reason why the 37signals are doing so well. They have stopped seeing the web as place that solely delivers information and see it as a place that can deliver solutions to people who have real needs and problems. It is a lower barrier to entry for those of us who don't have 100's of thousands of dollars to enter a market and compete. Anyone can come up with a great idea and built it and sell it, right here on the internet.

ChrisT wrote:

Do you get what I mean? What I'm saying is let's use OOP but within the HTML page model that websites are built on. This would be using the include capabilities of any scripting language that we've all be using for years to centralise code. That code could be classes; as I demonstrated above I've been mainly using OOP techniques rather than procedural ones for several months. Check out my last post, you'll see I've even wrapped up each HTML page into it's own object:

As far as OOP is concerned, I said previously that I believe it really comes down to what fits your brain better. But, I do believe that every developer is going to have to get used to OOP someday because things are changing and they are changing quickly. Technology isn't one to wait for us to learn, it will pass us by without a bat of the eye. We, as developers, must constantly be learning, pushing ourselves to do better; to learn new things/technologies and expand our minds. The minute we stop and become complacent, we've already been passed up by technology. Honestly, it reminds me a lot of Christianity in the respects of becoming complacent. We must always be active, we must always be disciplined and push ourselves to be better.

ChrisT wrote:

The other thing PHP really kicks donkey in is it's awesome range of built-in functions. You need to do something to a string or an integer? Chances are PHP has the exact thing you need as part of its core library.

Ruby, being a pure OO language, also has its own cool things. If I wanted to convert a number to a string = 1.to_s. If I want to convert a string to number = "10".to_i. This is a classic example that every number and string is an object. And because it is an object, each has its own set of methods and that means every thing in Ruby has methods for it. PHP does not. And surely you wouldn't tell me that a non object has more depth than an object.

You should see that with a pure OO language, you receive more from the get go than you do with non pure OO language. It is never about one language being bad or procedural style coding being bad. It is about being productive and giving the highest quality product so that it is easy to maintain in the future, while providing great performance. The quality we are talking about here is not what the customer sees, or the clients, it is about the quality of the code so that it is simple to maintain and scale. OOP has always been better at scaling and maintaining.

I'd suggest taking a look at Design Pattern Books to get a better perspective on how OOP can benefit you.

Re: The great big friendly methodology debate

Wow. Ray, can I make a request? Can you draw an ASCII diagram of my brain exploding? smile

OK, there's loads to think of there. Robert, I absolutely see what you're saying. And yes, I have been guilty of seeing things everything in terms of pages. There's a valid reason for that; all my apps so far have been accessible (wther they spew out HTML, XML, JSON etc etc) at a URL, for example http://myapp.com/users/edit/123/. And where I see a URL, I think of a page. Maybe that's not quite what you mean, but that's what I meant when I said the page model isn't going anywhere soon.

However (you knew there'd be one of those, didn't you) I don't agree with a few things you said:

Robert Evans wrote:

There may be a form that takes input and stores it, but no real interaction like we see with desktop applications. Applications, interact with users. Applications provide solutions to problems. Pages serve information, but not working solutions to help solve problems.
...
Thus, I can provide more than a mere page that can interact with a community of people to help solve their problems.
...
A simple example: Campfire. If campfire was a page, it would only provide information, not allow a group of people to interact with it and each other. The software keeps records that can be viewed at any time. It connects people with people. It solves a real problem.
...
Now, maybe you view pages differently than I have explained here, which is how I view them. As Ray said, it is a way of thinking about our online environment and realizing it is more than just a text holder.

OK, where do I start? Firstly I see that Ray is absolutely right about the semantics surrounding the word "page". I see a page as a resource which may or may not have any level of interactive functionality attached to it. Campfire is, in my view, a series of web pages with come nifty client-side scripting going on to provide the interaction. However I get the feeling what you see a "page" as nothing but a static display of information, and that's why you provide "more" than a mere page.

But I provide pages that do a job: in your parlance, a website that gives interaction, serves information AND gives working solutions. I'm sure we're all singing from the same hymn sheet here, and discussions about something as esoteric as the meaning of the word "page" aren't very productive, and it's obvious we have a different view on that particular word. Maybe I should use the word "resource" instead to make things clear. Anyway, as you've rightly said, it's the quality of the solution that makes the difference.

There is a reason why the 37signals are doing so well. They have stopped seeing the web as place that solely delivers information and see it as a place that can deliver solutions to people who have real needs and problems.

Nope, don't agree with that either smile 37signals aren't the only people in the world to build interactive web applications. They weren't even the first, not by a long way. They are successful because their solutions are simple but powerful, elegant and aimed at the right market. The rest of the web-world isn't still stuck in 1996, and even average-sized companies now have websites that provide useful solutions to fill real needs. Still, the 37signals boys are an inspiration to me because of the way they constantly allow users to do more with less hassle - much like the Ruby language itself, I would guess.

ChrisT wrote:

The other thing PHP really kicks donkey in is it's awesome range of built-in functions. You need to do something to a string or an integer? Chances are PHP has the exact thing you need as part of its core library.

Ruby, being a pure OO language, also has its own cool things. If I wanted to convert a number to a string = 1.to_s. If I want to convert a string to number = "10".to_i. This is a classic example that every number and string is an object. And because it is an object, each has its own set of methods and that means every thing in Ruby has methods for it. PHP does not. And surely you wouldn't tell me that a non object has more depth than an object.

Absolutely not, and I made exactly that point myself earlier in the discussion. However PHP does have the equivalent functions to do what your examples do there, just using procedural rather than OOP techniques. Which, in simple apps at least, is more than adequate. Note I said 'adequate' and I also said earlier that PHP is good for smaller apps. If we're talking enterprise-level stuff then we're into a whole new world, and one in which Ruby has yet to make big in-roads, too. Maybe it will, it certainly has the passionate support of a lot of developers, only time will tell.

Ray, your diagrams were a great help. And the snippet of Ruby (hey, it really is easy to understand!) is extremely impressive. Traditionally I've had to write functions to do all that array-to-output-format stuff myself, if it's built into Ruby then that's a great thing. Your and Roberts explanation of other output formats and devices was also useful, as I think a lot of developers (myself included) get a buit myopic when they're writing web apps day in, day out. I get asked to provide things in XML (or JSON, or CSV, or PDF, or other formats) regularly, but still it's easy to slip into seeing these outputs as less important.

class Bar
  include Foo

  def say_goodbye
    puts "goodbye"
  end
end

Well strike me down. That's great. But what I really want is something like this:

class Bar
  include Foo
  include Boo
  include Goo
  include Soo

  def say_goodbye
    puts "goodbye"
  end
end

Is that possible?

Re: The great big friendly methodology debate

Acknowledging that there are many kinds of tools to do a job, and that not all tools are created equal is the first step to recovery as a developer. Yes, the language that you use might be the only one that's worthy of your supremely magnified intelligence. But there are still others out there, and sometimes we are either forced (as in the case of a client who insists on a certain technology) or choose to use them.

Having said that sarcastic bit, I vastly prefer Ruby to any other language I've ever seen or heard of. The whole idea of Ruby is that you get to talk to the objects that you're using. So, for example if I have a date object like

today = Time.now

, using Rails' convenience methods I can ask today to give me the time in one week:

>> today = Time.now
=> Thu Oct 12 09:15:47 CDT 2006
>> today + 1.week
=> Thu Oct 19 09:15:47 CDT 2006

>> 7.days.from_now
=> Thu Oct 19 09:15:51 CDT 2006

I can instill any methods that I like into an object, and then talk to that object about its methods. I can ask a number if it's even or odd.

>> 5.even?
=> false
>> 5.odd?
=> true

I can do easy data calculations:

>> 1.kilobyte
=> 1024
>> 1.megabyte
=> 1048576
>> 1.terabyte
=> 1099511627776
>> 1.petabyte
=> 1125899906842624
>> google = 666.petabytes
=> 749849337957187584

But to me, the real sugar is in the ActiveRecord database handles. The fact that I can have a User object that maps directly to a users table is pure luxury. I often forget that I'm working on a database at all - the db fades away leaving only the data, my app, and a very happy programmer.

So, forget what I said above. There is only one real tool for every job - Ruby. There is no other. Totally kidding of course. PHP is great for lots of applications, and I've often used it for quick calculations and includes. But that's changing. In the past I would have done a one-page site like http://www.artofmission.com/survey/ with PHP, but it was just so easy to throw it together as a quick Rails app, and I got the benefit of transparent database operations with the package.

ChrisT wrote:

Is that possible?

Chris - I'm not quite sure, but I think you're asking if you can include multiple modules in a class. Yes, you can do that.

Ryan Heneise  |  Art of Mission  |  Now with extra-strong Donor Tools mojo

Re: The great big friendly methodology debate

ChrisT wrote:

OK, where do I start? Firstly I see that Ray is absolutely right about the semantics surrounding the word "page". I see a page as a resource which may or may not have any level of interactive functionality attached to it. Campfire is, in my view, a series of web pages with come nifty client-side scripting going on to provide the interaction. However I get the feeling what you see a "page" as nothing but a static display of information, and that's why you provide "more" than a mere page.

But I provide pages that do a job: in your parlance, a website that gives interaction, serves information AND gives working solutions. I'm sure we're all singing from the same hymn sheet here, and discussions about something as esoteric as the meaning of the word "page" aren't very productive, and it's obvious we have a different view on that particular word. Maybe I should use the word "resource" instead to make things clear. Anyway, as you've rightly said, it's the quality of the solution that makes the difference.

Then it is merely a difference in how we view *pages*. In the conception of the internet, HTML was used to display text, a text holder per say. It wasn't used for interaction. Today, we used server side languages that pull data from a database and display it for the user to read. It is still the same thing, a text holder. What changes is when you start getting the user to interact with the application and the application either interacts with the user or connects users to connect with each other or both.

In many respects, people still use the internet to display information that is meant to be read, but not interacted with. I'm used to when people talk about pages, they are refering to a page that is used to *just* display text, nothing more, hence my different view point on the word pages in the context of the internet.

ChrisT wrote:

Nope, don't agree with that either :) 37signals aren't the only people in the world to build interactive web applications. They weren't even the first, not by a long way. They are successful because their solutions are simple but powerful, elegant and aimed at the right market. The rest of the web-world isn't still stuck in 1996, and even average-sized companies now have websites that provide useful solutions to fill real needs. Still, the 37signals boys are an inspiration to me because of the way they constantly allow users to do more with less hassle - much like the Ruby language itself, I would guess.

I wasn't intending to say 37signals is the only company doing what it is doing. Instead, I was saying the 37Signals' of the world, meaning *all* the companies that are providing simple solutions to problems that interact with their users. Neither was I saying the rest of the web-world is back in 1996.

I think unless one actually gives Ruby a serious try for a descent amount of time, one won't know the benefits of the language. That is one of the many reasons why I have said, we as developers, ought to learn at least 1 new language every year.

It is like being a Christian and having Christ transform your life. You won't really know what it is like until you give it up to God and allow Him to change you. Until then, you can fight against it, say how everyone is wrong when they express their benefits from what God has given them.

ChrisT wrote:

Absolutely not, and I made exactly that point myself earlier in the discussion. However PHP does have the equivalent functions to do what your examples do there, just using procedural rather than OOP techniques. Which, in simple apps at least, is more than adequate. Note I said 'adequate' and I also said earlier that PHP is good for smaller apps. If we're talking enterprise-level stuff then we're into a whole new world, and one in which Ruby has yet to make big in-roads, too. Maybe it will, it certainly has the passionate support of a lot of developers, only time will tell.

Maybe that is our difference in view points, the size of the application itself. What would define an enterprise application? We can see the wiki's definition and if we are to use that as our definition, Ruby is already doing these things. (http://en.wikipedia.org/wiki/Enterprise_application) Ruby may not have a lot of applications in the enterprise arena, but can you expect it to with only 3-5 years that it is been prevalent in the West?


ChrisT wrote:

Ray, your diagrams were a great help. And the snippet of Ruby (hey, it really is easy to understand!) is extremely impressive. Traditionally I've had to write functions to do all that array-to-output-format stuff myself, if it's built into Ruby then that's a great thing. Your and Roberts explanation of other output formats and devices was also useful, as I think a lot of developers (myself included) get a buit myopic when they're writing web apps day in, day out. I get asked to provide things in XML (or JSON, or CSV, or PDF, or other formats) regularly, but still it's easy to slip into seeing these outputs as less important.

class Bar
  include Foo

  def say_goodbye
    puts "goodbye"
  end
end

Well strike me down. That's great. But what I really want is something like this:

class Bar
  include Foo
  include Boo
  include Goo
  include Soo

  def say_goodbye
    puts "goodbye"
  end
end

Is that possible?

Yes, you can. As per Ray's example of RESTful techniques which leverage HTTP, those formats aren't the only ones you can provide support for. You need RSS, simple. What about a MIME Type, let's say for mobile phones. I can simple do the following:

#config environment.rb
MIME::Type.register :mobile, "text/x-mobile"

#routes.rb
map.connect "mobile/appointment", :controller => "appointment", :format => "mobile"

#controller file
class AppointmentController < ActionController::Base
  def index
    @appointments = Appointment.find :all
    respond_to do |format|
      format.html
      format.js
      format.icl       { render_calendar(@appointment) }
      format.xml     { render :xml => @appointment.to_xml }
      format.mobile { render :action => "index_mobile" }
      format.atom do
        render :action => "atom", :content_type => Mime:ATOM
      end
    end
  end
end

This is just an example to show that I can render the appointments found in any type of format listed within the respond_to block. I created a mobile Mime Type that can be served as well as xml, atom, html, js, or ical. I can create more if I needed it too. And how they are served is simple if the HTTP header request matches the format, it will be servered.

That is just a simple example of the some of the cool things *Rails* has included because it is written in Ruby.

Re: The great big friendly methodology debate

I think we all need a big huge :-P.  Seems like we are all on somewhat the same page.. err request, haha.  Nice to see you drop in Ryan, now its 3 Rubyist vs 1 PHP(ist/er/ dude)... this can get ugly.

So to I got my wisdom teeth pulled out today... sorry, they are just screaming for attention.  So I think we can sum this up as OO will rule the web soon, although the formats that are output, are surely less OO in feel compared to the Models and the Controllers.  I am going to go lay down. (slaps Ryan's hand, "your up").

In the beginning God created the heavens and the earth. [Gen. 1:1]

Re: The great big friendly methodology debate

RayCMorgan wrote:

...now its 3 Rubyist vs 1 PHP(ist/er/ dude)... this can get ugly.

You're right, it could. But don't worry, I'll go easy on you all wink

So I think we can sum this up as OO will rule the web soon, although the formats that are output, are surely less OO in feel compared to the Models and the Controllers.

Yes, this seems to sum things up. I was pretty convinced of the OOP thing before this discussion, but it's certainly helped to confirm some of the more esoteric nuances of this methodology. Maybe I had unrealistic expectations, but seeing code that was this:

<html stuff>

<instantiate an object and set some properties>

<more html stuff>

<invoke a method>

<more html stuff>

<output the methods' return property (or similar) >

<more html stuff>

<a bit more stuff with the object>

<finish html stuff>

Rather than this:

<html stuff>

<set some variables and include a set of functions>

<more html stuff>

<call a function>

<more html stuff>

<output the functions return property (or similar) >

<more html stuff>

<a bit more stuff with some functions and variables>

<finish html stuff>

Made me a bit confused. It happens a lot, I know. However there are definite advantages to wrapping things in classes, and I also have to say that Ruby/Rails looks very, very impressive. More of an investigation is obviously needed - when I find time roll

Robert Evans wrote:

Then it is merely a difference in how we view *pages*. In the conception of the internet, HTML was used to display text, a text holder per say. It wasn't used for interaction. Today, we used server side languages that pull data from a database and display it for the user to read. It is still the same thing, a text holder. What changes is when you start getting the user to interact with the application and the application either interacts with the user or connects users to connect with each other or both.

In many respects, people still use the internet to display information that is meant to be read, but not interacted with. I'm used to when people talk about pages, they are refering to a page that is used to *just* display text, nothing more, hence my different view point on the word pages in the context of the internet.

OK, I thought so. I've certainly learned to be more careful with my choice of words when describing certain aspects of web apps. Thanks Robert, what you've said is certainly appreciated.

ryenski wrote:

But to me, the real sugar is in the ActiveRecord database handles. The fact that I can have a User object that maps directly to a users table is pure luxury. I often forget that I'm working on a database at all - the db fades away leaving only the data, my app, and a very happy programmer.

That, more than anything else, sounds wonderful. Now, can anyone write a system to give me more hours in the day?

Re: The great big friendly methodology debate

As someone who uses both PHP and Ruby on a regular basis, I must say that the fact that everything is an Object in Ruby does make it easier to go down the OO path. PHP with it's roots in C, I feel lends it self to procedural programming.

To reiterate what I see all the OO proponents saying:

OOP is not just encapsulating functionality in classes. OOP is like creating a little world and populating it with objects that interact with one another.

Yes as Robert said:

# Analysis and Design Made Easier
# Code Reuse
# Ease of Maintenance and Enhancement
# Iterations Fewer and Shorter

are all side effects of OOP. But the real power of Object Oriented programming is learning to turn your brain inside out and be able to visualize your application in a way that procedural programming does not lend it self to.

If you think about it the world we live in is Object Oriented, and by programming in that manner we are able to see possible interactions with data before the customer/client does.

class Tree
end

class Man
	include ImageOfGod
end

class Woman < (rib.from(Man))
	def initialize(man)
		man.remove(:rib)
	end
end

tree_of_good_evil = God.create(new Tree)

adam = God.create(new Man)
if ( adam.alone? != "Good" )
	eve = God.create( new Woman(adam) )
end
	
if( adam.stomach.includes?(tree_of_good_evil) )
	include Sin
end

Not to belabor my point, but once it clicks OOP will change the way you work.

Last edited by kennyparnell (2006-10-25 21:15:35)

Re: The great big friendly methodology debate

Kenny: That's awesome! smile

Give me liturgy or give me death.

Re: The great big friendly methodology debate

Ha ha, sweet illustration.

In the beginning God created the heavens and the earth. [Gen. 1:1]

Re: The great big friendly methodology debate

Kenny, that's fantastic. Can you do the rest of the bible - maybe then I'd understand it a bit more :0)

I agree with what you say. The only language I know pretty well where everything is an object is Javascript, and knowing that certainly has changed the way I work.