One method I’ve used is the idea of a resolver. The application might keep the current pattern for a link generated from data, but the resolve allows for previous patterns to also be used. It also allows for a catalog of bases to be used (ie XML Catalog). This idea is based entirely on creating a custom URL resolver for XSLT, which most XSLT processing libraries support.

The point here is that I agree links should be first class objects in addition to having a framework or controller in place for managing them that goes beyond simple parsing/routing.

This keeps the separation of concern between the model and templates. Also designers have specific areas in which they can manage / inspect templates should they want to extend or change markup.

How you handle template helpers is another area for debate - you could use template fragments in separate html files (keeping the designers away from code) or return strings from the helper methods - but then is that as bad as declaring them in the model? Probably not, I’d say its still slightly better but its a matter of preference. I’d choose the latter if my designers had a high level of competence with scripting languages i.e. frontend developers.

def url(post)>
  <a href="/post/${post.year}/${post.month}/${post.slug}" rel="nofollow">
    ${post.title}</a>
/def&gt;

(something is wrong with your markdown formatting, or I’ve just drank too much tonight)

The filter method someone mentioned above can work with this, though I don’t use filters that way myself that often.

This is how it would be done with Ruby/ERB:

<ul>
  <% recent_posts.each do |post| %>
    <li><%= link_tag h(post.title), post_url(post) %></li>
  <% end %>
</ul>

Or perhaps if you find yourself creating links to posts often, use a template helper:

<ul>
  <% recent_posts.each do |post| %>
    <li><%= link_to_post(post) %></li>
  <% end %>
</ul>

@link.when('isinstance(obj, Page) and obj.type == "link"')
def link(obj):
    return obj.body

Of course in Zope you’d probably have separate class types; outside of Zope it’s more common to use a single class that’s more connected to the storage type (e.g., a one-to-one mapping of class to database table).

Generally, I’m not sure the complexity of the indirection pays off much. In theory there’s some important separation going on there, but in practice I’ve never seen it. Given a RESTful approach, there actually isn’t a distinction at all — an object is at its URL, this is not just an implementation detail. I don’t think of the web as an implementation detail, in my mind it is core to the application itself.

That said, creating URLs without some kind of helper is also a needless waste of time and causes bugs (e.g., not allowing for application path prefixes, not quoting segments properly, or spending an inordinate amount of time formatting query string parameters). And once you have a helper, you’ve got at least some indirection happening.

See slide 147 of my NOLA Grok talk for an example of how a URL factory looks when you build it for one of your own types. I should nudge the Grok folks to make that take less lines and look less grungy. Like maybe three lines. Yeah, three lines.

One way of handling this would be to use template functions or blocks. Then you can centralize the logic of link display (making it easier to extend that logic) while still putting it somewhere a designer can find. Backtracking rendered code to these template functions isn’t that easy, but that’s something that should be fixed — it should be much easier to see a bit of rendered code and backtrack to where that code was defined.

Regarding Marcus’ point about relying on a framework’s reversing logic — IMHO, that’s going a bit too far, and I never use reverse() stuff in model URL methods. I tend to see this as an acceptable breach of the DRY principle, because it’s a lot more efficient just to hard-code the URL-generating logic directly in the url() method (as opposed to relying on the reverse logic).

It’s sort of like denormalizing a database for performance. If you’re outputting a list of links and each one is calling url(), which in turn calls reverse()…whew! That’s a lot of unnecessary overhead.

class Post(SomeORM):
    def url(self):
        if self.is_internal:
            return SomeRouting.reverse('view_post', id=4)
        else:
            return self.external_url

URI-aware objects provide consistency and extensibility.

I agree with the initial 40% of your idea, the rest, I think, pushes too much the View layer into the Control layer — post.link() will likely output links with classes and/or ids (even when assuming inline JavaScript is strictly forbidden), which introduces a high dependency/risk of keeping the Control code in sync with the View whenever the web team refactors/updates the design.

I believe a balance can be achieved when post.link_href() outputs the content of href and nothing else, while post.link_text() returns the a link text.

Jerry

P.S. How to disable/escape underscore Markdown formating? [for cases like these using backticks renders it as code and no markup is not interpreted inside the backticks -- Ian]