A decent approach to application design?

[SJH]

Hi everyone,

I wanted to see what people think of my approach for a webapp I'm going to start developing shortly.

My planned approach is as follows.

URLs are in the format /module/action/parameters/
So the URL to view a listing of widgets might be /widgets/list/20/ (20 being an optional parameter to limit the display to 20 widgets).
Or the URL for displaying a form to edit a specific listing might be /widgets/edit/12345/ (12345 being the unique ID of the widget's database record).

So if we use my first example, the front controller would call the Widgets controller, which in turn would call the list() method found in that class. The list() method would then call a generic Template class and a generic Records class, the latter of which would query the database and return an array of widgets. The array would then be converted to an HTML table. The table and the template could then be sent to output.

Obviously the final product would be slightly more complex than this, but hopefully from the description above you can see the general intention.

What do people think of this idea? I've seen applications done like this before but would like to know if it's a bad idea or if it will end up being too restrictive as I constantly add new features to the application.

[ctx2002]

dude, you plan is perfect, , my advise is, just do it.

happy programing

[imaginethis]

Why not use one of the MVC frameworks for PHP? This is a commonly solved problem in all the frameworks I've looked at.

[SJH]

Why not use one of the MVC frameworks for PHP? This is a commonly solved problem in all the frameworks I've looked at.

It's a problem I want to solve myself I've only recently started learning about OOP principles and I think the best way of learning it is to get my hands dirty and write an application from scratch.

Plus eventually this application will be sold commercially and I want to be able to decide on licensing etc without being confined to licences that come with frameworks.

[Peter Goodman]

One thing you should look out for is, with respect to your routes, to always make a distinction between what parameters help represent a resource and what parameters belong in GET variables. A nice way to think of it would be to look at the parameters as a superkey (in database terms), where the route would no longer uniquely identify the same resource if a single parameter was removed. Anything that doesn't fit this requirement doesn't belong in the URL/URI and should be passed as a GET variable.

In your example, /widgets/list/20, 20 doesn't uniquely identify the resource. You are viewing a widgets list, and it will always be that, regardless of how many widgets are displayed. In fact, the 20 represents a filter on how widgets are viewed. Although you might now find it as pretty, I suggest: /widgets/list/?limit=20.

[Mastodont]

/widgets/list/20/ (20 being an optional parameter to limit the display to 20 widgets)

Usually it is page number, not count of items.

[allspiritseve]

In fact, the 20 represents a filter on how widgets are viewed. Although you might now find it as pretty, I suggest: /widgets/list/?limit=20.

By that logic, list is an action and doesn't uniquely identify a resource either. So maybe /widgets/ lists all widgets, /widgets/widget_name/ lists a specific widget name, etc.

[Peter Goodman]

The point is to see the route as a URI, not as an alternative to the query string. Query strings have a purpose and should be used, as should routes. They are not mutually exclusive.

Most people are used to doing, for example, view.php?id=...&... and from this, we need to be able to say, if we were instead to translate this query string into a RESTful approach, how much of what is in the query string actually belongs in the URI and how much of it should stay in the query string.

Well, as my earlier comment suggested, look for what uniquely identifies the resource. Going with a simple example of a forum which lists threads and includes pagination. The forum id uniquely identifies the resource, that being the forum we want to look at. Now, for pagination. Is the resource dependent on pagination? If we remove the pagination stuff form the URI then will be suddenly be looking at a different resource? No, because pagination affects the view, not the resource. And so, pagination belongs in the query string.

If we look at a different form of pagination, where instead of telling us what page to look at, we provide a thread id and then show only threads the came before that (in the same way reddit does pagination) then, the example resource might be /threads/<forum-id>/<thread-id> (note: I randomly chose the prefix /threads, there might be one more appropriate but that is irrelevant to the argument). Well, the thread-id uniquely identifies a new resource!

This might seem somewhat arbitrary. Consider, for example, that when viewing a forum, we will always see threads belonging only to that forum. When paginating a forum with a thread id, we will always see the same list of older threads for any given thread id, regardless of if we go to it today or in two months.