Re: Modularity - Users and UserProfile controllers
Bharat Mediratta <[email protected]> Sat, 11 May 2013 15:20:29 -0700
| Newsgroups | gmane.comp.web.gallery.devel |
|---|---|
| Message-ID | <CAESa+_nK111a=_KcnRY_wJcJ5ktCsfR+rPvE80rcfMpC-BYD3g@mail.gmail.com> |
--===============8522422450494891551== Content-Type: multipart/alternative; boundary=047d7bdc055c55b0e104dc78b34b --047d7bdc055c55b0e104dc78b34b Content-Type: text/plain; charset=ISO-8859-1 Up to my ears today so I can't respond to this in depth - but I think we're doing all the user module stuff wrong. Our current approach aims to be way too flexible and if we reduce scope we can greatly dial it down. Right now we have the Identity class that relies on the IdentityProvider interface which uses an IdentityProvider driver to do the actual work. This allows us to switch identity providers at runtime by adding and removing modules. That sounds great, but it adds a bunch of complexity that I think few people actually use. It also puts us in the awkward situation in a few places in the code where we're not even sure if there *is* an identity provider. This is overly flexible and nobody needs it. Instead we should just let modules implement the Identity API directly. No more IdentityProvider and driver - just define an Identity interface and let modules implement it. At install time, we'll install the user module by default.. but if you click an "advanced" link you can pick from some other ones (like Drupal, etc) and we'll install that module instead. You can't install identity modules later - once you pick one that's the one you get. I think this will simplify things considerably. The user module can provide its own controllers, etc and we can move them out of the Gallery module so we don't have this abstract concept of what you can and can't do with users. thoughts? On Sat, May 11, 2013 at 2:26 PM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote: > Hmm... on second thought, the approach I proposed has a problem: it > *expects* that Gallery should be able to change the email, password, etc., > which may not always be the case for an identity provider. Using a module > event is probably a more flexible approach... > > Take care, > Shad > > > On 11 May 2013 19:31, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote: > >> Hey everyone, >> >> I just finished converting the user/group-related controllers and forms >> over to Formo, and found that the view used in >> Controller_UserProfile::action_show() (gallery module) has URLs to things >> in Controller_Users (user module)... which seems like a breach of >> modularity. >> >> Right now, we have: >> [user module] >> class Controller_Users extends User_Controller_Users {} >> class User_Controller_Users { >> public function action_edit(); >> public function action_change_email(); >> public function action_change_password(); >> } >> [gallery module] >> class Controller_UserProfile extends Gallery_Controller_UserProfile {} >> class Gallery_Controller_UserProfile { >> public function action_show(); >> public function action_contact(); >> } >> >> My thought: >> - in the gallery module, change Controller_UserProfile to make it an >> abstract class in IdentityProvider. >> - add three abstract action functions that reflect the three links it >> wants. >> - in the user module, make Controller_UserProfile extend the abstract >> class in Gallery. >> >> Then, we'd have something like: >> [user module] >> class Controller_Users extends User_Controller_Users {} >> class User_Controller_Users extends IdentityProvider_Controller_Users { >> public function action_edit(); >> public function action_change_email(); >> public function action_change_password(); >> } >> [gallery module] >> abstract class IdentityProvider_Controller_Users extends >> Gallery_IdentityProvider_Controller_Users {} >> abstract class Gallery_IdentityProvider_Controller_Users { >> public function action_show(); >> public function action_contact(); >> abstract public function action_edit(); >> abstract public function action_change_email(); >> abstract public function action_change_password(); >> } >> >> Thoughts? >> >> Take care, >> Shad >> > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > __[ 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 ] > --047d7bdc055c55b0e104dc78b34b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div style>Up to my ears today so I can't respond = to this in depth - but I think we're doing all the user module stuff wr= ong. =A0Our current approach aims to be way too flexible and if we reduce s= cope we can greatly dial it down. =A0Right now we have the Identity class t= hat relies on the IdentityProvider interface which uses an IdentityProvider= driver to do the actual work. =A0This allows us to switch identity provide= rs at runtime by adding and removing modules. =A0That sounds great, but it = adds a bunch of complexity that I think few people actually use. =A0It also= puts us in the awkward situation in a few places in the code where we'= re not even sure if there <i>is</i>=A0an identity provider.</div> <div style><br></div><div style>This is overly flexible and nobody needs it= .</div><div style><br></div><div style>Instead we should just let modules i= mplement the Identity API directly. =A0No more IdentityProvider and driver = - just define an Identity interface and let modules implement it. =A0At ins= tall time, we'll install the user module by default.. but if you click = an "advanced" link you can pick from some other ones (like Drupal= , etc) and we'll install that module instead. =A0You can't install = identity modules later - once you pick one that's the one you get.=A0</= div> <div style><br></div><div style>I think this will simplify things considera= bly. =A0The user module can provide its own controllers, etc and we can mov= e them out of the Gallery module so we don't have this abstract concept= of what you can and can't do with users.</div> <div style><br></div><div style>thoughts?</div></div><div class=3D"gmail_ex= tra"><br><br><div class=3D"gmail_quote">On Sat, May 11, 2013 at 2:26 PM, Sh= ad Laws <span dir=3D"ltr"><<a href=3D"mailto:shad-xpYdmXCiSuZWk0Htik3J/[email protected]" target= =3D"_blank">shad-xpYdmXCiSuZWk0Htik3J/[email protected]</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hmm... on second thought, t= he approach I proposed has a problem: it *expects* that Gallery should be a= ble to change the email, password, etc., which may not always be the case f= or an identity provider. =A0Using a module event is probably a more flexibl= e approach...<div class=3D"gmail_extra"> <br></div><div class=3D"gmail_extra">Take care,</div><div class=3D"gmail_ex= tra">Shad</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote= "><div class=3D"im">On 11 May 2013 19:31, Shad Laws <span dir=3D"ltr"><<= a href=3D"mailto:shad-xpYdmXCiSuZWk0Htik3J/[email protected]" target=3D"_blank">shad-xpYdmXCiSuZWk0Htik3J/[email protected]</a>= ></span> wrote:<br> </div><div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr= ">Hey everyone,<div><br></div><div>I just finished converting the user/grou= p-related controllers and forms over to Formo, and found that the view used= in Controller_UserProfile::action_show() (gallery module) has URLs to thin= gs in Controller_Users (user module)... which seems like a breach of modula= rity.</div> <div><br></div><div>Right now, we have:</div><div><font face=3D"courier new= , monospace">[user module]<br></font></div><div><font face=3D"courier new, = monospace">class Controller_Users extends User_Controller_Users {}</font></= div> <div><font face=3D"courier new, monospace">class User_Controller_Users {<br= ></font></div><div><div><font face=3D"courier new, monospace">=A0 public fu= nction action_edit();</font></div><div><font face=3D"courier new, monospace= ">=A0 public function action_change_email();</font></div> <div><font face=3D"courier new, monospace">=A0 public function action_chang= e_password();</font></div><div><font face=3D"courier new, monospace">}</fon= t></div></div><div><font face=3D"courier new, monospace">[gallery module]</= font></div> <div><font face=3D"courier new, monospace">class Controller_UserProfile ext= ends=A0Gallery_Controller_UserProfile=A0{}</font></div><div><font face=3D"c= ourier new, monospace">class Gallery_Controller_UserProfile {<br></font></d= iv> <div><font face=3D"courier new, monospace">=A0 public function action_show(= );</font></div><div><font face=3D"courier new, monospace">=A0 public functi= on action_contact();</font></div><div><font face=3D"courier new, monospace"= >}</font></div> <div><br></div><div>My thought:<br></div><div>- in the gallery module, chan= ge Controller_UserProfile to make it an abstract class in IdentityProvider.= </div><div>- add three abstract action functions that reflect the three lin= ks it wants.</div> <div>- in the user module, make Controller_UserProfile extend the abstract = class in Gallery.</div><div><br></div><div>Then, we'd have something li= ke:</div><div><div><div><font face=3D"courier new, monospace">[user module]= <br> </font></div><div><font face=3D"courier new, monospace">class Controller_Us= ers extends User_Controller_Users {}</font></div><div><font face=3D"courier= new, monospace">class User_Controller_Users extends IdentityProvider_Contr= oller_Users {</font></div> <div><div><font face=3D"courier new, monospace">=A0 public function action_= edit();</font></div><div><font face=3D"courier new, monospace">=A0 public f= unction action_change_email();</font></div><div><font face=3D"courier new, = monospace">=A0 public function action_change_password();</font></div> <div><font face=3D"courier new, monospace">}</font></div></div></div><div><= font face=3D"courier new, monospace">[gallery module]</font></div><div><fon= t face=3D"courier new, monospace">abstract class IdentityProvider_Controlle= r_Users extends Gallery_IdentityProvider_Controller_Users {}</font></div> <div><font face=3D"courier new, monospace">abstract class Gallery_IdentityP= rovider_Controller_Users=A0{<br></font></div><div><font face=3D"courier new= , monospace">=A0 public function action_show();</font></div><div><font face= =3D"courier new, monospace">=A0 public function action_contact();</font></d= iv> <div><font face=3D"courier new, monospace">=A0 abstract public function act= ion_edit();</font></div><div><font face=3D"courier new, monospace">=A0=A0ab= stract=A0public function action_change_email();</font></div><div><font face= =3D"courier new, monospace">=A0=A0abstract=A0public function action_change_= password();</font></div> <div><font face=3D"courier new, monospace">}</font></div><div><br></div><di= v>Thoughts?</div><div><br></div><div>Take care,<br></div><div>Shad</div></d= iv></div> </blockquote></div></div></div><br></div></div> <br>-----------------------------------------------------------------------= -------<br> Learn Graph Databases - Download FREE O'Reilly Book<br> "Graph Databases" is the definitive new guide to graph databases = and<br> their applications. This 200-page book is written by three acclaimed<br> leaders in the field. The early access version is available now.<br> Download your free book today! <a href=3D"http://p.sf.net/sfu/neotech_d2d_m= ay" target=3D"_blank">http://p.sf.net/sfu/neotech_d2d_may</a><br>__[ g a l = l e r y - d e v e l ]_________________________<br> <br> [ list info/archive --> <a href=3D"http://gallery.sf.net/lists.php" targ= et=3D"_blank">http://gallery.sf.net/lists.php</a> ]<br> [ gallery info/FAQ/download --> <a href=3D"http://gallery.sf.net" target= =3D"_blank">http://gallery.sf.net</a> ]<br></blockquote></div><br></div> --047d7bdc055c55b0e104dc78b34b-- --===============8522422450494891551== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may --===============8522422450494891551== 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 ] --===============8522422450494891551==--