| Super Ultra Mega Dynamic Menu Post - all gurus and no gurus invited |
[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
[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.
[eluser]MEM[/eluser]
[quote author="jedd" date="1256792396"] In practice you say you're going to have three levels, and only three levels (...) 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. [/quote] To put it on another perspective: In practice and theory I will need an unlimited level scale. Then, on the backend administration, I may consider ways to limit this menu usage,on some levels, . [quote author="jedd" date="1256792396"] 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. [/quote] I see... explode from /, implode, with / and follow that root... ? Right now, I've been introduced to stack methods by using array_push and array_pop I will see where this takes me as well... [quote author="jedd" date="1256792396"] 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] And I still believe is tempting, with means, it makes sense to me. [quote author="jedd" date="1256792396"] Can you fork here - are you using a CVS? [/quote] No. What I'm using is a fabulous "save as..." with some prefix. But the problem with this "method" is that I can't keep track of different separate files at once, so I believe I REALLY need to change my methodology. [quote author="jedd" date="1256792396"] if not I recommend git [/quote] I'm on micro$oft. And I really need a big introduction on how control versions work... [quote author="jedd" date="1256792396"] When I talk about preserving the parentage, I don't mean in the URL - I just mean on-screen, within the browser window proper. [/quote] Yes. [quote author="jedd" date="1256792396"] 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 believe they need to be more semantic (Tim Lee is clapping now), so yes they need words. But still, be consistent over time. How? No idea. But I believe this is the path to follow. I agree with the long. [quote author="jedd" date="1256792396"] 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. [/quote] I totally agree. [quote author="jedd" date="1256792396"] My final comment - on using names rather than ID's - in your URL. I think this would be bad, for a number of reasons. [/quote] Ok... [quote author="jedd" date="1256792396"] First, long URLs are painful, especially once they breach 72 characters. [/quote] I've found nothing specific about 72 characters, but thanks to your comment I've found: http://www.w3.org/QA/Tips/uri-choose http://www.w3.org/Provider/Style/URI http://www.w3.org/TR/chips/#uri I've learn new things. For anyone else, including myself when I forget, here's a resume: Make your efforts to create: Short, Persistent, Semantic Relevant - URIs. [quote author="jedd" date="1256792396"] 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). [/quote] Partially agree. As stated, the optimal should be to have semantic names on the URI that persists (ideally) forever. Herbicidas is one of those names. Of course the category name could change one day, but at the limit, a comet could arrive to earth, and deal with this internet think at once, so, I would never say forever, but, ideally forever. [quote author="jedd" date="1256792396"] 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. [/quote] The same as ID. We could have 1024 or 1 024. What you are saying is valid, but not an argument against words. Words can have pontuation, accentuation, unite language chars... such as ç. They could, they tend, but it's easy to not allow that on uris. If you do not allow that on the URI the word possibilities are not an issue. [quote author="jedd" date="1256792396"] 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. [/quote] Single names no. But a path of names yes. www.mysite.com/categories/car/ www.mysite.com/products/car/ A short path of names however. :-) The worst URI we can have? A long id uri. And that's what I'm getting if I follow the path I'm in. So I really need to change this path. I'm just not yet sure, If I change on this project or on the next project. If you have nothing against, let's go back to the menu main question on the next thread...
[eluser]MEM[/eluser]
Right now, Codeginiter framework, as lead me to the following URI: http://www.nuvemk.com/c_categoria/seccao/1 Where seccao, is a method name, on my c_categoria controller. The intended URI for that page would be: http://www.nuvemk.com/solucoes/agricultura Is there an easy way to archive this? If the user then decides to navigate deeply into agricultura, let's say, into Fitofarmacos: The ideal URL would be: http://www.nuvemk.com/solucoes/fitofarmacos If the user decides to go even further, into fitofarmacos child, "Herbicidas", then the ideal URL would be: http://www.nuvemk.com/solucoes/herbicidas Visually, however, and I believe that's your point Jedd, we can keep track of some sort of path, but that path doesn't need to be expressed on the URL. Only on the viewport. If something like this IS NOT EASILY possible with CodeIgniter, and if we MUST have the first segment to our controller, and the third segment to be our method inside the controller, then, the best possible URL we can get is: http://www.nuvemk.com/c_categorias/seccao/fitofarmacos http://www.nuvemk.com/c_categorias/seccao/herbicidas etc... 1) Is it possible to easily shorten this, or this is the short we can get? [UPDATE:] It is possible. http://ellislab.com/codeigniter/user-guide/general/routing.html If I understand correctly: We can say: when this address is given: http://www.nuvemk.com/agricultura Call: c_categorias/seccao/1/ This will be done on the routes.php system file. But this will be hard coded. What if, in the future, the website administrator adds a new category? Should I hard code the routes.php file again, and add that new rule? I believe not, so something must be escaping me... [/UPDATE] [UPDATE II:] I've now found that something like this on the router should do the trick: Code: $route['solucoes/(:any)'] = "c_categoria/seccao/$1";I know $1 refers to the first () on a regex expression. $2 to the second () on a regex expression... But my second doubt still applies, and the solution of that doubt could the change the answer to this first one as well. [UPDATE II:] 2) 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? From the solo URI segment we have? 2.1.1) I'd like to work with names on the URL, but work with IDs on the database retrieving, where could we make the corresponded switch? Supposing this is the short URL we can get to access herbicidas: http://www.nuvemk.com/c_categorias/seccao/herbicidas That will have a corresponded id. Where should we grab that ID, and pass that id to the query on my model? (I hope it's clear, if not, please, I can remake this last question). Regards, Márcio
[eluser]jedd[/eluser]
I shall return to the rest of this subject soon, but here's a software versioning aside, based on what you said above. Read this story - the [url="http://tom.preston-werner.com/2009/05/19/the-git-parable.html"]git parable[/url] - it's aimed at git, but it's ultimately applicable to almost any code versioning software. It'll take you 10-15 minutes to read, but if you've not used a cvs before, you definitely should spend that time reading it first. Read [url="http://spheredev.org/wiki/Git_for_the_lazy"]Git for the lazy[/url] - an excellent overview. Handy reference, too. Read [url="http://www.kernel.org/pub/software/scm/git/docs/everyday.html"]Everyday git - 20 commands you'll often use[/url] - similarly good overview and handy reference. Both those will give you a bit of a tutorial, bit of an overview, without going into too much depth. I'd suggest you allocate a few hours to - download git, install it, experiment with it using the stuff in those last two URL's, and see if if clicks. I think that once you use a versioning tool, you'll a) wonder how you ever lived with out it, and b) you'll never work without one again. Given they are free, very lightweight, and don't ever get in your way (you're still allowed to zip up everything you've got if want and stick it in an archive somewhere), there's no real downside to using one. Note that other people will recommend svn (subversion). SVN is what I used to use, and I certainly liked it at the time. It gets a lot of bad press, especially from Linus Torvalds (who happened to write git  but I think for a new-to-cvs-tools person, git will make more sense and will simply be easier to set up.Finally, you can read through the definitive git guide - an online book called [url="http://progit.org/book/ch6-5.html"]Pro git[/url] - but it's heavier going, and is obviously much larger. Good to bookmark, though.
[eluser]MEM[/eluser]
Thanks a lot, I will absolutely give a look, and add those links to my bookmarks.
[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? 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.
[eluser]MEM[/eluser]
[quote author="jedd" date="1257008108"] 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. [/quote] I still believe w3c as big point for wanting semantic URI segments. However, I do realise that, according to my knowledge, doing all properly: ie: w3c friendly AND provide a good performance, I need to give myself some experience first. Let's go for the id's then, and stick to them, without changing the URI to any names. (for now) :p [quote author="jedd" date="1257008108"] 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. [/quote] Of course! I was wondering, should I always need to have that controller method name on the URI? Or, the only way I have to remove that controller method from the URI is by routing? No. We can always do that on the constructor. [quote author="jedd" date="1257008108"] 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. [/quote] Nice limit to have at sight then. [quote author="jedd" date="1257008108"]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] I was unable to understand what do you mean here. I'm not that fluent on English. Are you saying to: forget about routing on this case? Can you please, re-state? (sorry  )I will now try to create a work-flow process for this. And see what I get. My main difficulties will be with the retrieving of all parents and childs from a given id models. Let's see... Regards, Márcio
[eluser]jedd[/eluser]
Of course. Earlier on you said you were worried about ROUTE changes, because you would have to hard-code things. This meant that if any new things were added - by a user perhaps - you would have to hard-code NEW routes in to handle them. I suggest that you invert this problem. Rather than route a bunch of things that you list, you instead route everything that is NOT in a list. As I say, this is only helpful if you think that in the future, the kinds of changes that will occur are more likely to be things that you want to automatically route by default. I expect that there will always be times when you need to visit your source and make hard-coded changes to the way things work. Does that make more sense? I think the key here is just reversing or inverting your routing condition - exclude from one set, rather than include from a different set.
[eluser]MEM[/eluser]
[quote author="jedd" date="1257019957"]Of course. Earlier on you said you were worried about ROUTE changes, because you would have to hard-code things. This meant that if any new things were added - by a user perhaps - you would have to hard-code NEW routes in to handle them. [/quote] I was wondering if, for example,the admin user of this site adds a new category to the database I don't want to hard code the possible route changing associated to that new category. I believe however, that my update II on the previous post, have clear this doubt. By having placeholders that expect not a specific number like 1, 2, or 10, but any number, by using :num. Or any character, by using: :any. [quote author="jedd" date="1257019957"] I suggest that you invert this problem. Rather than route a bunch of things that you list, you instead route everything that is NOT in a list. As I say, this is only helpful if you think that in the future, the kinds of changes that will occur are more likely to be things that you want to automatically route by default. I expect that there will always be times when you need to visit your source and make hard-coded changes to the way things work. [/quote] O.o [quote author="jedd" date="1257019957"] Does that make more sense? [/quote] I will grab some chocolate... Oh... nice birds... do you hear them? Whistling out... Ok. No.  Anyway, give me some hours to organize the ideas. Side note: The last 20 hours I was playing and reading about Git. It's really nice and fast! I've installed egit (for enclipse) as an Aptana Plugin. Also, because I like the command line style, I've added cygwin with git inside as well. Once on the cygwin, I navigate to my project directory, and I do some commit, and then I create a branch, and then I change from branch to branch. And wow! that's fast. So, in this case for example, I need to change files on the model, and on the controller, and on the view... instead of always create versions of each of those files, I just create a branch based on my working branch, and I call it: testmenu. If something goes wrong on my testmenu branch... well... I will return to my working branch. I realise this is, still, a very limited use of git, but it's a start. Thanks a lot jedd. here are other references that I found: http://book.git-scm.com/ For Aptana (or other eclipse related users), after install the plugin, just follow the steps here: http://wiki.eclipse.org/EGit/User_Guide Regards, Márcio |
| Welcome Guest, Not a member yet? Register Sign In |
