Re: Changes to tag and rest controllers
Chad Kieffer <[email protected]> Fri, 17 May 2013 12:03:28 -0600
| Newsgroups | gmane.comp.web.gallery.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============0640016772330840281== Content-Type: multipart/alternative; boundary=Apple-Mail-905C52E2-13F7-4ECF-9A4B-9342434DEE43 Content-Transfer-Encoding: 7bit --Apple-Mail-905C52E2-13F7-4ECF-9A4B-9342434DEE43 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Should routes reflect hierarchy? On May 17, 2013, at 10:39 AM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote: > Hmm... good question. >=20 > My first inclination isn't to make a hierarchy, but rather an extra cross-= reference. For example, "gallery/tag/me/you" would find photos tagged with b= oth me and you. Thoughts? >=20 > Take care, > Shad >=20 >=20 > On 17 May 2013 17:56, Chad Kieffer <[email protected]> wrote: >> Although tags are strictly flat now, how might hierarchical structures be= routed in the future? I think even if support for taxonomies isn't part of G= 3 now, it might be worth considering as part of this discussion. >>=20 >> - Chad >>=20 >> On May 17, 2013, at 9:15 AM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote: >>=20 >>> Hmm... I'm not sure I agree. For example, this would make folks with ph= otos about 90210, 356, and 1776 really annoyed at the new system. The simpl= est rule is the one we don't need :-) >>>=20 >>> My preference is this: >>> - make the new system simple, flexible, and exactly what we want. >>> - provide enough redirects for old URLs to keep most old sites happy dur= ing the conversion. >>>=20 >>> Thinking again, there's actually a better rule we can use to deal with o= ld redirects: >>> gallery30x/tag/123/321 --> tag id 123 (which coincidentally has name 321= , but this isn't checked) - old canonical URL >>> gallery31x/tag/123/321 --> tag id 123, name 321 (sees slash and tries th= is), then 301 redirect. >>> gallery31x/tag/123 --> tag name 123, or if none exists, look for a tag i= d 123 and 301 redirect. >>> gallery31x/tag/321 --> tag name 321 (which coincidentally has id 123, bu= t this isn't checked) - new canonical URL >>>=20 >>> The only oddball case here is old URLs that were truncated *and* coincid= e with new URLs, for which I don't think we should break our new system to s= upport... >>>=20 >>> Take care, >>> Shad >>>=20 >>>=20 >>>=20 >>> On 17 May 2013 17:06, Bharat Mediratta <[email protected]> wrote: >>>>=20 >>>> I'd prefer to have a simpler rule of "no numeric tag slugs" because tha= t way we'll have consistent behavior in all cases. I like simple rules :-) >>>>=20 >>>>=20 >>>> On Fri, May 17, 2013 at 7:55 AM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote: >>>>> Yah, that's easy enough to keep. Just as you said, the only slight wr= inkle is numeric tag names, but even then we don't need to *enforce* that sl= ugs are non-numeric. Rather, we just can't forward old URLs that coincide w= ith new URLs of numeric tags. >>>>>=20 >>>>> For example: >>>>> gallery30x/tag/123 --> tag id 123. >>>>> gallery31x/tag/123 --> tag name 123, or if none exists, look for a tag= id 123 and 301 redirect. >>>>>=20 >>>>> Take care, >>>>> Shad >>>>>=20 >>>>>=20 >>>>> On 17 May 2013 16:42, Bharat Mediratta <[email protected]> wrote: >>>>>>=20 >>>>>> Keeping around support for tag/<id> shouldn't be too hard, right? It= just means that the user-defined slug can't be purely numeric to avoid conf= licts. >>>>>>=20 >>>>>>=20 >>>>>> On Fri, May 17, 2013 at 6:34 AM, Dave Moore <[email protected]> wro= te: >>>>>>> On 2013-05-15 8:29 PM, Bharat wrote: >>>>>>> > The tag/<id>/<name> approach was essentially a fix because origin= ally >>>>>>> > we did tag/<name> but that was causing problems when we tried to m= ap a >>>>>>> > slugified tag name in the url back into a tag in the database. >>>>>>> That has been some concern for me and for others as well. I would b= e >>>>>>> nice if we could get to: /tag/<name> without the <id> in the url. I= f >>>>>>> that could be sorted out then that would make some/lots users/me hap= py. >>>>>>> I don't know about backwards compatibility with tag/<id>/<name> is >>>>>>> required or not. I guess it depends on the amount of work required. = I >>>>>>> guess it would be good or if some workaround in the .htaccess could b= e >>>>>>> provided as a fix, that would work as well. >>>>>>>=20 >>>>>>> Dave >>>>>>>=20 >>>>>>> --------------------------------------------------------------------= ---------- >>>>>>> AlienVault Unified Security Management (USM) platform delivers compl= ete >>>>>>> security visibility with the essential security capabilities. Easily= and >>>>>>> efficiently configure, manage, and operate all of your security cont= rols >>>>>>> from a single console and one unified framework. Download a free tri= al. >>>>>>> http://p.sf.net/sfu/alienvault_d2d >>>>>>> __[ g a l l e r y - d e v e l ]_________________________ >>>>>>>=20 >>>>>>> [ list info/archive --> http://gallery.sf.net/lists.php ] >>>>>>> [ gallery info/FAQ/download --> http://gallery.sf.net ] >>>>>>=20 >>>>>>=20 >>>>>> ---------------------------------------------------------------------= --------- >>>>>> AlienVault Unified Security Management (USM) platform delivers comple= te >>>>>> security visibility with the essential security capabilities. Easily a= nd >>>>>> efficiently configure, manage, and operate all of your security contr= ols >>>>>> from a single console and one unified framework. Download a free tria= l. >>>>>> http://p.sf.net/sfu/alienvault_d2d >>>>>> __[ g a l l e r y - d e v e l ]_________________________ >>>>>>=20 >>>>>> [ list info/archive --> http://gallery.sf.net/lists.php ] >>>>>> [ gallery info/FAQ/download --> http://gallery.sf.net ] >>>=20 >>> ------------------------------------------------------------------------= ------ >>> AlienVault Unified Security Management (USM) platform delivers complete >>> security visibility with the essential security capabilities. Easily and= >>> efficiently configure, manage, and operate all of your security controls= >>> from a single console and one unified framework. Download a free trial. >>> http://p.sf.net/sfu/alienvault_d2d >>> __[ g a l l e r y - d e v e l ]_________________________ >>>=20 >>> [ list info/archive --> http://gallery.sf.net/lists.php ] >>> [ gallery info/FAQ/download --> http://gallery.sf.net ] >=20 --Apple-Mail-905C52E2-13F7-4ECF-9A4B-9342434DEE43 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Should routes reflect hierarchy?</div><div><br>On May 17, 2013, at 10:39 AM, Shad Laws <<a href="mailto:shad-xpYdmXCiSuZWk0Htik3J/[email protected]">shad-xpYdmXCiSuZWk0Htik3J/[email protected]</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Hmm... good question.<div><br></div><div>My first inclination isn't to make a hierarchy, but rather an extra cross-reference. For example, "gallery/tag/me/you" would find photos tagged with both me and you. Thoughts?<div> <br></div><div>Take care,</div><div>Shad</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 17 May 2013 17:56, Chad Kieffer <span dir="ltr"><<a href="mailto:[email protected]" target="_blank">[email protected]</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Although tags are strictly flat now, how might hierarchical structures be routed in the future? I think even if support for taxonomies isn't part of G3 now, it might be worth considering as part of this discussion.</div> <div><br></div><div>- Chad</div><div><br>On May 17, 2013, at 9:15 AM, Shad Laws <<a href="mailto:shad-xpYdmXCiSuZWk0Htik3J/[email protected]" target="_blank">shad-xpYdmXCiSuZWk0Htik3J/[email protected]</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"> Hmm... I'm not sure I agree. For example, this would make folks with photos about 90210, 356, and 1776 really annoyed at the new system. The simplest rule is the one we don't need :-)<div><br></div> <div>My preference is this:</div><div>- make the new system simple, flexible, and exactly what we want.</div><div>- provide enough redirects for old URLs to keep most old sites happy during the conversion.</div> <div><br></div><div>Thinking again, there's actually a better rule we can use to deal with old redirects:</div><div><div style="font-family:arial,sans-serif;font-size:13px">gallery30x/tag/123/321 --> tag id 123 (which coincidentally has name 321, but this isn't checked) - old canonical URL</div> <div style="font-size:13px;font-family:arial,sans-serif">gallery31x/tag/123/321 --> tag id 123, name 321 (sees slash and tries this), then 301 redirect.</div><div style="font-family:arial,sans-serif;font-size:13px">gallery31x/tag/123 --> tag name 123, or if none exists, look for a tag id 123 and 301 redirect.</div> <div style="font-family:arial,sans-serif;font-size:13px">gallery31x/tag/321 --> tag name 321 (which coincidentally has id 123, but this isn't checked) - new canonical URL</div><div style="font-family:arial,sans-serif;font-size:13px"> <br></div><div style="font-family:arial,sans-serif;font-size:13px">The only oddball case here is old URLs that were truncated *and* coincide with new URLs, for which I don't think we should break our new system to support...</div> <div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Take care,</div><div style="font-family:arial,sans-serif;font-size:13px">Shad</div><div style="font-family:arial,sans-serif;font-size:13px"> <br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 17 May 2013 17:06, Bharat Mediratta <span dir="ltr"><<a href="mailto:[email protected]" target="_blank">[email protected]</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div>I'd prefer to have a simpler rule of "no numeric tag slugs" because that way we'll have consistent behavior in all cases. I like simple rules :-)</div> </div><div class="gmail_extra"> <br><br><div class="gmail_quote">On Fri, May 17, 2013 at 7:55 AM, Shad Laws <span dir="ltr"><<a href="mailto:shad-xpYdmXCiSuZWk0Htik3J/[email protected]" target="_blank">shad-xpYdmXCiSuZWk0Htik3J/[email protected]</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr">Yah, that's easy enough to keep. Just as you said, the only slight wrinkle is numeric tag names, but even then we don't need to *enforce* that slugs are non-numeric. Rather, we just can't forward old URLs that coincide with new URLs of numeric tags.<div> <br></div><div>For example:</div><div>gallery30x/tag/123 --> tag id 123.</div><div>gallery31x/tag/123 --> tag name 123, or if none exists, look for a tag id 123 and 301 redirect.</div><div><br></div> <div>Take care,</div><div>Shad</div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On 17 May 2013 16:42, Bharat Mediratta <span dir="ltr"><<a href="mailto:[email protected]" target="_blank">[email protected]</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div>Keeping around support for tag/<id> shouldn't be too hard, right? It just means that the user-defined slug can't be purely numeric to avoid conflicts.</div> </div><div class="gmail_extra"> <br><br><div class="gmail_quote">On Fri, May 17, 2013 at 6:34 AM, Dave Moore <span dir="ltr"><<a href="mailto:[email protected]" target="_blank">[email protected]</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div>On 2013-05-15 8:29 PM, Bharat wrote:<br> > The tag/<id>/<name> approach was essentially a fix because originally<br> > we did tag/<name> but that was causing problems when we tried to map a<br> > slugified tag name in the url back into a tag in the database.<br> </div>That has been some concern for me and for others as well. I would be<br> nice if we could get to: /tag/<name> without the <id> in the url. If<br> that could be sorted out then that would make some/lots users/me happy.<br> I don't know about backwards compatibility with tag/<id>/<name> is<br> required or not. I guess it depends on the amount of work required. I<br> guess it would be good or if some workaround in the .htaccess could be<br> provided as a fix, that would work as well.<br> <span><font color="#888888"><br> Dave<br> </font></span><div><div><br> ------------------------------------------------------------------------------<br> AlienVault Unified Security Management (USM) platform delivers complete<br> security visibility with the essential security capabilities. Easily and<br> efficiently configure, manage, and operate all of your security controls<br> from a single console and one unified framework. Download a free trial.<br> <a href="http://p.sf.net/sfu/alienvault_d2d" target="_blank">http://p.sf.net/sfu/alienvault_d2d</a><br> __[ g a l l e r y - d e v e l ]_________________________<br> <br> [ list info/archive --> <a href="http://gallery.sf.net/lists.php" target="_blank">http://gallery.sf.net/lists.php</a> ]<br> [ gallery info/FAQ/download --> <a href="http://gallery.sf.net" target="_blank">http://gallery.sf.net</a> ]<br> <br> </div></div></blockquote></div><br></div> <br>------------------------------------------------------------------------------<br> AlienVault Unified Security Management (USM) platform delivers complete<br> security visibility with the essential security capabilities. Easily and<br> efficiently configure, manage, and operate all of your security controls<br> from a single console and one unified framework. Download a free trial.<br> <a href="http://p.sf.net/sfu/alienvault_d2d" target="_blank">http://p.sf.net/sfu/alienvault_d2d</a><br>__[ g a l l e r y - d e v e l ]_________________________<br> <br> [ list info/archive --> <a href="http://gallery.sf.net/lists.php" target="_blank">http://gallery.sf.net/lists.php</a> ]<br> [ gallery info/FAQ/download --> <a href="http://gallery.sf.net" target="_blank">http://gallery.sf.net</a> ]<br></blockquote></div><br></div> </div></div></blockquote></div><br></div> </blockquote></div><br></div> </div></blockquote><blockquote type="cite"><div><span>------------------------------------------------------------------------------</span><br><span>AlienVault Unified Security Management (USM) platform delivers complete</span><br> <span>security visibility with the essential security capabilities. Easily and</span><br><span>efficiently configure, manage, and operate all of your security controls</span><br><span>from a single console and one unified framework. Download a free trial.</span><br> <span><a href="http://p.sf.net/sfu/alienvault_d2d" target="_blank">http://p.sf.net/sfu/alienvault_d2d</a></span></div></blockquote><blockquote type="cite"><div><span>__[ g a l l e r y - d e v e l ]_________________________</span><br> <span></span><br><span>[ list info/archive --> <a href="http://gallery.sf.net/lists.php" target="_blank">http://gallery.sf.net/lists.php</a> ]</span><br><span>[ gallery info/FAQ/download --> <a href="http://gallery.sf.net" target="_blank">http://gallery.sf.net</a> ]</span></div> </blockquote></div></blockquote></div><br></div> </div></blockquote></body></html> --Apple-Mail-905C52E2-13F7-4ECF-9A4B-9342434DEE43-- --===============0640016772330840281== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d --===============0640016772330840281== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline __[ g a l l e r y - d e v e l ]_________________________ [ list info/archive --> http://gallery.sf.net/lists.php ] [ gallery info/FAQ/download --> http://gallery.sf.net ] --===============0640016772330840281==--