[eluser]jedd[/eluser]
I see that you've worked out routing. Or at least discovered it.
To answer one of your questions there - if you onlya nticipate future changes would be to
add new things you want to route, then just negate your logic and
don't route everything that fits your hard-coded and defined set of controller and/or method names.
Quote:In order to grab what is behind and what is forward a given position, we need to have two methods on our model. One to grab the parents of a given ID passed on a where clause, another to grab the childs given an ID passed on a where clause?
If so:
2.1) Where should that ID come from?
Okay, let's call this the fifth reason why names are less attractive than ID's here - you have to do an extra database hit on the way in to convert your name to an ID, and then on the way out again to convert the ID to a name. Yes, you have to do those kinds of lookups in either case - but they're more likely to be embedded in a single SELECT/JOIN if they're based on ID. Not a huge thing, of course, as database lookups like this are reasonably cheap, especially if you index your name column. Still, it's an additional level of indirection, and you have to contend with duplicate names (as discussed earlier) which is a problem you don't have with an ID field.
As to
where you'd do this .. well, somewhere early on I would imagine. The constructor of your controller seems like a sensible place, assuming only one controller ever cares about this translation.
Btw, 72 characters is the usual auto-wrap for email clients. Breaching that number can cause URL's to be split, and not all mail clients, particularly after a message has been replied/forwarded, will automatically join a URL that spans two lines.
