On 11/12/05, Levi <[EMAIL PROTECTED]> wrote: > > 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 :)
As you mention at the end of your email, these little details can make the difference between a framework that works but annoys you every time you use it, and one that you love using. > >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). Hmm... This is an interesting point. Though, as you said, forms are stateless. you could just as easily do: login_form = TableForm(TextField(tg_user), PasswordField(tg_password)) or some such. > 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. I agree that this type of conversation is important to have. The difficulty is that there's generally no provably right answer. If someone shows me a use case or two that is clearly better one way or the other, that will help. For now, this is the one that "feels" the most straightforward to me. Kevin -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
