[eluser]jedd[/eluser]
Okay, I'm a bit torn here.
In practice you say you're going to have three levels, and only three levels - which suggests you could have a category (1, 2, or 3) assigned to each entity to denote what generation (grandparent, parent, child) it resides.
In theory you say you want something that will scale to 'infinite' levels - which suggests absolute generations are wrong, and you instead need to emulate a nested set.
If you have at most three levels, then your URLs can easily be of the form: /27/42/69 - where 27 is the ID of the grandparent, 42 the parent, 69 the child.
You would only ever show the child if you're showing parent and grandparent at the same time. Similarly you'd only show the parent if you were showing the grandparent too. You'd never show anything without showing its ancestors, in other words. This means your URLs could 'degrade' nicely - you could have /27/ and that would be easy to interpret - it would mean 'show me the grandparent ID27 and everything under it.
I still assert that you don't need all three bits of data - you can deduce the other two from any given one that you are given - but I mean that it would be
manageable to deal with the two bits of redundant data.
I think part of your confusion is trying to work out the visual aspects of your data, at the same time as the logic of your database structure, and indeed the logic of your data retrieval functions.
If you have just three levels, then constructing the last segments of your URL is easy - you pull $grandparent, $parent, and $child from somewhere - say your session data, your current URL, etc - and reconstruct the new URL with that information appended. Obviously you can't have more than one set of 'variable length' data, unless you start noting the nature of each segment. (And you can do that with a 'g', 'p', 'c' prefix, or by alternating url segments with key/value pairs - for example, /g27/p42/c69/, or /g/27/p/24/c/69 - the latter has support within the URI helper, from memory, for pulling these apart and re-constructing them. I'm writing something that uses the /g27/p42/ approach at the moment - and it's fairly painless.)
But this is all just a lot of pain to work around a problem that I think you can ignore. I really do believe that if all your entities are contained in one table - that is, the 27, 42, and 69 (for example) all come from one
thing.id column - and you have a
thing.parent column in that same table - that you should only use ONE parameter, ONE number, to denote your current thing. As I mentioned before, it's easy to work out what's above and beneath any
thing with two very simple model functions.
Quote:What it isn't tempting, it's thrown out to the window 1 months and a lot of hours spending to arrive where I'm now.
Yeah, this is a tough call. Can you fork here - are you using a CVS? if not I recommend git - and experiment for a couple of days down this path, and see if it makes more sense, or makes things easier at least?
When I talk about preserving the parentage, I don't mean in the URL - I just mean on-screen, within the browser window proper.
I think URL's need to be consistent over time, but they don't need words, and they don't need to be long.
Quote:I'm not sure if I understand: you are giving an example of a breadcrumb when the user will be on the Herbícidas page?
It's not a breadcrumb in the sense that it lets the user go back to where they came from - just context so they can work out where they
are - and obviously you'd provide links to the context elements so they can move up and down the hierarchy more easily.
This definitely gets difficult to make a decision about when you've got 2 or 3 (but no more) levels of hierarchy - as you'd obviously be better off showing them as 2 or 3 columns, and the user can see the whole thing laid out in front of them. As soon as you go for more columns or levels of hierarchy it gets really confusing, visually, as well as code, I think.
My final comment - on using names rather than ID's - in your URL. I think this would be bad, for a number of reasons. First, long URLs are painful, especially once they breach 72 characters. Second, IDs for a given thing tend to stay the same forever, but names sometimes change - which reduces the longevity of URL's, which annoys users (directly or indirectly because it also annoys search engines). Third, words tend to have characters in them that need translating - such as spaces - so that they may appear in a URL, and that makes them look different to the
actual name of the thing. Fourth, names are possibly not going to be guaranteed unique in this context - insofar as you may have a product that matches the name of a product category, for example.
