On Nov 14, 9:24 pm, "Peter J. Farrell" <[email protected]> wrote: > A lot of questions which I will be happy to answer... If I miss any, > summarize them as bullets next time if possible ;-)
Thanks Peter I really appreciate you taking the time. > > Brian H. said the following on 11/14/2010 03:49 PM:> Ok thanks for the reply > Peter. I would still assume that this would be > > "possible" in M2 with a change to the URL parsing routines, but > > possibly not a priority item enough to do so (unless I am > > misunderstanding the underlining structural problem). > > Actually it would be rather problematic to switch. Currently we use the > first element in the /slash/structure as a "list" perform a lookup in > the following order: > > * endpoint name > * route name > * event name (if you have urlParameterEnabled=false set) > * event parameter value > > If the slash becomes a valid character in the route name, everything > would need to be matched by RegEx. This would be slow in CFML and a big > performance bottle neck -- looping over regexes definitely doesn't scale > as well of structkeyexists. I'd be opposed to switching to regex not to > mention it allows for a lot more ambiguous URL cases. Understood! I'll work around this. > > > Question. This application is private and NOT being indexed by any > > search engine, so I am looking to employ routes across every page of > > this application simply because I think that it provides a cleaner URL > > for the user. Would you typically only use routes on those URLs are > > that sensitive to indexing or, on route enabled applications, would > > you go all out and make every event (even those only accessed by site > > admins) routed? > > Routes are human readable positional URLs. It really depends. Take for > instance this URI: > > /bamboo-flooring-installation-photos/489/Maria-Pinto-Boutique-Chicago-IL/ > > The only key piece is 489 (the id) whereas the name and location is for > Google is "thrown" away by the application (purely SEO). It's > definitely easy to see what you are getting than: > > /en.bamboo.installation/id/489/ > > or > > ?event=en.bamboo.install&id=489 > > We did similar URL rewriting for images associated to these installs: > > /img/bamboo/installs/Solid-Bamboo-Flooring-Maria-Pinto-Boutique-Chicago-IL_071_2_l.jpg?1272492154 > > The only key piece there is "071_2_l.jpg" everything else is either SEO > or for caching reasons. This was really enlightening. I've always assumed that if I was using keywords/product names in the URL that I would be using those strings as keys, but what you are suggesting is use those urls mostly for keyword indexing by serach engine, still include an ID somewhere in the URL and just disregard the rest of the URL (pulling only the id from the url). Can I ask why you didn't just throw the ID at the END of the url (you put it in the middle in both cases)? It would seem more logical for the ID at the end: domain.com/some-keywords/some- more-keywords/12345. > > > I ask because the inability to use persistence on > > routed URLs is going to be troublesome. I know that M2 currently > > can't, but is that not something that can be developed at some point? > > I looked at this last Friday and works on some code (t:245) for 1.9. I > just haven't had a chance to test properly and check it in. > > http://trac.mach-ii.com/machii/ticket/246 > > I added you as a CC so you can stay updated on the status. Look for it > in the nightly in the next day or so> Finally, I haven't been able to dig up > any docs for this "cookie" > > method of event persistence. Do you have a link handy? > > http://trac.mach-ii.com/machii/wiki/URLManagementFeatures#PropertiesT... > > The property is redirectPersistLocation.> Are there any disadvantages to this > approach? > > It does keep URLs clean although you are limited to one cooke at a time > per session so multiple AJAX request that us persist (can't think of why > you would do that) would be out of the question. The cookie is clear on > the 2nd request of the post post redirect get (PRG) routine.> What if the > user had multiple browser > > windows open (sharing a login session) and accessed the same feature > > on the site? > > Wouldn't matter unless they submitted the requests at the same time.> Would > using cookies to store the persistID create a > > conflict? > > They are temporary because subject to race conditions with multiple > requests from the same browser. Ok thanks for the info! Excellent I am glad to see this making it's way into a milestone. I think that this is the right move. The old routes will still work (/view-products/), but in those rare cases when we need a redirection, we can still rely on the same URL structure. I like. -Brian -- You received this message because you are subscribed to Mach-II for CFML list. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mach-ii-for-coldfusion?hl=en SVN: http://svn.mach-ii.com/machii/ Wiki / Documentation / Tickets: http://trac.mach-ii.com/machii/
