SitePoint Sponsor

User Tag List

Results 1 to 8 of 8
  1. #1
    SitePoint Wizard
    Join Date
    Mar 2002
    Location
    Bristol, UK
    Posts
    2,240
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    A decent approach to application design?

    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.

  2. #2
    SitePoint Enthusiast
    Join Date
    May 2007
    Posts
    74
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    dude, you plan is perfect, , my advise is, just do it.

    happy programing

  3. #3
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why not use one of the MVC frameworks for PHP? This is a commonly solved problem in all the frameworks I've looked at.
    Creativity knows no other restraint than the
    confines of a small mind.
    - Me
    Geekly Humor
    Oh baby! Check out the design patterns on that framework!

  4. #4
    SitePoint Wizard
    Join Date
    Mar 2002
    Location
    Bristol, UK
    Posts
    2,240
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by imaginethis View Post
    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.

  5. #5
    SitePoint Zealot
    Join Date
    May 2008
    Location
    Montreal
    Posts
    155
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  6. #6
    SitePoint Addict Mastodont's Avatar
    Join Date
    Mar 2007
    Location
    Czech Republic
    Posts
    375
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    /widgets/list/20/ (20 being an optional parameter to limit the display to 20 widgets)

    Usually it is page number, not count of items.

  7. #7
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Peter Goodman View Post
    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.

  8. #8
    SitePoint Zealot
    Join Date
    May 2008
    Location
    Montreal
    Posts
    155
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •