Hi! Thanks for the answer! On 4/17/07, bjpirt <[EMAIL PROTECTED]> wrote:
> - It seems like the objects you are able to edit are only used to get > the underlying schema, so you are effectively mapping straight on to > the database without using the ORM, so relations do not show up. I > have been trying to work out where these fields are stored and as far > as I can tell they are in MyObject.mapper.props could an SQLAlchemy > expert confirm (or correct) this? I'm using the 'c' (column list) property, but I already thinked about relations, that are not stored there, so I'll check out 'mapper.props'. Relationships are important feature for administration interface, so it for sure should be done for the first release. Any help appreciated. :) - It would be good to not be able to edit the primary key of the > object 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? - Perhaps Mako could be made to run in parallel with any other > templating engine (see > http://docs.pythonweb.org/display/pylonscookbook/Using+Mako+templating+language > ) 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. - Perhaps the list of editable object types could be a dict > containing other dicts that could define which object fields are > editable AFAIK in Django, the admin tool properties are defined right in the model. I'm not sure what's "the right way" for it, but I kinda like the django approach, because it's really a "model" properties. In other hand, we could have different setups for different admin controller subclasses in the applications. Need to think about it more. - Need to be able to pass a limit and an offset to the list view, I > tried it with a table of 5000 rows and it took a little while :-) I already committed a fix for it. Now the 'list' action uses pagination and there's an items_per_page class variable that is 10 by default. :) I am happy to help with some stuff on this if you would like, I have > already built a method for adding relations so could look at adding > this in if you would like, though it would be good to talk about the > architecture of how this should be done though - good way of learning. > It does seem like something like this is missing from pylons. All of > the other web frameworks seem to have some kind of 'instant admin' > tool, although the modular nature of pylons makes the idea of a > standalone and easily installable ORM content editor which could work > with any ORM. > Yeah, that's the idea of AdminPylon. Easy installation is also the task for the release. It should somehow know about where to find its default data (templates and static files) but provide an easy way to redefine it. I think that it's not very hard, but I guess I must learn Pylons application creation and middleware setup more for this. 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. Thanks for the reaction. Glad to see some people are interested in this project! -- 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 pylons-discuss@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
