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. 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. Ian ------------------------------------------------------- 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
