Aug 11th, 2008, 06:57 AM
A fluent DSL for configuring Spring Python?
We had some offline discussions today about ATComponent and it got me thinking about some of the directions that Spring Python could take in order to take full advantage of its language.
Ok, so the idea is that although offering XML configuration is a great thing for anyone moving from one Spring implementation to another, there are some drawbacks especially when you consider the perspectives of the Python community. Decorators take us a step closer, but there's still a little magic going on that might feel a little uncomfortable to a python person.
So, the question is would a fluent api be a better approach for Spring Python.
Some of the benefits of providing this approach are:
- Code completion in an editor. You can configure the Spring and know whether you've called the right methods immediately.
- You configure in python. This might keep python people more happy as there is less magic going on.
- 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.
- 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 kludge up the expression of the language
Ok, that's my two cents, any thoughts anyone?
Aug 11th, 2008, 10:48 AM
I think moving toward a DSL is a good idea. As much as I love XML for data processing, I believe XML for application configuration is quite often abused cumbersome. I don't think aside from Zope 3 there is any framework in the Python world that uses XML in such fashion. I can't guess whether or not that decision did Zope any good.
A proper DSL in Python would make it easier for Python developers to get hooked by Spring Python while probably keeping on board Spring Java developers wishing to try something new.
I want actually to make a parenthesis about one current aspect of Spring Python that made me stop. Spring Python implements the Spring filter mechanism as WSGI middlewares. WSGI middlewares can be nested in a way that felt natural for the filter API and the rationale was sensible from Greg's part.
However, like the Spring Python homepage says, Spring is not specifically a web framework and deciding to use a protocol dedicated to the web (WSGI) for a task (filtering) that could be applied outside of a web application may be confusing. That's why it feels sensible to me that we migrate the filters to the DSL you suggested Russ. That would keep the framework's design more consistent.
Many web frameworks, like Pylons, made the decision to follow WSGI all the way through in their design. Others, like CherryPy chose on the other hand to provide more or less their own DSL while supporting WSGI middlewares, but probably as a second class citizen. My point here is not to judge which made the right decision but rather to offer them as showcase of how their decision impacted their design and the resulting API.
If, we were deciding to for a DSL for all aspects of Spring Python, I think looking at how CherryPy designed and implemented its plugging interface could be interesting. Just as a matter of inspiration.
Tags for this Thread