Re: Changes to tag and rest controllers
Chad Kieffer <[email protected]> Wed, 15 May 2013 20:29:50 -0600
| Newsgroups | gmane.comp.web.gallery.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============1281395597608087033== Content-Type: multipart/alternative; boundary=Apple-Mail-7--477832765 --Apple-Mail-7--477832765 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think floridave uses the tag cloud in a module or theme. On May 15, 2013, at 7:01 PM, Bharat Mediratta wrote: >=20 > Both of these approaches sound good and right to me. The REST = approach was not well thought out initially and is due for a refactor. = The tag/<id>/<name> approach was essentially a fix because originally we = did tag/<name> but that was causing problems when we tried to map a = slugified tag name in the url back into a tag in the database. Using = the id made it easy to find the actual tag. Using a real slug would be = much better. >=20 >=20 > On Wed, May 15, 2013 at 9:28 AM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote: > Hey everyone, >=20 > I think that most of the heavy lifting with the big Forge->Formo = conversion is done! There are still a couple minor things to iron out, = but it's getting close :-). >=20 > During the process, I noticed two other things I'd like to revamp for = 3.1... > - tag controller and routing (make it more like items) > - rest controller and resource files (make them more like admin = controllers) >=20 > I have a couple long plane rides coming up, and unless anyone protests = I was thinking I might start to delve into these... >=20 > REST: >=20 > Looking through the rest code, it seems like a more K3-savvy approach = would be to build a base Controller_Rest class, then have each resource = make its own *controller* (not helper or hook) to extend it. I haven't = delved into this too deeply just yet, but it'd probably look something = like this: > - main controller (Controller_Rest): 2 full actions (reset_api_key, = index for login), 4 empty actions which the controllers would extend = (get, put, post, delete), before and after functions. > - a resource (e.g. Controller_Rest_Data): 1-4 actions that replace the = empty ones, non-action callbacks for relationships, resolve, and url. >=20 > I think that this can largely simplify the rest code (which curently = uses their own, special request and resource objects) while leaving the = external API essentially identical. So, all the slick apps written = around it (sidenote: Xotof is awesome) wouldn't need any changes. >=20 > TAG: >=20 > Right now, we have five routes: > - tags/add/<item_id> > Add tag to item. This should stay as-is. > - tags/autocomplete?term=3D<term> > Do the autocomplete. This should also stay as-is. > - tags > Return a tag cloud. Is this route still used anywhere? > - tag/<tag_id>(/<tag_name>) > Show the items for a tag. This is currently the canonical URL for a = tag, and the tag_name is purely decorative. > - tag_name/<tag_name> > Find a tag by its name, then redirect it to its canonical URL. >=20 > It's mainly the last two I'd like to change. Here's what I'd like it = to be: > - tag > Show the tags as albums, similar to the tag_albums module > - tag/<tag_slug> > Show the items for a tag. This is the new canonical URL for a tag. >=20 > Obviously, this requires a bit of work. The first phase is to change = the canonical URL, add a slug field to the tag model, allow the slugs to = be edited (only in the admin menu - not needed in the main "add" = interface), and ensure we can (mostly) redirect the old URLs. This is = the part I'd like to bite off sooner than later. >=20 > Then, in a separate project, we can get the "tag" route going. = Really, this phase is all about adding things like album cover ids, sort = orders, etc. to each tag. This part is probably best tackled after = revisiting the "pagination" code that shows collections (currently = written up independently for albums, tags, and search... should be = unified in View_Gallery or View_Theme). >=20 > Thoughts? >=20 > Take care, > Shad >=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 > = --------------------------------------------------------------------------= ---- > 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 ] --Apple-Mail-7--477832765 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii <html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I think floridave uses the tag cloud in a module or theme.<div><br><div><div>On May 15, 2013, at 7:01 PM, Bharat Mediratta wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><br><div>Both of these approaches sound good and right to me. The REST approach was not well thought out initially and is due for a refactor. The tag/<id>/<name> approach was essentially a fix because originally we did tag/<name> but that was causing problems when we tried to map a slugified tag name in the url back into a tag in the database. Using the id made it easy to find the actual tag. Using a real slug would be m uch better.</div> </div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 15, 2013 at 9:28 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">Hey everyone,<div><br></div><div>I think that most of the heavy lifting with the big Forge->Formo conversion is done! There are still a couple minor things to iron out, but it's getting close :-).</div> <div><br></div><div>During the process, I noticed two other things I'd like to revamp for 3.1...</div><div>- tag controller and routing (make it more like items)<br></div><div>- rest controller and resource files (make them more like admin controllers)</div> <div><br></div><div>I have a couple long plane rides coming up, and unless anyone protests I was thinking I might start to delve into these...</div><div><br></div><div>REST:</div><div><br></div><div> Looking through the rest code, it seems like a more K3-savvy approach would be to build a base Controller_Rest class, then have each resource make its own *controller* (not helper or hook) to extend it. I haven't delved into this too deeply just yet, but it'd probably look something like this:</div> <div>- main controller (Controller_Rest): 2 full actions (reset_api_key, index for login), 4 empty actions which the controllers would extend (get, put, post, delete), before and after functions.</div><div>- a resource (e.g. Controller_Rest_Data): 1-4 actions that replace the empty ones, non-action callbacks for relationships, resolve, and url.</div> <div><br></div><div>I think that this can largely simplify the rest code (which curently uses their own, special request and resource objects) while leaving the external API essentially identical. So, all the slick apps written around it (sidenote: Xotof is awesome) wouldn't need any changes.</div> <div><br></div><div>TAG:</div><div><br></div><div>Right now, we have five routes:</div><div>- tags/add/<item_id></div><div>Add tag to item. This should stay as-is.</div><div> - tags/autocomplete?term=<term></div><div>Do the autocomplete. This should also stay as-is.</div><div>- tags</div><div>Return a tag cloud. Is this route still used anywhere?</div><div>- tag/<tag_id>(/<tag_name>)</div> <div>Show the items for a tag. This is currently the canonical URL for a tag, and the tag_name is purely decorative.</div><div>- tag_name/<tag_name></div><div>Find a tag by its name, then redirect it to its canonical URL.</div> <div><br></div><div>It's mainly the last two I'd like to change. Here's what I'd like it to be:</div><div>- tag</div><div>Show the tags as albums, similar to the tag_albums module</div> <div>- tag/<tag_slug></div><div>Show the items for a tag. This is the new canonical URL for a tag.</div><div><br></div><div>Obviously, this requires a bit of work. The first phase is to change the canonical URL, add a slug field to the tag model, allow the slugs to be edited (only in the admin menu - not needed in the main "add" interface), and ensure we can (mostly) redirect the old URLs. This is the part I'd like to bite off sooner than later.</div> <div><br></div><div>Then, in a separate project, we can get the "tag" route going. Really, this phase is all about adding things like album cover ids, sort orders, etc. to each tag. This part is probably best tackled after revisiting the "pagination" code that shows collections (currently written up independently for albums, tags, and search... should be unified in View_Gallery or View_Theme).</div> <div><br></div><div>Thoughts?</div><div><br></div><div>Take care,<br></div><div>Shad</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></blockquote></div><br></div> ------------------------------------------------------------------------------<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__[">http://p.sf.net/sfu/alienvault_d2d__[</a> 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">http://gallery.sf.net/lists.php</a> ]<br>[ gallery info/FAQ/download --> <a href="http://gallery.sf.net">http://gallery.sf.net</a> ]</blockquote></div><br></div></body></html> --Apple-Mail-7--477832765-- --===============1281395597608087033== 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 --===============1281395597608087033== 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 ] --===============1281395597608087033==--