On Apr 17, 9:53 am, "Dan Korostelev" <[EMAIL PROTECTED]> wrote:
> 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?
Sounds reasonable to me
>
> - Perhaps Mako could be made to run in parallel with any other
>
> > templating engine (see
> >http://docs.pythonweb.org/display/pylonscookbook/Using+Mako+templatin...
> > )
>
> 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
> - 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.
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.
> - 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. :)
excellent
> 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.
TBH SQLAlchemy is fine with me :-) Are you working on the
relationships or shall I start hacking away?
> 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 [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
-~----------~----~----~----~------~----~------~--~---
