Re: Modularity - Users and UserProfile controllers
Bharat Mediratta <[email protected]> Sun, 12 May 2013 11:27:56 -0700
| Newsgroups | gmane.comp.web.gallery.devel |
|---|---|
| Message-ID | <CAESa+_kbPxOJ60pc7=4rwOe1a9QSuBBKin67i-VQOYtpAZQW6g@mail.gmail.com> |
--===============4810707749731715865== Content-Type: multipart/alternative; boundary=047d7b62527c7e282004dc899165 --047d7b62527c7e282004dc899165 Content-Type: text/plain; charset=ISO-8859-1 Stacking is an interesting concept, but doesn't that mean that we have multiple identity providers active at a given time? If the user isn't in ldap, I don't think that falling back to the user module is the right way to go. There should be a single, canonical source of truth for identities. Switching between identity systems is painful and we should eliminate it. On Sun, May 12, 2013 at 10:03 AM, Tim Almdal <[email protected]> wrote: > I agree that the Identity Provider as implemented is overly complex when > it comes to switching providers (there is a dangerous place, where one is > uninstalled and the new one isn't installed) to some simplification would > be good. If I was to do the identity provider over again, I would make it > a "stack" so that the default user module as provided by gallery is always > installed at the bottom, and other providers (i.e. ldap) would be stacked > above it. Searching for a user would parse down the stack looking for the > appropriate user. This way we wouldn't have the messiness of switching the > item owners and such > > Just my 2cents > > Tim > > On 5/11/2013 3:20 PM, Bharat Mediratta wrote: > > > 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 ] >> > > > > ------------------------------------------------------------------------------ > 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 ] > > > --047d7b62527c7e282004dc899165 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div style>Stacking is an interesting concept, but doe= sn't that mean that we have multiple identity providers active at a giv= en time? =A0If the user isn't in ldap, I don't think that falling b= ack to the user module is the right way to go. =A0There should be a single,= canonical source of truth for identities. =A0Switching between identity sy= stems is painful and we should eliminate it.</div> </div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun,= May 12, 2013 at 10:03 AM, Tim Almdal <span dir=3D"ltr"><<a href=3D"mail= to:[email protected]" target=3D"_blank">[email protected]</a>></span> wrot= e:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> =20 =20 =20 <div text=3D"#000000" bgcolor=3D"#FFFFFF"> I agree that the Identity Provider as implemented is overly complex when it comes to switching providers (there is a dangerous place, where one is uninstalled and the new one isn't installed) to some simplification would be good.=A0 If I was to do the identity provider over again, I would make it a "stack" so that the default=A0 = user module as provided by gallery is always installed at the bottom, and other providers (i.e. ldap) would be stacked above it.=A0 Searching for a user would parse down the stack looking for the appropriate user.=A0 This way we wouldn't have the messiness of switching the i= tem owners and such<br> <br> Just my 2cents<span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> Tim</font></span><div><div class=3D"h5"><br> <div>On 5/11/2013 3:20 PM, Bharat Mediratta wrote:<br> </div> <blockquote type=3D"cite"> <div dir=3D"ltr"><br> <div>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. =A0Our current approach aims to be way too flexible and if we reduce scope we can greatly dial it down. =A0Right now we have the Identity class that relies on the IdentityProvider interface which uses an IdentityProvider driver to do the actual work. =A0This allows us to switch identity providers 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><br> </div> <div>This is overly flexible and nobody needs it.</div> <div><br> </div> <div>Instead we should just let modules implement the Identity API directly. =A0No more IdentityProvider and driver - just define an Identity interface and let modules implement it. =A0At install time, we'll install the user module by default.. but if you click an "advanced" link you can p= ick from some other ones (like Drupal, etc) and we'll install tha= t module instead. =A0You can't install identity modules later - once you pick one that's the one you get.=A0</div> <div><br> </div> <div>I think this will simplify things considerably. =A0The 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.</di= v> <div><br> </div> <div>thoughts?</div> </div> <div class=3D"gmail_extra"><br> <br> <div class=3D"gmail_quote">On Sat, May 11, 2013 at 2:26 PM, Shad Laws <span dir=3D"ltr"><<a href=3D"mailto:shad-xpYdmXCiSuZWk0Htik3J/[email protected]" t= arget=3D"_blank">shad-xpYdmXCiSuZWk0Htik3J/[email protected]</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex"> <div dir=3D"ltr">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. =A0Using a module event is probably a more flexible approach... <div class=3D"gmail_extra"> <br> </div> <div class=3D"gmail_extra">Take care,</div> <div class=3D"gmail_extra">Shad</div> <div class=3D"gmail_extra"><br> <br> <div class=3D"gmail_quote"> <div>On 11 May 2013 19:31, Shad Laws <span dir=3D"ltr">&l= t;<a href=3D"mailto:shad-xpYdmXCiSuZWk0Htik3J/[email protected]" target=3D"_blank">shad-xpYdmXCiSuZWk0Htik3J/[email protected]<= /a>></span> wrote:<br> </div> <div> <div> <blockquote class=3D"gmail_quote" style=3D"margin: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/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.</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 function action_edit();</font></div> <div><font face=3D"courier new, monospace">=A0 public function action_change_email();</fon= t></div> <div><font face=3D"courier new, monospace">=A0 public function action_change_password();</font></div> <div><font face=3D"courier new, monospace">}</f= ont></div> </div> <div><font face=3D"courier new, monospace">[galle= ry module]</font></div> <div><font face=3D"courier new, monospace">class Controller_UserProfile extends=A0Gallery_Controller_UserProfile=A0{}= </font></div> <div><font face=3D"courier new, monospace">class Gallery_Controller_UserProfile {<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></div= > <div><font face=3D"courier new, monospace">}</fon= t></div> <div><br> </div> <div>My thought:<br> </div> <div>- in the gallery module, change Controller_UserProfile to make it an abstract class in IdentityProvider.</div> <div>- add three abstract action functions that reflect the three links 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 like:</div> <div> <div> <div><font face=3D"courier new, monospace">[u= ser module]<br> </font></div> <div><font face=3D"courier new, monospace">cl= ass Controller_Users extends User_Controller_Users {}</font></div> <div><font face=3D"courier new, monospace">cl= ass User_Controller_Users extends IdentityProvider_Controller_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 function 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">[gal= lery module]</font></div> <div><font face=3D"courier new, monospace">abst= ract class IdentityProvider_Controller_Users extends Gallery_IdentityProvider_Controller_Users {}</font></div> <div><font face=3D"courier new, monospace">abst= ract class Gallery_IdentityProvider_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 action_edit();</fo= nt></div> <div><font face=3D"courier new, monospace">=A0= =A0abstract=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">}</f= ont></div> <div><br> </div> <div>Thoughts?</div> <div><br> </div> <div>Take care,<br> </div> <div>Shad</div> </div> </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 grap= h 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/n= eotech_d2d_may" target=3D"_blank">http://p.sf.net/sfu/neotech_d2d_may</a><b= r> __[ g a l l e r y - d e v e l ]_________________________<br> <br> [ list info/archive --> <a href=3D"http://gallery.sf.net/lis= ts.php" target=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> <br> <fieldset></fieldset> <br> <pre>----------------------------------------------------------------= -------------- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases = and=20 their applications. This 200-page book is written by three acclaimed=20 leaders in the field. The early access version is available now.=20 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></pre> <br> <fieldset></fieldset> <br> <pre>__[ g a l l e r y - d e v e l ]_________________________ [ list info/archive --> <a href=3D"http://gallery.sf.net/lists.php" targ= et=3D"_blank">http://gallery.sf.net/lists.php</a> ] [ gallery info/FAQ/download --> <a href=3D"http://gallery.sf.net" target= =3D"_blank">http://gallery.sf.net</a> ]</pre> </blockquote> <br> </div></div></div> </blockquote></div><br></div> --047d7b62527c7e282004dc899165-- --===============4810707749731715865== 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 --===============4810707749731715865== 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 ] --===============4810707749731715865==--