On 4/17/07, bjpirt <[EMAIL PROTECTED]> wrote: > On Apr 17, 9:53 am, "Dan Korostelev" <[EMAIL PROTECTED]> wrote: > > Well what if the primary key is defined by user on object creation? I > guess > > we should have an option on making it visible/invisible. I guess we can > make > > the primary_key invisible by default if it's Integer and autoincrement. > What > > do you think? > Sounds reasonable to me
I committed a little check that skips autogenerated integer primary keys from HTML field generation. > Here's I don't want to depend hardly on Mako, because users could define > > their own templates in their preferred template engine. So if I provide > > default templates in Mako, it should use it internal and independent on > the > > application's global template engine setting, but also user should be > able > > to set own template engine name in the configuration (just like the > > 'domains' attribute in the subclassed controller). Adding a ticket for > this. > Sounds good - should just be a case of specifying mako explicitly when > you call render I think Also fixed this. Now the default template engine is Mako, and it's passed explicitly to the render_response call, but it can be changed using the 'template_engine' class variable. Yes, I wondered about putting more stuff in the model to define how > you want to be able to view it, but it feels wrong to me - the model > feels like it should be a generic data structure without view specific > stuff in there too. Mm..I guess you're right here, especially when this way gives us more flexibility in admin area configuration. For me personally, it's okay to put the field labels and display configuration in the controller code. But what about HTML field generators and converters/validators? In all tutorials, the validation schemas stated as models. There's not much difference between our "user-defined" validators/generators and the form validation schemas. So I'm not really sure where to put it yet, but for now, I think it will go to the controller properties, because that seems to be the right way and it's more flexible. :) > > As for "any ORM". Well I don't think it's possible to make it work with > ANY > > ORM, because there's no standard interface AFAIK, but we could add > support > > for most popular ones. > TBH SQLAlchemy is fine with me :-) Are you working on the > relationships or shall I start hacking away? > I'm just started grokking it and I'll for sure find out how to work with it someday, but I also don't have very much free time to work on it, so if you will get it before me and offer suggestions or even patches, it would be cool. :) -- WBR, Dan Korostelev --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
