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
