On Thu, Jul 22, 2010 at 12:24 PM, BrianTheLion <[email protected]> wrote:
> Good discussion already!
>
> Let me frame the three issues that I brought up in a broader context.
> IMHO, the "web pages" that we see gaining popularity these days tend
> to be collections of little widgets. I am thinking mostly of Facebook
> here, where each little widget gives us a slightly different view of
> the underlying data. One widget gives us a look at one subset of the
> data, another gives us a look at a different subset, etc. A user's
> "home page" is just a frame for a bunch of widgets. The user can
> "drill down" and get expanded views of the data by clicking through
> the widgets. I guess I'm struggling to implement this kind of user
> experience in the MVC paradigm.
>
> I start with two things:
> 1) A clear idea of how I want the user's experience to work (eg, what
> I just described)
> 2) A URL schema that - and maybe this is where I am going wrong -
> implements a kind of "pointer system" to the various views of the data
> that I want to show the user.
>
> An example of #2:
> http://mysite/user/danny gives danny's profile (a
> bunch of widgets)
> http://mysite/user/danny/email gives danny's email console
> http://mysite/user/danny/trips gives danny's trip console
> http://mysite/trip/1/participants (you get the idea...)
>
> This schema is maybe best described as {entity}/{id}/{view} or
> somesuchthing. For each kind of entity, I have a different Controller
> class and, typically, a database table and the rest. Different "views"
> get different Controller methods. So, UserController would have an
> "email" method, a "trips" method, and so forth.
>
> So I've got my #1 and my #2 and I start working in from both
> directions. The problems start to arise when I try to collect a bunch
> of different views into one, like on the user's "home page." This page
> would, basically, just be a frame that holds the output of
> http://mysite/user/danny/email/widget and
> http://mysite/user/danny/trips/widget
> and so forth. This is easy to implement using AJAX, but doing so seems
> really kludgey. I've also thought about passing the controller
> instance right into the template and calling the controller methods
> that correspond to the URLs (eg, UserController.email_widget and
> UserController.trips_widget), but that seems silly too.
>
> All of which leads me to believe that I'm violating the paradigm
> somehow.
>
> Any thoughts?
Nested structures are a bit complex, especially if they have to work
both embedded in a larger page and alone. And Pylons is not the best
framework for nested objects, although we're hoping to improve that in
Pylons 1.1.
There are two ways of handling related resources. One is to fully nest them:
/users/danny/trips/1/participants/BenBangert
The other is to put each one at the top level and indirectly relate them:
/users/danny
/trips/1 # user_id in database is "danny"
The flat approach is easier to progam, but sometimes you end up having
to pass the parent IDs as query parameters; e.g., for a "new trip"
form:
/trips/new?user=danny
At that point, the nested URL starts to look better, especially if you
need the parent IDs anyway for breadcrumbs (links to the ancestor
pages). But if you usually *don't* need the parent IDs, then maybe the
flat URL structure is adequate.
As for embedded widgets on a page, I wouldn't use AJAX unless you want
to go the whole AJAX route anyway. It turns one request into several,
adding overhead for no clear benefit. (It would be a clearer benefit
if the widget could page through its content via AJAX, or if
client-side scripting was doing its own additional calculations to
display in the widget.)
If you don't use AJAX, each widget would not have its own URL: the
page would take care of rendering it. So it wouldn't need an action or
a route or a "resource route action". That takes it out of MVC, which
only deals with first-class items that have their own URLs. It makes
the widget look more like a model-thing, an attribute of the user
object. So you merely have to query the model for the appropriate data
to display in the widget. You can still maintain a UI separation by
having the page template call a Mako function or helper that renders
the widget -- something that could be called by any other page that
wants to display the widget, including a dummy page that contains only
the widget.
Another thing. You're using the singular for resource collections.
/trip/1
That's fine but it can only implement a partial resource interface. In
other words, there's no page to list the members of the collection!
("/users" in map.resource : "/user" would be silly.) And you can't
post to "/user" to create a user. Well, you can, but again it would
be silly. So if you use the singular for the collection name, just
make sure you won't need the actions that it makes awkward. That could
well be the case; e.g., if you list trips a different way (via
"/users/danny/trips"), or if you add and delete trips outside the web
interface. And in some cases, you may not want to display the
collection index at all (e.g., "/users"). In that case, if you use
map.resource, it will create the route anyway, and you'll have to
sabotage it with a dummy action:
# /users
def index(self):
abort(404) # Or 403 (Forbidden)
I would not think of subsections of the page as "models" or "views".
They are just subsections, which may be related to a model or a view
but not necessarily. That's all a private matter for the action to
decide. Exposing it in the route or URL makes the application less
flexible.
--
Mike Orr <[email protected]>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
