Ben Sizer wrote: > Unfortunately the naive approach seems to yield errors like > "AttributeError: type object 'User' has no attribute '_descriptor'", > where User is a plain SA class and I've referred to it with a > 'belongs_to' relation from an Elixir class. There are no hits > for this error on either this or the SQLElixir group. I'm sure > someone's documented how I get around this, somewhere. I'm guessing > '_descriptor' is part of the private interface that Elixir Entities > have, but beyond that, I dunno.
Gaetan just added a test to show what is currently possible, and a commented out test to show what we'd like to have working when we get a chance: http://elixir.ematia.de/trac/browser/elixir/trunk/tests/ test_sa_integeration.py?rev=241 Essentially, plain SQLAlchemy objects can refer to Elixir objects with no problem right now. You can't do the same in the other direction (yet) without workarounds. > ... this sort of hints at all that is bad about Turbogears, in my > (apparently minority) opinion. Everybody seems to think that it's > great that all the parts are interchangeable. I totally understand what you are saying. You aren't really in the minority, as I think we've been migrating to new defaults for a looong time. There has also been a lot of debate about what the new defaults will be: CherryPy 3 or Paste, SQLAlchemy or Elixir, Genshi, etc. TurboGears is about having sane defaults though, meaning that if you don't know enough to make your own decisions, you can just let TurboGears choose for you. The main reason TurboGears makes it possible to swap things out so that the maintainers can make sure that the default is always the best-of-breed selection. If something better comes along, its possible for us to flip a switch. I also like that the parts are interchangable because sometimes the defaults don't make sense for a particular project. For example, sometimes Genshi is totally the wrong choice for an application, because it can be very slow when rendering very large and complex templates. In those cases, I like the fact that I can use Mako, for raw speed. This is just one example of why choice and flexibility are good. Of course, choice needs to be balanced with sane defaults, so that newbies can get rolling without having to make any decisions on their own :) > Possibly the best thing for me to do at this stage is just strip out > Identity and all the associated objects, and write all the login stuff > myself with Elixir. I expect it'll be poor compared to using Identity > or Authkit or whatever the authentication flavour of the month module > is, but at least I won't be chasing round the web and mailing lists > trying to find out how to get it to comply. Trust me, it won't take you a long time to build something like identity that meets your needs much better. Identity is easy to use, but kind of weird in its implementation, and too closely tied to your model. AuthKit is much better, but is really young, poorly documented, and difficult to use at this stage. So, I just created something that doesn't aim to be general purpose, but just meets my own needs in the project I am working on. It took about 2 days. That being said, if identity works for you, and you like it, go for it. > Which example? I typed "easy_install elixir", and got an .egg > installed, and that's all I know. The 'examples' page on the Elixir > Wiki is blank. You can find it in subversion by looking through the source, or you can take another look at the examples page on the wiki, which now links directly into the example :) > Well, it doesn't work yet, that's the thing. I have a model.py that > doesn't work due to the exception I noted earlier, and I can't go much > further until I know what I'm supposed to do to make it work. I asked > how to mix the 2 models and maybe when someone has an answer for me, I > can proceed. Or maybe I'll just have to remove the plain SA stuff. I > don't know. Ask on the Elixir list (again if you already have), you'll get a much better response I think. > All I know at this stage is that it gets really demoralising to spend > 20 minutes coding and then hours waiting for support, but that's been > my Turbogears experience from day one. > > I apologise for the frustrated tone! It is just difficult when the > language and tools become the barrier rather than the solution. I totally understand. If documentation and a large, responsive user base are extremely important to you, then TurboGears may actually not be the right choice for you. That might change in the future, of course, if more people get involved and help improve the current situation. -- Jonathan LaCour http://cleverdevil.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
