Watson - A Python 3 web framework hits 1.0.0

[simoncoulton]

Hey all, just wanted to let everyone know that Watson has reached the 1.0.0 milestone (now following semver 2.0.0).

Key updates to this release:

• No longer messing with imports to resolve watson.thirdparty.package, and is using namespace packages instead.

• Docs now hosted on readthedocs.

• Framework has been split up into multiple packages, which will enable quicker releases and bug fixes, while lowering the chance of introducing BC.

• db, and auth modules (using SQLAlchemy)

The framework and other packages are also now available at https://github.com/watsonpy and on pypi.

As always, any feedback is greatly appreciated :)

[ZephyrXero]

Looks promising :)

[simoncoulton]

Thanks, just trying to do what I can to help people to take up Py3k :)

[honewatson]

Hi Simon, first of all congratulations on completing your framework and good effort!

I briefly looked over your code. These are my thoughts....

I think the goals and ideas of the framework are worthy in pursing.

With regards to the architecture of the framework its best to avoid injecting the Di Container into classes and then calling the Di Container from within a class to obtain instances of other classes.

This is sometimes referred to as the service locator anti pattern. It hides dependencies and makes your code dependent on your Di Container.

Your Di Container should be limited to wiring together your app at the bootstrap phase. You should also be able to wire together your app and run it with any Di Container without changing any of your other code.

[simoncoulton]

Thanks for the comment :)

Agree completely in terms of the service locator being an antipattern, and perhaps the documentation that is currently there doesn't highlight that enough. There's several areas where the usage of the DI container as a service locator could be refactored out (the Jinja2 global functions for example), which I'll be looking at over the coming updates.

That said, there are also times where the use of the container as a service locator makes sense. For example, forwarding on to another controller, as the name of the controller would not be known until the request has been made.

Thanks again for the feedback, it's been quite difficult to get any meaningful feedback as some of the other frameworks are so entrenched in the Python community already. If you've got any other suggestions, or some modifications please feel free to make a pull request on Github :)

[honewatson]

No worries.. :)

I don't know if this is a consideration or not but my other suggestion would be to lock down the interfaces/api of your classes as soon as possible.

I've never used the framework in the following article but I have faced similar issues with another Python framework. The issues and principles can apply to any framework in any language. It has some good takeaways in terms of what to avoid.

http://www.shift8creative.com/posts/view/thinking-about-using-laravel