Makunas, Michael <Makunas.Michael <at> mtvne.com> writes: > My question is where do people generally put the logic for determining > something like the value of the href attribute?
Good question. I've noticed the same problem in the prototype I'm working on. I haven't implemented the solution yet, but I have some ideas. I'm generally using subclassed Finders to lookup Domain objects and subclassed Resources to render each Domain object, which sounds similar to what you have. I pass a String href into the Resource constructor because it doesn't (shouldn't) have any knowledge of URLs. When the Finder (or whatever your controller is) constructs the Resource, in some cases its own request.getResourceRef().toString(true,false) is the appropriate value to pass in. But I may have more than one way to arrive at the same top-level domain object so I don't want to rely on that. What I'm leaning towards for a solution is a single utility class that can determine the canonical URL for a given domain object. This would be configured with a Map of class-names to url-patterns. This might be the one-center-of-ugliness pattern, but I'm using Spring to wire up my Router, so I can at least put all the configuration of URLs to Restlets near (in XML) the configuration of the reverse mappings of domain objects to URLs. When I get into my "list" controllers (in your example, whatever Finder returns a list of Foos), it's just too convenient to have an authority that can be given a domain object and hand me it's authoritative location. Hope this helps. I'm new to Restlets but have noticed the same problem so I'm curious what experts have to say. Stokes.
