This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Spring Python and CherryPy 3

Aug 11th, 2008, 07:29 AM

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.

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.

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.

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

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.

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

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!"

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.

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?

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?

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?

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

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.

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

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

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?

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

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

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.

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

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.

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.

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, 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 tickethttps://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.