Announcement Announcement Module
Collapse
No announcement yet.
Spring Python and CherryPy 3 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Python and CherryPy 3

    I recently had an email/IM chat between myself, Sylvain and Russ. This was before we had the forum setup. I got permission from them to capture this discussion on the forum. I have since marked up the code blocks and quotes, so it is easier to read this interchange of ideas.
    ================================================== ========
    Hello Sylvain,

    Glad to meet you. I appreciate getting any type of assistance regarding CherryPy.

    One of my first things I did when creating Spring Python was to make a web app demo
    like Spring's petclinic, and I decided to use CherryPy (https://springpython.webfactional.com/wiki/PetClinic).
    I think cherrypy is pretty neat. Since my HTML was not very complicated, I don't
    use any templating libraries.

    The whole demo app is located at https://springpython.webfactional.co...ples/petclinic.

    petclinic.py is my cherrypy runner
    model.py contains all my business object, i.e. python POJOs
    controller.py contains the business logic, in this case database calls to populate
    the model objects
    view.py contains the HTML, and is basically a set of cherrypy exposed methods
    noxml.py contains three IoC containers, one demonstrating client-and-server, the
    other two demonstraing client-only and server-only versions of the application (show
    off remoting features of Spring Python). Right now, I am working on the client-and-server
    version.

    The version of petclinic.py I had working with CherryPy 2 is https://springpython.webfactional.co...nic.py?rev=109.

    Last night, I downloaded CherryPy 3.1.0 (since it advertised out-of-the-box Google
    App Engine support), and proceeded to adjust petclinic.py to work with it. You can
    see what changes I made at https://springpython.webfactional.com/changeset/122.

    I was able to view the petclinic app in my web browser, but my middleware security
    filter isn't working. I wrote a WSGI-compliant security filter. It is meant
    to intercept calls to "/", run them through the security filtering, and
    if things succeed, pass through to the actual app I have mounted at root. My filter
    code is located at https://springpython.webfactional.co...ecurity/web.py.

    I would appreciate any help on how to migrate my application properly. If you have
    questions, please feel free to email me, or IM me through skype me at "gregturn".

    FYI: Spring Python is my "pet" project, not my day job, so I can't
    always correspond in real time, but I will advise you about that.

    Thanks,
    Greg Turnquist
    Last edited by gregturn; Aug 28th, 2008, 03:45 PM.

  • #2
    Sylvain's response

    Good morning folks,

    Right, I've been navigating the Spring source code (I mean the Python
    port here) and I've had some comments to make from a pythonista
    perspective.

    If I understand correctly, there are two ways to describe a Spring
    components: either via a XML document (which I assume comes from the
    Java world) or from the code itself.

    In the latter case, a method is flagged as a Spring component through
    the usage of the @component decorator (Russ, just in case, look at
    this link for an introduction to decorators:
    http://www.siafoo.net/article/68). Python developers, like any
    developers, don't like digging to understand why something works the
    way it works. Frameworks like Spring (I mean the framework in general,
    not just the Python port) aim at finding the right balance between
    providing added value while refraining from becoming a black box that
    sooner or later forbid/prevent the developer from doing things in a
    certain way. In my opinion, the @component decorator does very little
    to justify its existence. In other words it breaks the aforementioned
    balance.

    Basically it does this:

    1/ Inspects a class instance for its methods
    2/ For each method that is decorated with @component, call the method
    3/ If the method also has the following attribute:
    "postProcessAfterInitialization", then it calls it.

    One immediate issue to me is that it doesn't lazily calls the methods
    and one might wonder the point of all this when the instance could
    have done it in its __init__(). It looks a bit like voodoo magic

    Take this:
    Code:
    class PetClinicClientAndServer(DecoratorBasedApplicationContext):
        def __init__(self):
            DecoratorBasedApplicationContext.__init__(self)
    
        @component
        def connectionFactory(self):
            connFactory = factory.MySQLConnectionFactory()
            connFactory.username = "springpython"
            connFactory.password = "springpython"
            connFactory.hostname = "localhost"
            connFactory.db = "petclinic"
            return connFactory
    Since you want to define the application's components explicitly in
    the code rather than in an XML, why not going all the way like this:
    Code:
    class PetClinicClientAndServer(object):
        def __init__(self):
            self.connectionFactory()
    
        def connectionFactory(self):
            connFactory = factory.MySQLConnectionFactory()
            connFactory.username = "springpython"
            connFactory.password = "springpython"
            connFactory.hostname = "localhost"
            connFactory.db = "petclinic"
            return connFactory
    That has two advantages:

    1/ It's explicit and self-contained while preserving functionality.
    You don't need to lookup the declaration of
    DecoratorBasedApplicationContext nor @component.
    2/ By removing the DecoratorBasedApplicationContext you allow any
    regular Python class (POPO) removing, in my opinion, unnecessary
    inheritance.

    If your method has a post initialization, make a decorator of it:
    Code:
    # Defined in spring somewhere
    def postInit(func):
        def inner(obj):
            func(obj)
            print "Do some post proc here: Yeah! Rock on!"
    
        return inner
    
    class PetClinicClientAndServer(object):
        def __init__(self):
            self.connectionFactory()
    
        @postInit
        def connectionFactory(self):
            connFactory = factory.MySQLConnectionFactory()
            connFactory.username = "springpython"
            connFactory.password = "springpython"
            connFactory.hostname = "localhost"
            connFactory.db = "petclinic"
            return connFactory
    Still easy to grasp, no introspection here.


    Why am i saying all this? I'm a huge believer in libraries rather than
    frameworks. Libraries are tools that truly add value while, when well
    designed, hardly coming into the developer's way. Frameworks define a
    canvas with boundaries to more or less hint the developer in a given
    way. The problem is that frameworks, no matter how smart they are,
    usually hit a point where they cannot provide the flexibility required
    to let developers with different background be efficient with them.
    That's why you often see "Framework X sucks big time" but if you dig
    a
    biot the statement it's because the developer was used to framework Y
    or that framework X came into the way at some stage.

    Libraries that are well designed usually don't have that issue. They
    offer a functionality but let the developer decide how he/she wants to
    apply it.

    I think, and it's not a mockery, that the Java world is rather a
    framework type of environment which leads usually to have as many
    frameworks as you have developers for the very reason I described
    above. Python has also its share of frameworks but the language is
    flexible enough to encourage libraries. I *strongly* believe that
    Python Spring has both functionalities that could be attractive to
    many developers while having the chance of doing so as a library
    rather than a framework.

    In fact Greg has done a great job in that regards with many parts of
    Python Spring (I notably like the spring.aop and aop.remoting
    packages) and I think it's not far off being a library rather than a
    framework for instance with changes like I highlighted previously.

    Would you lose Java developers on the way? I don't believe so because
    the functionality and promises are still there. Only the syntax is
    somehow different.
    Would you gain Python developers? I believe so. It's easier to attract
    people with a library because it's less intrusive than a whole new
    framework. Less coupling is better.

    A few more comments.

    Drop the database sub-package. Python has excellent ORM like
    SQLAlchemy and dejavu. The former is really well spread and there
    isn't any reason to ask developers to learn a new way of setting up
    their stack. Keeping the database package only adds up more work for
    little added value. Let people use their own choice of package.
    SQLAlchemy's syntax is rather close to the one describe as well.

    I'm rather feeling the same way towards the web package but still not
    yet sure about that one.

    Focus on what makes Python Spring different: aop, remoting, IoC, security.


    So there you go, sorry for the long email but I thought I needed to
    make those points clear from the start. This is no reflection on your
    great work Greg. It's just a point of view

    Hopefully I didn't sound too harsh either. Russ knows I sometimes use
    the wrong approach but always for making things better if i can


    - Sylvain
    Last edited by gregturn; Aug 28th, 2008, 03:13 PM.

    Comment


    • #3
      (Sylvain)

      One more thing. I thought about why the PetClinic was causing so much
      problem with CherryPy 3 and I believe it's because the Spring filters
      are not WSGI middlewares per nature.

      They could be applied from within a WSGI middleware or a CherryPy 3
      tool but themselves are not WSGI middleware.

      They are just functions to be applied at some stage of the request
      processing but are not part of the HTTP stack.

      Greg, we'll need to discuss this

      - Sylvain

      Comment


      • #4
        Russ's followup - Part 1

        Hi Sylvain,

        Thanks for taking a look through the code, wow you've been busy See some
        of my comments inline (demarcated with Russ>), Greg I'm sure will have more
        when he's up and around later on today:

        Originally posted by Sylvain
        ----- Original Message -----
        From: "Sylvain Hellegouarch" <[email protected]>

        Good morning folks,

        Right, I've been navigating the Spring source code (I mean the Python
        port here) and I've had some comments to make from a pythonista
        perspective.

        If I understand correctly, there are two ways to describe a Spring
        components: either via a XML document (which I assume comes from the
        Java world) or from the code itself.
        Russ> Absolutely right, altho all things Spring come from the Java world initially
        so it's fair to just say that the XML document approach is a Spring thing -
        most Spring developers get a warm fuzzy feeling when they see an XML config document
        because it gives them a common ground to start understanding an application before
        they delve into the specifics of the implementation language.

        Originally posted by Sylvain
        In the latter case, a method is flagged as a Spring component through
        the usage of the @component decorator (Russ, just in case, look at
        this link for an introduction to decorators:
        http://www.siafoo.net/article/68). Python developers, like any
        developers, don't like digging to understand why something works the
        way it works. Frameworks like Spring (I mean the framework in general,
        not just the Python port) aim at finding the right balance between
        providing added value while refraining from becoming a black box that
        sooner or later forbid/prevent the developer from doing things in a
        certain way. In my opinion, the @component decorator does very little
        to justify its existence. In other words it breaks the aforementioned
        balance.
        Russ> Hmm, not sure I agree here. @Component is meant to distinguish, at the
        class level, that a particular class results in one Spring-managed object. To this
        effect, I really like the fact that you just have to see the @component syntax and
        know that this class results in something managed by Spring. However, decorators
        are not supported at the class level, and that does feel like a disconnect and something
        that might need some more thought around...

        Originally posted by Sylvain
        Basically it does this:

        1/ Inspects a class instance for its methods
        2/ For each method that is decorated with @component, call the method
        3/ If the method also has the following attribute:
        "postProcessAfterInitialization", then it calls it.
        Russ> This is very much inline with what Spring does, and although it's not
        exactly voodoo magic I think the current implementation does not give the full picture.
        As I mentioned before, @Component is usually a class level annotation, and when
        used that way it becomes more obvious (as there is no special code required in the
        constructor) that this is a POPO that will be managed by Spring (or another container
        if it understands that annotation) (I'm using annotation here on purpose, as
        I'm not sure and will rely on your guys to tell me how python does this, if
        at all). So if @component was at the class level, and the init function didn't
        have to have any special calls to respect @component, then I don't think I would
        have any issues with @postProcessAfterInitialization, although I'd be tempted
        to bring it inline with what Spring developers are used to and maybe call is @PostConstruct?

        Originally posted by Sylvain
        One immediate issue to me is that it doesn't lazily calls the methods
        and one might wonder the point of all this when the instance could
        have done it in its __init__(). It looks a bit like voodoo magic
        Russ> Not sure I understand the meaning of "... lazily calls" Can you
        explain that a bit more?

        Russ> I think it might look like voodoo magic purely because this is a Spring-ism.
        However, if we are going to support decorator-based configuration then I think this
        is a great implementation of it, the only concern I have is that there is some intrusiveness
        if the constructor has to make a specific call, and that @Component cannot be applied
        to the class itself...

        Originally posted by Sylvain
        Take this:
        Code:
        class PetClinicClientAndServer(DecoratorBasedApplicationContext):
            def __init__(self):
                DecoratorBasedApplicationContext.__init__(self)
        
            @component
            def connectionFactory(self):
                connFactory = factory.MySQLConnectionFactory()
                connFactory.username = "springpython"
                connFactory.password = "springpython"
                connFactory.hostname = "localhost"
                connFactory.db = "petclinic"
                return connFactory
        Since you want to define the application's components explicitly in
        the code rather than in an XML, why not going all the way like this:
        Code:
        class PetClinicClientAndServer(object):
            def __init__(self):
                self.connectionFactory()
        
            def connectionFactory(self):
                connFactory = factory.MySQLConnectionFactory()
                connFactory.username = "springpython"
                connFactory.password = "springpython"
                connFactory.hostname = "localhost"
                connFactory.db = "petclinic"
                return connFactory
        That has two advantages:

        1/ It's explicit and self-contained while preserving functionality.
        You don't need to lookup the declaration of
        DecoratorBasedApplicationContext nor @component.
        2/ By removing the DecoratorBasedApplicationContext you allow any
        regular Python class (POPO) removing, in my opinion, unnecessary
        inheritance.
        Russ> Hmm, yeah but this breaks all sorts of concerns. What @Component was really
        trying to do was flag a particular class as being a candidate for being a Spring-managed
        object. I think we might have lost that point here. The point was not really to
        call that factory method, more to let Spring know "Hey, here's an object
        I want you to instantiate!"

        Originally posted by Sylvain
        If your method has a post initialization, make a decorator of it:
        Code:
        # Defined in spring somewhere
        def postInit(func):
            def inner(obj):
                func(obj)
                print "Do some post proc here: Yeah! Rock on!"
        
            return inner
        
        class PetClinicClientAndServer(object):
            def __init__(self):
                self.connectionFactory()
        
            @postInit
            def connectionFactory(self):
                connFactory = factory.MySQLConnectionFactory()
                connFactory.username = "springpython"
                connFactory.password = "springpython"
                connFactory.hostname = "localhost"
                connFactory.db = "petclinic"
                return connFactory
        Still easy to grasp, no introspection here.
        Russ> This falls very much into what I'd expect to see, but we really are
        talking about two separate things:
        1) Letting Spring know to construct an object from our class without having to
        explicitly mention it in the XML - that's what @Component is all about.
        2) Hooking into the lifecycle of that object by telling Spring to invoke particular
        methods on the object as it is instantiated (and destroyed). Actually that brings
        me to another point, if we are going to support @PostConstruct, we might want to
        consider @PreDestroy.


        Originally posted by Sylvain
        Why am i saying all this? I'm a huge believer in libraries rather than
        frameworks. Libraries are tools that truly add value while, when well
        designed, hardly coming into the developer's way. Frameworks define a
        canvas with boundaries to more or less hint the developer in a given
        way. The problem is that frameworks, no matter how smart they are,
        usually hit a point where they cannot provide the flexibility required
        to let developers with different background be efficient with them.
        That's why you often see "Framework X sucks big time" but if you dig
        a
        biot the statement it's because the developer was used to framework Y
        or that framework X came into the way at some stage.
        Russ> While I can see the argument, one of the qualities of Spring is that it
        is a framework, albeit as light and unintrusive a framework as possible. Spring
        is also a proven framework for building enterprise applications, and because it
        is unintrusive and very general purpose, not to mention easily extendable, there
        are very few development tasks that it would ever prevent.

        === To be continued ====
        Last edited by gregturn; Aug 28th, 2008, 03:39 PM. Reason: Add quote tags

        Comment


        • #5
          Russ's followup - Part 2

          == The rest of Russ's reply ==

          Russ> I also find that libraries themselves are intrusive as you have to understand
          and couple your code to their specific usage, which can make it hard to move from
          one library implementation to the next of exactly the same functionality. If you're
          lucky, this results in small code changes, if you're unlucky, an entire tier
          of your enterprise app needs to change... and this was the case often before Spring.
          Because of this challenge people tended to create their own vendor-neutral abstractions
          around libraries, which was fine but again code that was plumbing rather than code
          that made them money. Spring took that headache away by acting as an abstraction
          around those common pieces of functionality. This is where Spring has some qualities
          of a library as it provides a facade around common concerns, such as data access,
          that mean you can plug-in different implementations, often through configuration
          only, that don't affect the rest of your application. The core library/api remains
          the same, and if you need to get at more of the specifics of an implementation then
          you can. This is where the template pattern is used, such as in the database package.
          The idea with Spring is not to provide a data access technology, but to make it
          simple, through the use of the template pattern, to work with a number of different
          data access technologies in a consistent way and for those advanced cases the template
          provides access to the underlying specifics of a data access technology. The idea
          is "all the convenience when you can, all of the power when you need it".

          You can think of Spring as somewhere between an intrusive framework (bad), and a
          an inherently intrusive library (equally as bad) - it tries to hit that sweet-spot.

          Originally posted by Sylvain
          Libraries that are well designed usually don't have that issue. They
          offer a functionality but let the developer decide how he/she wants to
          apply it.
          Russ> True, but hopefully my point above shows why even that is not really enough.

          Originally posted by Sylvain
          I think, and it's not a mockery, that the Java world is rather a
          framework type of environment which leads usually to have as many
          frameworks as you have developers for the very reason I described
          above. Python has also its share of frameworks but the language is
          flexible enough to encourage libraries. I *strongly* believe that
          Python Spring has both functionalities that could be attractive to
          many developers while having the chance of doing so as a library
          rather than a framework.
          Russ> I would agree here, but this is why Spring is seen as being different from
          the crowd. Spring is, right now, THE enterprise framework, and it is specifically
          for enterprise applications that it is targeted. But I definitely want to talk around
          this a bit more. My take is Spring is half way between a framework and a library,
          and THAT is the reason it has been so hugely popular. Rather than forcing people
          to work a certain way, Spring offers facilities that implement best practices and
          get people being more productive, while you get to pick and choose which of those
          facilities you want to apply. For example, it is totally feasible to not use Spring
          for dependency injection at all... but if you do then there are a bunch more facilities
          you can make use of.

          Originally posted by Sylvain
          In fact Greg has done a great job in that regards with many parts of
          Python Spring (I notably like the spring.aop and aop.remoting
          packages) and I think it's not far off being a library rather than a
          framework for instance with changes like I highlighted previously.
          Russ> I echo that, but I think Greg probably has the right balance and there
          are a couple of areas, like the application of @Component, that might need some
          tweaking.

          Originally posted by Sylvain
          Would you lose Java developers on the way? I don't believe so because
          the functionality and promises are still there. Only the syntax is
          somehow different.
          Would you gain Python developers? I believe so. It's easier to attract
          people with a library because it's less intrusive than a whole new
          framework. Less coupling is better.
          Russ> Like I think I've said a couple of times now; I agree that strong frameworks
          are bad, but I also think that pure libraries fall short too, especially when it
          comes to enterprise apps. What I think we have with Spring Python is something that
          sits squarely in the middle, offering framework capabilities where appropriate and
          library-like qualities if that is what the developer prefers to pick from. The really
          great thing about this discussion is that it's raised an area of the current
          implementation that may need tweaking to make it more in the middle.

          Originally posted by Sylvain
          A few more comments.

          Drop the database sub-package. Python has excellent ORM like
          SQLAlchemy and dejavu. The former is really well spread and there
          isn't any reason to ask developers to learn a new way of setting up
          their stack. Keeping the database package only adds up more work for
          little added value. Let people use their own choice of package.
          SQLAlchemy's syntax is rather close to the one describe as well.
          Russ> Gonna have to disagree here, this package is very important for the reasons
          I outlined previously in terms of spring offering common abstractions around different
          libraries. We're not providing another ORM solution here, this is one of those
          abstractions that makes it a simple choice for a developer to use any of a number
          of different underlying technology solutions in a consistent manner. In fact, I'd
          argue that there might be a case for an ORM abstract not unlike the HibernateTemplate
          and NHibernateTemplates in Spring Java and Spring.NET respectively. But this is
          not what this package is doing, it is providing convenience and library agnostic
          methods to interact with data.

          Originally posted by Sylvain
          I'm rather feeling the same way towards the web package but still not
          yet sure about that one.
          Russ> Well I'm certainly open for discussion there, but maybe now I've
          explained the goals of Spring as the hybrid framework/library it might cast a different
          perspective on this?

          Originally posted by Sylvain
          Focus on what makes Python Spring different: aop, remoting, IoC, security.


          So there you go, sorry for the long email but I thought I needed to
          make those points clear from the start. This is no reflection on your
          great work Greg. It's just a point of view

          Hopefully I didn't sound too harsh either. Russ knows I sometimes use
          the wrong approach but always for making things better if i can
          Russ> Not harsh at all! All good questions and for me this is a great learning
          curve from a python perspective, as well as probably a learning curve for everyone
          on some of the underlying reasons that Spring is the way it is

          Originally posted by Sylvain
          - Sylvain
          Russ> Thanks for the feedback Sylvain! This is all great stuff and will help
          us drive forward Spring Python. I think you just raised some good questions that
          most python people would have coming to the framework.

          Of course all of this is just my thoughts and I'm no pythonista as you can probably
          tell. Greg, you're the project lead so ultimately your vote is the biggie -
          what are your thoughts?

          Cheers,
          Russ
          Last edited by gregturn; Aug 28th, 2008, 03:41 PM.

          Comment


          • #6
            Another followup from Russ to Sylvain

            A little background here too. Spring Security uses a filter chain to apply security
            concerns, as described here:

            http://static.springframework.org/sp...e.html#filters

            This is what Greg has implemented. Is there a WSGI standard way to provide these
            sorts of filters Sylvain?

            By the way, I'd love for these conversations to be pushed to the public forums
            that the Spring Python project will have really soon now. Does anyone have any issues
            with taking the summaries of these conversations and pushing them to the forums
            for all to see once I get that service in place?

            Cheers,
            Russ
            Originally posted by Sylvain
            ----- Original Message -----
            From: "Sylvain Hellegouarch" <[email protected]>
            To: [email protected]
            Cc: "russell miles" <[email protected]>
            Sent: Friday, August 8, 2008 9:16:13 AM GMT +00:00 GMT Britain, Ireland, Portugal
            Subject: Re: Hello

            One more thing. I thought about why the PetClinic was causing so much
            problem with CherryPy 3 and I believe it's because the Spring filters
            are not WSGI middlewares per nature.

            They could be applied from within a WSGI middleware or a CherryPy 3
            tool but themselves are not WSGI middleware.

            They are just functions to be applied at some stage of the request
            processing but are not part of the HTTP stack.

            Greg, we'll need to discuss this

            - Sylvain
            Last edited by gregturn; Aug 28th, 2008, 03:42 PM.

            Comment


            • #7
              Sylvain responds to some of Russ's comments.

              Originally posted by Russ
              > Russ> Hmm, not sure I agree here. @Component is meant to distinguish, at
              > the class level, that a particular class results in one Spring-managed
              > object. To this effect, I really like the fact that you just have to see
              > the @component syntax and know that this class results in something
              > managed by Spring. However, decorators are not supported at the class
              > level, and that does feel like a disconnect and something that might need
              > some more thought around...
              I understand your point. In fact CherryPy has such annotation with its
              @expose decorator that tells CherryPy whether or not a method in a class
              can be considered when matching a URL to an object. Basically the two
              snippets below are equivalent:

              Code:
              class User(object):
                  @cherrypy.expose
                  def search(self, userId):
                      ...
              
              
              class User(object):
                  def search(self, userId):
                      ...
                  search.exposed = True
              They are equivalent because the only thing the decorator does is to set
              the .exposed attribute to True (methods are objects in Python and thus can
              have attributes).

              I therefore see what the @component decorator is trying to convey but I
              think I'm not really agreeing with the implementation which does more than
              purely annotating the method.


              Originally posted by Russ
              > Russ> Not sure I understand the meaning of "... lazily calls"
              Can you
              > explain that a bit more?
              The @component decorator calls the decorated method which as the inline
              comment says "Eagerly fetching ...". I don't quite understand the
              point of
              such pre-loading each components rather than lazily call them when they
              are first requested. That's why my snippet was calling the methods from
              the __init__(). It's basically what is done there but explicit is better
              than implicit IMO.
              Originally posted by Russ
              Code:
              > class PetClinicClientAndServer(object):
              >     def __init__(self):
              >         self.connectionFactory()
              >
              >     def connectionFactory(self):
              >         connFactory = factory.MySQLConnectionFactory()
              >         connFactory.username = "springpython"
              >         connFactory.password = "springpython"
              >         connFactory.hostname = "localhost"
              >         connFactory.db = "petclinic"
              >         return connFactory
              >
              >
              > Russ> Hmm, yeah but this breaks all sorts of concerns. What @Component was
              > really trying to do was flag a particular class as being a candidate for
              > being a Spring-managed object. I think we might have lost that point here.
              > The point was not really to call that factory method, more to let Spring
              > know "Hey, here's an object I want you to instantiate!"
              I think that's one point I'm not a fan of. It does make sense when loading
              the component structure from XML but when you describe your component in a
              class, why not calling each components as you see fit explicitly from your
              constructor rather than doing introspection there?

              I do understand and even see the point of annotating a method for
              readability purpose, much like CherryPy developers are used to the @expose
              decorator. However asking that decorator to be more than that isn't as
              understandable.

              Originally posted by Russ
              >
              > Russ> I also find that libraries themselves are intrusive as you have to
              > understand and couple your code to their specific usage, which can make it
              > hard to move from one library implementation to the next of exactly the
              > same functionality. If you're lucky, this results in small code changes,
              > if you're unlucky, an entire tier of your enterprise app needs to
              > change... and this was the case often before Spring. Because of this
              > challenge people tended to create their own vendor-neutral abstractions
              > around libraries, which was fine but again code that was plumbing rather
              > than code that made them money. Spring took that headache away by acting
              > as an abstraction around those common pieces of functionality. This is
              > where Spring has some qualities of a library as it provides a facade
              > around common concerns, such as data access, that mean you can plug-in
              > different implementations, often through configuration only, that don't
              > affect the rest of your application. The core library/api remains the
              > same, and if you need to get at more of the specifics of an implementation
              > then you can. This is where the template pattern is used, such as in the
              > database package. The idea with Spring is not to provide a data access
              > technology, but to make it simple, through the use of the template
              > pattern, to work with a number of different data access technologies in a
              > consistent way and for those advanced cases the template provides access
              > to the underlying specifics of a data access technology. The idea is "all
              > the convenience when you can, all of the power when you need it".
              >
              > You can think of Spring as somewhere between an intrusive framework (bad),
              > and a an inherently intrusive library (equally as bad) - it tries to hit
              > that sweet-spot.
              >
              > Libraries that are well designed usually don't have that issue. They
              > offer a functionality but let the developer decide how he/she wants to
              > apply it.
              >
              > Russ> True, but hopefully my point above shows why even that is not really
              > enough.
              It does. That's why I was saying "well designed libraries". It's
              perhaps
              one of the hardest task for a developer. Probably the fact I'm new to
              Spring makes me want to bend it so that it fits my expectations rather
              than trying to adapt myself a bit so that I can see its power. Time will
              tell.


              Originally posted by Russ
              > Russ> I would agree here, but this is why Spring is seen as being
              > different from the crowd. Spring is, right now, THE enterprise framework,
              > and it is specifically for enterprise applications that it is targeted.
              > But I definitely want to talk around this a bit more. My take is Spring is
              > half way between a framework and a library, and THAT is the reason it has
              > been so hugely popular. Rather than forcing people to work a certain way,
              > Spring offers facilities that implement best practices and get people
              > being more productive, while you get to pick and choose which of those
              > facilities you want to apply. For example, it is totally feasible to not
              > use Spring for dependency injection at all... but if you do then there are
              > a bunch more facilities you can make use of.
              That's good to hear

              Originally posted by Russ
              > Russ> Gonna have to disagree here, this package is very important for the
              > reasons I outlined previously in terms of spring offering common
              > abstractions around different libraries. We're not providing another ORM
              > solution here, this is one of those abstractions that makes it a simple
              > choice for a developer to use any of a number of different underlying
              > technology solutions in a consistent manner. In fact, I'd argue that there
              > might be a case for an ORM abstract not unlike the HibernateTemplate and
              > NHibernateTemplates in Spring Java and Spring.NET respectively. But this
              > is not what this package is doing, it is providing convenience and library
              > agnostic methods to interact with data.
              I understand the point yet I don't believe it's the right approach in
              Python Spring. I shouldn't have used the term of ORM as it muddies the
              discussion. I invite you guys to have a look at this project and see
              whether or not that could fit the bill:

              http://www.aminus.net/geniusql

              I'm mentioning it because it has a solid history in that regards.


              Thanks Russ for the feedback. It's cool that you pushed back like that

              - Sylvain
              Last edited by gregturn; Aug 28th, 2008, 03:42 PM. Reason: Put in code tags.

              Comment


              • #8
                Sylvain responds to comment about the filter chain

                Originally posted by Russ
                > A little background here too. Spring Security uses a filter chain to apply
                > security concerns, as described here:
                >
                > http://static.springframework.org/sp...e.html#filters
                >
                > This is what Greg has implemented. Is there a WSGI standard way to provide
                > these sorts of filters Sylvain?
                Oh I've understand the purpose of those filters and I'm not arguing with
                them. However, I believe the are orthogonal to WSGI and could be
                disconnect from the WSGI interface entirely.

                Originally posted by Russ
                >
                > By the way, I'd love for these conversations to be pushed to the public
                > forums that the Spring Python project will have really soon now. Does
                > anyone have any issues with taking the summaries of these conversations
                > and pushing them to the forums for all to see once I get that service in
                > place?
                I don't have much issue though I would remove the notion that I'm speaking
                for the entire Python community. Everyone has a slightly different opinion
                on what is "pythonic"

                - Sylvain
                Last edited by gregturn; Aug 28th, 2008, 03:43 PM.

                Comment


                • #9
                  Russ - usage of terms pythonic / thoughts about WSGI mechanisms

                  Consider the notion removed

                  On the subject of the filters, is there no concept in WSGI (and admittedly I'm
                  new to it, but am an old hand at HTTP stacks) of such a filter? Can you elaborate
                  more on why you don't believe they are a disconnect from the WSGI interface?

                  Also, are there mechanisms in WSGI that would offer such cross-cutting concerns,
                  such as the security chain, to be applied to the HTTP request processing stack?

                  Originally posted by Sylvain
                  ----- Original Message -----
                  From: "Sylvain Hellegouarch" <[email protected]>
                  To: "Russell Miles" <[email protected]>
                  Cc: [email protected], [email protected]
                  Sent: Friday, August 8, 2008 10:35:05 AM GMT +00:00 GMT Britain, Ireland, Portugal
                  Subject: Re: Hello


                  > A little background here too. Spring Security uses a filter chain to apply
                  > security concerns, as described here:
                  >
                  > http://static.springframework.org/sp...e.html#filters
                  >
                  > This is what Greg has implemented. Is there a WSGI standard way to provide
                  > these sorts of filters Sylvain?

                  Oh I've understand the purpose of those filters and I'm not arguing with
                  them. However, I believe the are orthogonal to WSGI and could be
                  disconnect from the WSGI interface entirely.

                  >
                  > By the way, I'd love for these conversations to be pushed to the public
                  > forums that the Spring Python project will have really soon now. Does
                  > anyone have any issues with taking the summaries of these conversations
                  > and pushing them to the forums for all to see once I get that service in
                  > place?

                  I don't have much issue though I would remove the notion that I'm speaking
                  for the entire Python community. Everyone has a slightly different opinion
                  on what is "pythonic"

                  - Sylvain
                  Last edited by gregturn; Aug 28th, 2008, 03:43 PM.

                  Comment


                  • #10
                    Russ - more inlined comments, mentions fluent API idea - Part 1

                    More comments inline, demarcated with Russ>

                    == Sylvain's earlier email ==

                    Originally posted by Sylvain
                    > Russ> Hmm, not sure I agree here. @Component is meant to distinguish, at
                    > the class level, that a particular class results in one Spring-managed
                    > object. To this effect, I really like the fact that you just have to see
                    > the @component syntax and know that this class results in something
                    > managed by Spring. However, decorators are not supported at the class
                    > level, and that does feel like a disconnect and something that might need
                    > some more thought around...

                    I understand your point. In fact CherryPy has such annotation with its
                    @expose decorator that tells CherryPy whether or not a method in a class
                    can be considered when matching a URL to an object. Basically the two
                    snippets below are equivalent:

                    Code:
                    class User(object):
                        @cherrypy.expose
                        def search(self, userId):
                            ...
                    
                    
                    class User(object):
                        def search(self, userId):
                            ...
                        search.exposed = True
                    They are equivalent because the only thing the decorator does is to set
                    the .exposed attribute to True (methods are objects in Python and thus can
                    have attributes).

                    I therefore see what the @component decorator is trying to convey but I
                    think I'm not really agreeing with the implementation which does more than
                    purely annotating the method.
                    Russ> I think we are agreeing her; not sure but possibly. In Spring there is
                    the concept of a Spring-managed object, and it is this concept that @Component is
                    meant to reflect. So in fact a function decorator doesn't make sense, because
                    what you're really looking to do is provide a way, beyond XML, to indicate that
                    an object should be instantiated and managed by Spring, making it a candidate for
                    AOP and DI for example.


                    Originally posted by Sylvain
                    > Russ> Not sure I understand the meaning of "... lazily calls"
                    Can you
                    > explain that a bit more?

                    The @component decorator calls the decorated method which as the inline
                    comment says "Eagerly fetching ...". I don't quite understand the
                    point of
                    such pre-loading each components rather than lazily call them when they
                    are first requested. That's why my snippet was calling the methods from
                    the __init__(). It's basically what is done there but explicit is better
                    than implicit IMO.

                    === To be continued ===
                    Last edited by gregturn; Aug 28th, 2008, 03:43 PM. Reason: Put in code tags

                    Comment


                    • #11
                      Russ - more inlined comments, mentions fluent API idea - Part 2

                      The rest of Russ's inlined comments, and mention of fluent API
                      ==================
                      Originally posted by Sylvain
                      Code:
                      > class PetClinicClientAndServer(object):
                      >     def __init__(self):
                      >         self.connectionFactory()
                      >
                      >     def connectionFactory(self):
                      >         connFactory = factory.MySQLConnectionFactory()
                      >         connFactory.username = "springpython"
                      >         connFactory.password = "springpython"
                      >         connFactory.hostname = "localhost"
                      >         connFactory.db = "petclinic"
                      >         return connFactory
                      >
                      >
                      > Russ> Hmm, yeah but this breaks all sorts of concerns. What @Component was
                      > really trying to do was flag a particular class as being a candidate for
                      > being a Spring-managed object. I think we might have lost that point here.
                      > The point was not really to call that factory method, more to let Spring
                      > know "Hey, here's an object I want you to instantiate!"

                      I think that's one point I'm not a fan of. It does make sense when loading
                      the component structure from XML but when you describe your component in a
                      class, why not calling each components as you see fit explicitly from your
                      constructor rather than doing introspection there?
                      Russ> In Spring, a component's lifecycle is managed by Spring (this is so
                      that it can do DI, AOP, transactional support, LOTS of stuff basically). So this
                      is in fact a very real and purposeful deviation. In a Spring application, Spring
                      creates and wires together the objects involved in an application. Each component
                      is NOT responsible for discovering its dependencies, that concern is deliberately
                      separated out.

                      Russ> In fact, this makes me wonder if we need an @Component decorator at all...
                      One of the things that are hot in SpringSource right now is creating fluent apis
                      that drive the configuration (creating and wiring together the different components).
                      I have an idea that this approach will not only render some of the @Spring annotation
                      approach less attractive but could well be the way forward... and in fact makes
                      even more sense when you're using a dynamic language like Python. I'll start
                      another email thread on that, but just a note here saying that it might be that
                      the @Component concern here goes away if we start to consider driving the configuration
                      of the application using a python-friendly DSL.

                      Originally posted by Sylvain
                      I do understand and even see the point of annotating a method for
                      readability purpose, much like CherryPy developers are used to the @expose
                      decorator. However asking that decorator to be more than that isn't as
                      understandable.

                      >
                      > Russ> I also find that libraries themselves are intrusive as you have to
                      > understand and couple your code to their specific usage, which can make it
                      > hard to move from one library implementation to the next of exactly the
                      > same functionality. If you're lucky, this results in small code changes,
                      > if you're unlucky, an entire tier of your enterprise app needs to
                      > change... and this was the case often before Spring. Because of this
                      > challenge people tended to create their own vendor-neutral abstractions
                      > around libraries, which was fine but again code that was plumbing rather
                      > than code that made them money. Spring took that headache away by acting
                      > as an abstraction around those common pieces of functionality. This is
                      > where Spring has some qualities of a library as it provides a facade
                      > around common concerns, such as data access, that mean you can plug-in
                      > different implementations, often through configuration only, that don't
                      > affect the rest of your application. The core library/api remains the
                      > same, and if you need to get at more of the specifics of an implementation
                      > then you can. This is where the template pattern is used, such as in the
                      > database package. The idea with Spring is not to provide a data access
                      > technology, but to make it simple, through the use of the template
                      > pattern, to work with a number of different data access technologies in a
                      > consistent way and for those advanced cases the template provides access
                      > to the underlying specifics of a data access technology. The idea is "all
                      > the convenience when you can, all of the power when you need it".
                      >
                      > You can think of Spring as somewhere between an intrusive framework (bad),
                      > and a an inherently intrusive library (equally as bad) - it tries to hit
                      > that sweet-spot.
                      >
                      > Libraries that are well designed usually don't have that issue. They
                      > offer a functionality but let the developer decide how he/she wants to
                      > apply it.
                      >
                      > Russ> True, but hopefully my point above shows why even that is not really
                      > enough.

                      It does. That's why I was saying "well designed libraries". It's
                      perhaps
                      one of the hardest task for a developer. Probably the fact I'm new to
                      Spring makes me want to bend it so that it fits my expectations rather
                      than trying to adapt myself a bit so that I can see its power. Time will
                      tell.
                      Russ> Even well-designed libraries differ from each other and make it tricky
                      to move from one, say, data access library to another. This headache is aleviated
                      somewhat, for common interaction with data access for example, by providing a consistent
                      facade around whatever library is being used underneath. This is the job of the
                      database package.

                      Originally posted by Sylvain
                      > Russ> I would agree here, but this is why Spring is seen as being
                      > different from the crowd. Spring is, right now, THE enterprise framework,
                      > and it is specifically for enterprise applications that it is targeted.
                      > But I definitely want to talk around this a bit more. My take is Spring is
                      > half way between a framework and a library, and THAT is the reason it has
                      > been so hugely popular. Rather than forcing people to work a certain way,
                      > Spring offers facilities that implement best practices and get people
                      > being more productive, while you get to pick and choose which of those
                      > facilities you want to apply. For example, it is totally feasible to not
                      > use Spring for dependency injection at all... but if you do then there are
                      > a bunch more facilities you can make use of.

                      That's good to hear

                      > Russ> Gonna have to disagree here, this package is very important for the
                      > reasons I outlined previously in terms of spring offering common
                      > abstractions around different libraries. We're not providing another ORM
                      > solution here, this is one of those abstractions that makes it a simple
                      > choice for a developer to use any of a number of different underlying
                      > technology solutions in a consistent manner. In fact, I'd argue that there
                      > might be a case for an ORM abstract not unlike the HibernateTemplate and
                      > NHibernateTemplates in Spring Java and Spring.NET respectively. But this
                      > is not what this package is doing, it is providing convenience and library
                      > agnostic methods to interact with data.

                      I understand the point yet I don't believe it's the right approach in
                      Python Spring. I shouldn't have used the term of ORM as it muddies the
                      discussion. I invite you guys to have a look at this project and see
                      whether or not that could fit the bill:

                      http://www.aminus.net/geniusql

                      I'm mentioning it because it has a solid history in that regards.
                      Russ> It looks like a solid implementation of ORM, and I have no worries about
                      suggesting that we might want to offer integration with Spring Python. But one library
                      is not THE only solution, and that's something that Spring recognises and another
                      place it differs from other frameworks. Spring doesn't typically have an opinion
                      as to which technologies you use to implement a given concern, ORM in this case.
                      What Spring does offer is consistent integration with whatever technology you want
                      to use. So what we are really building with Spring Python is the ability for developers
                      to pick the library that they want to use for a given concern and then integrate
                      with it in a consistent way regardless of the complexities and specifics of the
                      underlying library. For example, if I wanted to use Geniusql for ORM, then Spring
                      would provide a factory to generate the required connections and provide a template
                      to interact with the ORM, using common convenience functions to make my code as
                      simple as possible. If I then wanted to use another ORM solution, I would grab the
                      factory for that technologies connections and create a template based on that technology.
                      My ORM savvy code would not need to change, but my config would change to plug-in
                      the new technology.


                      Originally posted by Sylvain
                      Thanks Russ for the feedback. It's cool that you pushed back like that
                      Russ> No problems. I'm certainly passionate about Spring and believe Spring
                      Python can be a really amazing addition to the portfolio (taking things even beyond
                      being an extension) and it's these sorts of discussions that will drive us in
                      that direction. Heated discussion is good, no discussion at all is bad is my motto.

                      Originally posted by Sylvain
                      - Sylvain
                      Last edited by gregturn; Aug 28th, 2008, 03:44 PM.

                      Comment


                      • #12
                        Russ talks more about a fluent API idea

                        Hi gents,

                        Some of the discussions today about @Component got me thinking about some of the
                        directions that the Spring framework is looking at (one of the big benefits of making
                        Spring Python an extension is that I get to share some of the insider info )

                        Ok, so the idea is that people are getting rapidly more tired with driving their
                        application's configuration using XML. The annotation approach is a halfway
                        house, but it introduces problems when the language doesn't support the annotation
                        placement you want to use, nor does it offer a very clean solution as annotations,
                        or decorators, themselves can be seen as introducing dependencies in your objects
                        that shouldn't be there.

                        One way to get around this was spearheaded by the Java Config folks, http://www.springframework.org/javaconfig.
                        This approach, while typesafe, is seen by a lot of people as a little cludgy, even
                        more magic going on and ultimately was something developed quickly in response to
                        the immediate need to offer a solution that wasn't XML. That might be a little
                        unfair, as some people love it, but it's not a direction I would want to take
                        us in as already there are movements internally to jump to a better approach...

                        Enter fluent apis. The classic competitive example of this in the Java world is
                        Guice, http://code.google.com/p/google-guice/. Guice offers a typesafe way of configuring
                        your application's components, coding directly in Java. It provides a limited
                        solution as it only supports DI, but it does offer an example of a fluent api that
                        neatly shows configuration driven by actual code (no magic involved, ok Sylvain?
                        )

                        So, would such a fluent api be a better approach for Spring Python, especially given
                        our knowledge that Spring generally is going in this direction (esp the Spring .NET
                        folks, they already have a Spring Extension called SharpConfig that will be creating
                        a dsl for configuring their container)?

                        Some of the benefits of providing this approach are:

                        1) Code completion in an editor. You can configure the Spring and know whether you've
                        called the right methods, rather than the disconnected approach that XML can sometimes
                        offer (Type safety is another benefit here, but that's not exactly a concern
                        with dynamic languages)

                        2) You configure in python. This might keep python people more happy as there is
                        less magic going on.

                        3) Leading off of 2, the config becomes easier to read particularly if it is a well-designed
                        fluent api. The concepts are likely to be the same regardless of whether you're
                        configuring in Java or Python, so it offers arguable an even easier transition from
                        one environment to another while keeping the spring pieces consistent.

                        4) Python as a language would make it really easy for us to create a great fluent
                        api, i.e. no need for semi colons to cludge up the expression of the language

                        5) We get a chance to really trail-blaze this. Since Python is such an ideal environment
                        for this approach, imo, we get to put this in place and essentially lead the other
                        Spring projects by example. This would be a big win for the project internally.

                        Ok, that's my two cents, any thoughts anyone?

                        Cheers,
                        Russ

                        Comment


                        • #13
                          Sylvain's response to fluent API idea

                          Originally posted by Russ
                          >
                          > Ok, that's my two cents, any thoughts anyone?
                          >
                          I think that's a good idea. Coming back to CherryPy it's something that
                          CP3 has brought with its tools API. Config value may be provided either in
                          a config file, a config dict or per page handler (via decorators or method
                          attributes) (read component in the Spring context) with a unified API.
                          (You can in fact used the different forms all the the same time and they
                          are computed at run time.

                          In any case it's propbably a good idea to escape from XML here. Developers
                          tend to dislike having to describe their architecture that way and the
                          only framework that I know has been doing it is Zope 3 and they haven't
                          really made the Python folks applause for that decision.

                          - Sylvain
                          Last edited by gregturn; Aug 28th, 2008, 03:44 PM.

                          Comment


                          • #14
                            Greg's response to all the comments from Russ and Sylvain

                            Hey guys,

                            Sylvain, I appreciate the feedback you have provided me. Russ, I also like having
                            the perspective of what Spring is targeting. I think we definitely have the ingredients
                            for finding this balance I think we all desire.

                            1. Regarding @component, this was inspired by reading http://blog.springsource.com/main/20...on-for-spring/,
                            which was out before Spring actually had a solution. I opened Spring Python ticket
                            https://springpython.webfactional.com/ticket/18, where you can see the issues I
                            ran into trying to implement something similar in python, and the frustrations I
                            had dealing with the difference between decorators and annotations. In python, decorators
                            are function calls, not meta-data like in java. Python's decorators can only
                            be applied to methods, not classes. So replicating @Configuration was out. I was
                            concerned that python decorators and java annotations were too distant that this
                            wasn't possible.

                            However, one day I had a revelation (and a little help using someone's decorator
                            library), and thanks to python's speedy nature, implemented a solution. Since
                            python doesn't have "beans", and since the IoC container was already
                            using the term "component", I swapped out Spring's @Bean annotation
                            for Spring Python's @component decorator (and dropped the capital letter). Part
                            of my revelation was realizing the key thing I was needing was PROTOTYPE vs. SINGLETON
                            spring beans. Translation, I wanted the option to either call a factory-style method
                            from the IoC POPO every time (PROTOTYPE), or only once and cache the results in
                            a container-specific dictionary (SINGLETON). Unfortunately, my sample applications
                            don't really demonstrate this feature, so I could understand any developer,
                            pythonista or not, not seeing what I was really shooting for.

                            Sylvain is correct in observing that @component by itself, i.e. with no arguments,
                            doesn't seem to do anything you couldn't already do in the __init__ method.
                            But that is because I looked up Spring's default configuration status when Spring
                            beans have no arguments. The default is pre-building every Spring bean when the
                            container is created. Lazy initialization and prototype are lifecycle options that
                            allow you to override this default. I made @component do the same behavior and pre-instantiate
                            every @component item in the container when the container is created. Currently
                            I have one optional argument (https://springpython.webfactional.co...icationContext),
                            which allows you to spec whether or not you get a cached copy or new copy every
                            time. I haven't dug into python enough to even determine if this is feasible
                            to have multiple optional arguments in a function decorator. I hope so, because
                            this opens the door in the future having the other options Spring has such as lazy-init,
                            auto-wire-candidate, etc.

                            2. Regarding the security filters, I was just learning the ropes of WSGI, and the
                            only reference I had from spring security was their API based on servlet filters.
                            I guess you could say I replicated the servlet filter APIs in python, and shoe-horned
                            them into WSGI in order to plug-in my security filters. Since I believe the purpose
                            of WSGI is to allow people to define middleware filters, so I very much would like
                            to line them up to work better in that way. One thing I was noticing, is that the
                            chain of middleware filters is different based on the URL pattern being matched,
                            and thus becomes dynamic. Every example I could find on google that showed me how
                            to wire a stack of WSGI middleware was static in configuration. I was trying to
                            configure singleton filters that weren't locked into a particular chain. Probably
                            needs to be refactored to be cleaner, but I think they need to EASILY be able to
                            be plugged into a WSGI server.

                            3. Regarding ORM and database templates, in my day job, I work with a data-centric
                            application that has almost 300 custom queries written. When I was first evaluating
                            spring (3 years ago?), JdbcTemplate, and HibernateTemplate, I tried to create mappings,
                            etc. to work with the ORMs. Those queries had things like uniions, distincts, group-bys,
                            and joins across linked databases. Either I didn't know how to use hibernate,
                            or hibernate was not built for that level of SQL query complexity. Either way, it
                            was easier for me to utilize JdbcTemplate and the ANSI SQL I already knew, rather
                            than try to convert the queries to HQL. When I picked up another application, and
                            had to write more queries, I continued using JdbcTemplate, and from time to time,
                            would send my source code to a DBA, allowing him to work on indexies based on my
                            queries. Since I can do left-outer-joins in my sleep now and that is what our DBAs
                            use, it is actually easier for me to stick with SQL rather than learn either HQL
                            or EJB-QL or some other ORM-specific query language. DatabaseTemplate is my shortcut
                            to getting database calls working fast in python. Actually, whether or not this
                            will work with Google App Engine is my #1 concern regarding running PetClinic there.

                            I understand that other developers aren't in the same situation I am in. Perhaps
                            they don't know as much SQL. Or their app is simple, or their entities were
                            designed by them, and not by DBAs. However, I have yet to see the value in abstracting
                            SQLAlchemy, SLQObject, or the other one Sylvain mentioned. Users can use those tools
                            right now in their python apps, and when necessary, plug-in a databaseTemplate call
                            should the need arise. I opened https://springpython.webfactional.com/ticket/15
                            to track this, but found little value in writing an abstraction layer. I recognize
                            that Spring probably gave a little bit of competitive heat on the Hibernate crew
                            to make their APIs more use friendly, and I think it worked (http://blog.springsource.com/main/20...r-jpatemplate/).
                            Since no one has indicated they need any ORM templates yet for Spring Python, it
                            has been moved to the bottom of the list.

                            4. XML support? I have a grand vision that one day, someone can port their java-based
                            spring application to python, point at the same XML file, and either edit nothing
                            (or do some simple find/replace), and have their python equivalent working. THAT
                            would be a quick sell to migrate over to python, ehh? What if Spring IDE was tweaked
                            to interface with that and python code? But, back to reality. I won't kill myself
                            to duplicate the XML format. I have a format that works good enough for now. In
                            the mean time I have made all the sample apps and wiki documentation point at the
                            DecorateBasedApplicationContext as the first example, since that is the mode I prefer.
                            POPOs over XML.

                            5. This is all great material to publish in the forum, since I want anything exposed
                            to Spring Python to understand my perspective, as well as any other potential contributer
                            or user.

                            Thanks again,
                            Greg
                            Last edited by gregturn; Aug 28th, 2008, 04:18 PM.

                            Comment

                            Working...
                            X