[eluser]MEM[/eluser]
[quote author="jedd" date="1256769645"]
By recursively build the URI segments, do you mean the model / database side that pulls out the information, or actually generating a URL that provides the full parentage?
[/quote]
The second one. Generating a URL that provides de full parentage.
[quote author="jedd" date="1256769645"]
If you mean the URL thing, I'd suggest you don't go down that path - it'll get ugly.
[/quote]
I realise that having a bunch of id's on the address bar is ugly. I intended to change the ids by the corresponded names, hoping to be easy to memorize, SEO friendly, and not so ugly. But I would take care of that, and other details, only after the menu is working.
[quote author="jedd" date="1256769645"]
Any single ID you get on the URL can be used to identify WHERE in the hierarchy you are - and you can then have model calls that look up parentage, as well as children.
[/quote]
Ok... I know you had said that before, but only today, I'm understanding.
So I can get on the url only the id of the current item for example, and, you state that, with that ID we can display a list of navigation links that contain the parents and the children of that specific item. And we can also retrieve products information based on that id, and pass them to the page?
It is tempting.
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. But, hey, when we have do it for better, we do it. Anyway,knowing that I have take all this time, to arrive here, I'm wondering how much time will I take to drive a new path from here...
Right now, it's not clear, what should I throw away and what can I preserve, in order to follow that path?
But, if the "uglyness" is the solo argument against, then I believe changing the ids for the names, will be a nice solution.
[quote author="jedd" date="1256769645"]
The parentage information is used to give the user some context for what they're looking at. If you don't give them that information, then it will be like you have shown above - the user sees Fitofármacos, but then loses it when they go into Herbi - and they don't have anything on the screen to indicate how to get back up to Fitofármacos, or where Herbi fits into the overall structure.
[/quote]
Absolutely, and that is the reason why I want to preserve the parentage.
[quote author="jedd" date="1256769645"]
How about something like this:
visual information to the user (view stuff) has a prefix like this:
Top | Fitofármacos | Herbi - children : herb1, herb2, herb3 -- where Herbi (in this case) is bold/larger/not-a-URL-link but everything else is a link
[/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?
I should need one as well. But the intended result needs to be a vertical navigation system. However, that is only a CSS question. If I can do one, I can do the other I believe.
[quote author="jedd" date="1256769645"]
database functions (model stuff):
find_parents ( $thing ) - returns an array of parentage for the $thing
find_children ( $thing ) - returns an array of children of $thing
[/quote]
Where $thing will be that solo URL id passed?
[quote author="jedd" date="1256769645"]
Those two arrays would be enough to create the view I described. Would that approach kind of get you where you want to go?[/quote]
If I understand correctly, yes. I agree with you, and I really don't like to idea of having the ids on the URL, but I REALLY like the idea of having the name paths on the URL, instead of a solo ID, or something else.
But, as stated, the main point now is to make this to work, and for that,
I just need to correctly build the URL path for the anchors, and later on I would take care of the ugly parts and other details as well, like current item selection etc...
Can I have your guidance in order to change the URL path to be the correct one on the child elements?
Regards,
Márcio
