Changes to tag and rest controllers

--===============5977795429904688983==
Content-Type: multipart/alternative; boundary=f46d04430642bacdee04dcc43e2f

--f46d04430642bacdee04dcc43e2f
Content-Type: text/plain; charset=UTF-8

Hey everyone,

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 :-).

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)

I have a couple long plane rides coming up, and unless anyone protests I
was thinking I might start to delve into these...

REST:

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.

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.

TAG:

Right now, we have five routes:
- tags/add/<item_id>
Add tag to item.  This should stay as-is.
- tags/autocomplete?term=<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.

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.

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.

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).

Thoughts?

Take care,
Shad

--f46d04430642bacdee04dcc43e2f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hey everyone,<div><br></div><div style>I think that most o=
f the heavy lifting with the big Forge-&gt;Formo conversion is done! =C2=A0=
There are still a couple minor things to iron out, but it&#39;s getting clo=
se :-).</div>

<div style><br></div><div style>During the process, I noticed two other thi=
ngs I&#39;d like to revamp for 3.1...</div><div style>- tag controller and =
routing (make it more like items)<br></div><div style>- rest controller and=
 resource files (make them more like admin controllers)</div>

<div style><br></div><div>I have a couple long plane rides coming up, and u=
nless anyone protests I was thinking I might start to delve into these...</=
div><div style><br></div><div style>REST:</div><div style><br></div><div st=
yle>

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. =C2=A0I haven&#39;t de=
lved into this too deeply just yet, but it&#39;d probably look something li=
ke this:</div>

<div style>- main controller (Controller_Rest): 2 full actions (reset_api_k=
ey, index for login), 4 empty actions which the controllers would extend (g=
et, put, post, delete), before and after functions.</div><div style>- a res=
ource (e.g. Controller_Rest_Data): 1-4 actions that replace the empty ones,=
 non-action callbacks for relationships, resolve, and url.</div>

<div style><br></div><div style>I think that this can largely simplify the =
rest code (which curently uses their own, special request and resource obje=
cts) while leaving the external API essentially identical. =C2=A0So, all th=
e slick apps written around it (sidenote: Xotof is awesome) wouldn&#39;t ne=
ed any changes.</div>

<div style><br></div><div style>TAG:</div><div style><br></div><div style>R=
ight now, we have five routes:</div><div style>- tags/add/&lt;item_id&gt;</=
div><div style>Add tag to item. =C2=A0This should stay as-is.</div><div sty=
le>

- tags/autocomplete?term=3D&lt;term&gt;</div><div style>Do the autocomplete=
. =C2=A0This should also stay as-is.</div><div style>- tags</div><div style=
>Return a tag cloud. =C2=A0Is this route still used anywhere?</div><div sty=
le>- tag/&lt;tag_id&gt;(/&lt;tag_name&gt;)</div>

<div style>Show the items for a tag. =C2=A0This is currently the canonical =
URL for a tag, and the tag_name is purely decorative.</div><div style>- tag=
_name/&lt;tag_name&gt;</div><div style>Find a tag by its name, then redirec=
t it to its canonical URL.</div>

<div style><br></div><div style>It&#39;s mainly the last two I&#39;d like t=
o change. =C2=A0Here&#39;s what I&#39;d like it to be:</div><div style>- ta=
g</div><div style>Show the tags as albums, similar to the tag_albums module=
</div>

<div style>- tag/&lt;tag_slug&gt;</div><div style>Show the items for a tag.=
 =C2=A0This is the new canonical URL for a tag.</div><div style><br></div><=
div style>Obviously, this requires a bit of work. =C2=A0The first phase is =
to change the canonical URL, add a slug field to the tag model, allow the s=
lugs to be edited (only in the admin menu - not needed in the main &quot;ad=
d&quot; interface), and ensure we can (mostly) redirect the old URLs. =C2=
=A0This is the part I&#39;d like to bite off sooner than later.</div>

<div style><br></div><div style>Then, in a separate project, we can get the=
 &quot;tag&quot; route going. =C2=A0Really, this phase is all about adding =
things like album cover ids, sort orders, etc. to each tag. =C2=A0This part=
 is probably best tackled after revisiting the &quot;pagination&quot; code =
that shows collections (currently written up independently for albums, tags=
, and search... should be unified in View_Gallery or View_Theme).</div>

<div style><br></div><div style>Thoughts?</div><div style><br></div><div st=
yle>Take care,<br></div><div style>Shad</div></div>

--f46d04430642bacdee04dcc43e2f--


--===============5977795429904688983==
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
--===============5977795429904688983==
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 ]
--===============5977795429904688983==--