You don't have to waste a whole lot of time on this thread. I appreciate your replies and find the issue interesting, but realize the tg community would rather see you hammering out widgets and books :)
>From a modeling perspective, I believe it's valid (but pedantic) to say "a login form is a type of form". In fact, I think tg could pretty safely provide a LoginForm (extends TableForm) widget. A default template would be vanilla w/ lots-o css hooks, be bound to tg_user and tg_role tables, etc. The template could handle ordering, etc. etc.. (heck, @expose could even pick up 'required_role' and 'login_url' key words). >From an implementation perspective we (the oopers of the world) have learned that composition/instance based design is waaaay more powerful (less rigid really) than inheritance. For that reason alone, I'm completely on board with your implementation. Beyond that, I'm into your implementation because it's intelligent, working code :) If determining the type -v- instance mattered, I would have to note that forms don't appear to be stateful. And (I can't believe I'm saying this, dimiss it immediately!) that it could be implemented as a singleton. Of course, all of my comments are makeing me feel like I'm becoming an "architect astronaut" (http://www.joelonsoftware.com/articles/fog0000000018.html). Actually, I was a little dismissive of this thread when I sat down to write. In truth, I'm glad it's not being trivialized. Style and design are ___realllllly___ important. TG's base products (SQLObject, MochiKet, et al.) are perfect examples of thoughful design. So, thanks for thinking out loud. -- Levi
