On Wed, Oct 15, 2008 at 2:11 PM, Mike Orr <[EMAIL PROTECTED]> wrote: > > On Wed, Oct 15, 2008 at 10:25 AM, Jorge Vargas <[EMAIL PROTECTED]> wrote: >> >> On Mon, Oct 13, 2008 at 10:11 PM, Mike Orr <[EMAIL PROTECTED]> wrote: >>> >>> On Mon, Oct 13, 2008 at 9:14 AM, Tomasz Nazar <[EMAIL PROTECTED]> wrote: >>>> Is reason other than problems with pure Python imports (which don't >>>> work well for recursive dependencies)? >>> >>> Circular imports work but you have to put the lines in a certain >>> order. If module A imports module B, and module B imports module A >>> *and* in its top level code accesses something in module A, that >>> something has to be created in module A *above* the "import B" >>> statement. Otherwise, at the moment module B needs it, it doesn't >>> exist yet. If you do all your attribute access inside functions, this >>> doesn't matter because both modules are fully initialized by the time >>> the function is called (as long as it isn't called at the top level of >>> the module). >>> >>> Rather than having to carefully order their lines of code, most people >>> prefer to just avoid circular imports. So they make small base >>> modules like 'meta' and 'errors' that everybody can import, but which >>> themselves import only the Python standard library. >>> >> the underlaying problem is that if you want to make your models >> available as model.Obj instead of model.obj.Obj you need to provide >> this "magic" with the meta.py and __init__.py if you will reference >> everything in a java-like form, then you can get rid of the imports in >> model and everything works fine, but then you don't have the >> flexibility of reorganizing stuff inside the model package without >> breaking your client code. Bottom line it's a very handy feature that >> require a little obscure code, and by obscure I mean it's not logical >> at first glance not that is complex code. > > Forgot to address the issue of how Python imports differ from Java. > In Java the import is just a syntax shortcut to avoid having to type > the module prefix. If the module (class) is used anywhere, the > compiler automatically loads it, with or without import. In Python, > the module is not accessible unless you import it in every module that > depends on it. "import" is also an executable statement (as opposed > to a compiler directive like "global"), which means that it matters > where you put it: the item is not accessible before you execute the > import but it is accessible afterward. > > Technically, the first time a module is imported, it's loaded and > assigned a key in sys.modules. If you import it multiple times, the > memory copy is used directly rather than reloading the code. But even > if the module is loaded, it's not *accessible* unless you import it . > (Or sneak into it with 'module = sys.modules['the_module"]'.) > >> ok I think you are mixing two things here. >> #1 crud - as in code generation >> #2 admin interface - as in a real way to update models > > I was really talking about an admin interface, or something that could > be plugged into a program, not code generation. > > BTW, a complete Admin interface should also stop and restart the > server, view logs, manage users and permissions, etc. Managing users > is only feasable if the application uses a standardized user model, > but the other features are generic to any Pylons application. Zope > has this kind of admin interface, and ideally it should be available > for Pylons too. That's what I thought TurboGears was interested in > building. > That's a very nice long term plan. And I think rum is a good candidate for it. the user permissions is what I find the hardest as a "standardized" model is something that isn't possible in most applications. At most I'll say provide something that will inspect your model classes and work from there, which is what rum does but currently doesn't handles it any different from any other table.
> Stopping/restarting the server would have to be done in Paste, so it > would need a method in Paste that Pylons could call. > that could be interesting, although it means the admin will have to run standalone in it's own port, again something rum is able to do. I think most of the parts you suggest are already in place it's just a matter of sitting down and add the glue, although I do think that ones it happens people will complain that it isn't flexible enough. >>> According to Adrian's talk at PyCon this year, Django's CRUD interface >>> should theoretically run on Pylons. Somebody just needs to test it >>> and write a HOWTO. Ben and I thought it would be coming soon, but it >>> got lost among all the other work finishing up 0.9.7. >>> >> django-admin? how will it know about all the model configuration >> stuff? is there any links anywhere that suggest how it should be done? >> last time I heard django's sqlalchemy compatibility was in an >> abandoned branch. Also I assume you still need to install the whole >> tarball to get it running. > > I don't know how since I've never used Django. But Ben thought it > would be possible with some work. > Me neither I have just play with it. but it should be nice if that will interoperate. I have been thinking for a while of a django backend for rum, it has all the API in place, but I honestly don't have much interest in doing it myself other than learning about the internals of both. > -- > Mike Orr <[EMAIL PROTECTED]> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
