Spring Python and CherryPy 3

[gregturn]

The rest of Russ's inlined comments, and mention of fluent API
==================

> 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.

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.

> 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.

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.

- Sylvain