The rest of Russ's inlined comments, and mention of fluent API
Russ> In Spring, a component's lifecycle is managed by Spring (this is soOriginally Posted by Sylvain
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
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.
Russ> Even well-designed libraries differ from each other and make it trickyOriginally Posted by Sylvain
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
Russ> It looks like a solid implementation of ORM, and I have no worries aboutOriginally Posted by Sylvain
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.
Russ> No problems. I'm certainly passionate about Spring and believe SpringOriginally Posted by Sylvain
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