Pages should be derived from SitePage when they have no use for user information
Pages should be derived from SecurePage when they need user information.
Secure page does not need to require a login, it just assumes a user object will be available. I set the user objec to 'guest' until they logged in. But any page built on SecurePage could call user.name and get a non Null (non-None) answer.
-Aaron
Geoffrey Talvola wrote:
Ian Bicking [mailto:[EMAIL PROTECTED]] wrote:On Mon, 2003-03-03 at 09:58, Geoffrey Talvola wrote:I do believe we should keep Page and SecurePage separate. It'll make the framework easier to learn because you can just start with Page without worrying about the security. And some people may never need to learn SecurePage. Also, users may want to implement their own custom security framework derived from Page -- but if there is already security implemented in Page that may be difficult.Honestly, I think at most 10% of Webware's target audience won't be using authentication, probably less. Even public sites usually have user accounts. Many sites start without authentication, but it's just a stage of their growth. I think the conceptual overhead of having a separate class is greater than the overhead of having hooks directly in Page. And I don't think the natural evolution of a site should involve a change in the class hierarchy.It's a tiny change to modify my SitePage to derive from SecurePage instead of Page.The technique I layed out before would, I believe, be flexible enough for everyone. It only deals with the login, not other security issues. There's also a convention for what the results of the login are (a user object created), but there would be a method you could override to change that.And I don't buy your argument about a page being public sometimes and private sometimes, because we can just implement that capability into SecurePage.Sure we could do that in SecurePage, but it's just one more detail, one more method. Putting it into Page is the *easiest* way to do it -- for the amount of code involved (to write and for others to read and understand), for describing in documentation, and easiest to actually use.I'm not convinced. From a design perspective I find it better to use a subclass. Or perhaps a Mixin. Just something that keeps the authentication stuff separate from Page. Is there something specific about your proposal that actually makes it harder to accomplish in a subclass of Page than it would be in Page itself? I mean other than the standard overhead of having a separate source file, import statements at the top, class declaration, etc? - Geoff ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
