Transifex and Django
Dimitris Glezos
Hey all.
Long email ahead, hang tight. (:
Lately I've been spending quite some time experimenting with Django.
I'm sure most of you already heard about it, and for the rest I'll
just say that it's a fantastic Python web framework. Well designed,
with extremely good hackers behind it, vibrant community and stellar
documentation. A few bullet points about what I love about it could be
found on a blog post I wrote a few days ago:
http://dimitris.glezos.com/weblog/2008/09/21/experimenting-with-django/
I've noticed I'm not a person who changes his tools or habits often. I
tend to query a lot before deciding, and then stick with the choice
with no regrets. I'm using Fedora from the times it was named RH 6.2.
It took me many years to migrate from PHP to Python, and when I
started Tx in Python my co-workers and customers were wondering why
the hell a classic PHP web developer would switch. (Now I just say I
wish I did it earlier).
Lately I started wondering how would Tx be if it were written in
Django. I know that this idea will make a few people nervous (and maybe
angry?) but I think we should investigate what benefits could we have,
and whether they are important enough to make a transition worth it,
along with everything it brings with it.
We have already invested a lot in TG and everyone trusted that
investment and invested themselves more, so it's not an easy decision.
But I'm starting to believe it's a good one.
Why, oh why?
------------
So why should we consider migrating to Django? Here are my thoughts,
accumulated from the past months of coding and past weeks of testing
with new Tx code.
Django is different than most of the other popular Python frameworks in
the sense that it has no dependencies on other libraries. This makes
every component 'fit' in the best possible way with the whole philosophy
of the project. For example, the model provides forms, validation,
widgets, and validation, and one feels there's one way to do something
and one place to put a piece of code.
I believe our development pace will increase. A lot. Adding new features
in Django is usually like adding lego pieces. With only 400 lines of
Python code I had a working website with CRUD interfaces for 2 models
with markdown support, tags, search, feeds, contact form. Reusable
Django apps are all around the place. OpenID support is like 3 lines of
Python code. 15 for email notifications.
By developing our features as applications themselves, we can have other
projects re-use our components (like the statistics, the VCS abstraction
layer, etc). More contributors on our codebase.
Because of the separation and abstraction layers, the code is cleaner.
In Django there are no 'controllers', really. Just some small code that
decides what to display to the user (called views). It's a whole new
level of code cleanless, really.
It's a whole lot more fun. Both me, Christos and Diego are enjoying it
much more (Diego started learning Django a week ago). This is because of
all the above (and more) reasons, but also because the community is
extremely supportive (on IRC now, people on the channels: #turbogears
42, #django 529).
Django's documentation is excellent and learning it by reading the free
online book (djangobook.com) and the reference documentation
(docs.djangoproject.com) is quite fun. An experience in Python & TG, and
a good existing codebase makes adding features almost trivial.
Finally, it's a great opportunity to get rid of some ugly code I've
written when I was still learning the basics of Python (take a look at
`util.py` to take an idea). :-)
Oh, and a potential good point is also that I heard that the folks over
at Translate Toolkit are considering porting Pootle to Django too.
How?
----
The biggest challenge is probably to prepare something to base our stuff
from, so extending it will make things be a lot easier. Now, because
Linus said it best, "shut up and show me the code", I started
experimenting with such a base.
I think during the discussions "What would it take to move?" between me,
Christos and Diego and a few (read: many) beers, most of the
heavy-lifting of moving to the new architecture has been made.
The goal was to experience first-hand the assumptions I'm making and
have something good for a base. Diego has moved to Greece for a couple
of months and we're working together on in full-time for the past days.
The biggest challenges on our roadmap are statistics, user
registrations, and CRUD interfaces to our models. So we started with
these. I'll give a hint by saying the development results so far have
been astounding. Attaching a couple of screenshots as eye-candy.
We'll having something to show in a few days.
/me *excited* (:
-δ
--
Dimitris Glezos
Jabber ID: gle...@jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/
"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--
Toshio Kuratomi
> Hey all.
>
> Long email ahead, hang tight. (:
>
> Lately I've been spending quite some time experimenting with Django.
> I'm sure most of you already heard about it, and for the rest I'll
> just say that it's a fantastic Python web framework. Well designed,
> with extremely good hackers behind it, vibrant community and stellar
> documentation. A few bullet points about what I love about it could be
> found on a blog post I wrote a few days ago:
This looks like fun for you guys :-)
Mark Ramm made a good keynote about the possible downside of Django's
heavy integration leading to more Zope2-ish frameworks at the recent
DjangoCon that I think is up on youtube (lmacken would know) but I'm not
keyed into the Django community so I don't know if they took it
seriously or not. As long as they see the danger, I think they'll have
a fine framework that continues to grow by leaps and bounds.
As someone who's probably only going to have a tiny bit of actual code
in transifex, I'm most interested in how well/easy it will be to have
Django talk to other programs over http. The links you showed me the
other day look promising but not quite as easy as TurboGears. (Although
TurboGears is so open, that we have to work out some conventions to make
sure we do things in the best manner rather than having the restrictions
added to us in code.)
I have a pair of documents on how we want web services to tlak to each
other in Fedora although we haven't finished porting any of our apps to
those standards yet::
https://fedorahosted.org/python-fedora/wiki/doc/service
https://fedorahosted.org/python-fedora/wiki/doc/client
Do you think Django can do the things described there? Do you think
there's a better way to do them cross-framework now that you have some
Django experience as well?
-Toshio
Stéphane Raimbault
Dimitris and me have talked about this migration on IRC and he sent to me a snapshot of the current Transifex code based on Django for reading.
So, I found a bit rude to suddenly rewrite the code but now I'm ready to switch to Django!
Stéphane
Dimitris Glezos
> Dimitris Glezos wrote:
>> Hey all.
>>
>> Long email ahead, hang tight. (:
>>
>> Lately I've been spending quite some time experimenting with Django.
>> I'm sure most of you already heard about it, and for the rest I'll
>> just say that it's a fantastic Python web framework. Well designed,
>> with extremely good hackers behind it, vibrant community and stellar
>> documentation. A few bullet points about what I love about it could be
>> found on a blog post I wrote a few days ago:
>
> This looks like fun for you guys :-)
>
> Mark Ramm made a good keynote about the possible downside of Django's
> heavy integration leading to more Zope2-ish frameworks at the recent
> DjangoCon that I think is up on youtube (lmacken would know) but I'm not
> keyed into the Django community so I don't know if they took it
> seriously or not. As long as they see the danger, I think they'll have
> a fine framework that continues to grow by leaps and bounds.
I think the message was taken very seriously, I understood the keynote
was considered very valuable. There are two ways to see the whole
issue, which are "Django should be able to use outside components like
SQLa" and the opposite, like "Other projects should be able to use
Django's components (eg. ORM)". The latter is more important for the
Python framework ecosystem, and from what I understand, people agreed
that the latter should definitely improve.
> As someone who's probably only going to have a tiny bit of actual code
> in transifex, I'm most interested in how well/easy it will be to have
> Django talk to other programs over http. The links you showed me the
> other day look promising but not quite as easy as TurboGears. (Although
> TurboGears is so open, that we have to work out some conventions to make
> sure we do things in the best manner rather than having the restrictions
> added to us in code.)
>
> I have a pair of documents on how we want web services to tlak to each
> other in Fedora although we haven't finished porting any of our apps to
> those standards yet::
>
> https://fedorahosted.org/python-fedora/wiki/doc/service
> https://fedorahosted.org/python-fedora/wiki/doc/client
>
> Do you think Django can do the things described there? Do you think
> there's a better way to do them cross-framework now that you have some
> Django experience as well?
Not sure. I could have a better picture when starting working on the
API and the CLI I guess.
The documents you put together will definitely help, thanks Toshio.
-d