in reply to Re^7: Re-blessing || Re-constructing objects
in thread Re-blessing || Re-constructing objects

Yes. However, I tend to put my authentication code in my cgiapp_prerun and, very rarely, refer to it in other places. This reduces work quite dramatically.

In the case of only authentication, that's a perfect solution. However, sometimes the authentication leads to authorization, and you have a system of user rights scattered all over the place. Instead of having many conditionals, I typically prefer to put all functionality in methods, and indicate rights by (re)blessing into the right package.

it's the reblessing solution that's harder to subclass.

That is what I referred to.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

  • Comment on Re^8: Re-blessing || Re-constructing objects

Replies are listed 'Best First'.
Re^9: Re-blessing || Re-constructing objects
by dragonchild (Archbishop) on Apr 18, 2006 at 15:21 UTC
    Well, if your runmode dispatches based on a certain level of authorization, then it should be asking the user "Do you have this authorization?". This is self-documenting and resilient in the face of change. I don't see how reblessing is a better solution.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

      I don't see how reblessing is a better solution.

      It's nice in terms of security, grouping, maintenance, and more of that. If you really don't see it, then that is too bad; I don't know how I could explain it better than I already have. And I think that you are unable to convince me as much as I am unable to convince you, so I'm going to spend my time on other branches of discussion.

      Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }