I can understand why you want to use Elixir for its ease of use but it bothers me when the defaults encourage bad design practices. Persistence should always be separated from the business logic but with Elixir that's not possible. I realize the data is being stored in the database but you end up mixing database design details in with the business objects.
I realize that straight SA contains quite a bit of boiler plate that makes it look more complex and increases the amount of required coding and could discourage some users but at least it handles more than just the simplest database needs. How long can someone using Elixir put off learning straight SA? Even if they don't have to learn mappers when using Elixir they will need to learn a good chunk of SA. For the past half week or so I have had an idea on how to eliminate most of the boiler plate code in the __init__ methods of your business objects when using straight SA. The idea would be to modify the magic init function that replaces the classes __init__ method to add a call to a hook method that is auto generated and added to the class when the mapper is compiled. This auto generated hook method would just contain the boiler plate code that normally appears in the __init__ method and thus eliminate 20-30% of the code normally required for straight SA. I haven't brought this up on the SA list yet as I wanted to code it up to see if I run into any issues. If this idea pans out it would simplify things a bit for SA. John On Aug 8, 6:10 pm, "Mark Ramm" <[EMAIL PROTECTED]> wrote: > I think the point was that there would be extra features (data > dependent authorization) added using elixir's polymorphic association > type statements. (This would make the identity related tables less > trivial (but still not that complex). > > These ought to be translatable to raw SA, but we're already going for > elixir as the default in TG for ease of use reasons, so I wasn't too > worried about adding it as a dependency. > > This is far from decided yet, so it is a good time to have this discussion. > > --Mark > > On 8/8/07, John M Camara <[EMAIL PROTECTED]> wrote: > > > > > > > Why introduce another dependency to TG when the identity model is > > trivial and can easily be built at the SA ORM level? I just don't see > > any benefits. > > > John > > > On Aug 8, 1:23 pm, "Mark Ramm" <[EMAIL PROTECTED]> wrote: > > > I'm CCing Pylons-devel list, as the last I heard somebody overthere > > > had plans to do some identity like syntax on top of elixir that also > > > allowed tying access to particular data in the database. > > > > --Mark > > > > On 8/8/07, kwilliams <[EMAIL PROTECTED]> wrote: > > > > > Who's hacking on the Identity port? I'd like to help > > > > > On Aug 8, 6:25 am, "Mark Ramm" <[EMAIL PROTECTED]> wrote: > > > > > On 8/7/07, scruffy323 <[EMAIL PROTECTED]> wrote: > > > > > > > I am a experience developer but new to TurgoGears and wanted to know > > > > > > if I can start deployment with TG2 or do I have to start with TG1? > > > > > > Is > > > > > > there a actuall TG2 that's usable right now even if it's alpha? > > > > > > Not yet in alpha, but you can checkout from SVN, and it should work. > > > > > > Identity isn't ported yet, and there's no automatic wrapping of > > > > > requests in transactions yet. But it should work. > > > > > >http://docs.turbogears.org/2.0/RoughDocs/InstallingFromDev > > > > -- > > > Mark Ramm-Christensen > > > email: mark at compoundthinking dot com > > > blog:www.compoundthinking.com/blog > > -- > Mark Ramm-Christensen > email: mark at compoundthinking dot com > blog:www.compoundthinking.com/blog --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
