Ian Bicking [mailto:ianb@...] 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
> 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
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?