So Gaëtan and I decided that it was time to put an end to OpenHex and go separate ways. Even if we didn't achieve what we were aiming for, it was a nice trip and a very interesting experience nonetheless.

I will still be active in the python business and Gaëtan is still looking for an interesting job.

While our Rapid Web and Desktop Application Development framework will most likely decay in the heaven of aborted free software projects, we will continue to provide some limited support for relatorio and Elixir.

Most of our domain names (openhex.com, .be, .net, .eu) will disappear over time (ie won't be renewed next year), though openhex.org will stay up and running for the foreseeable future.

Since we released a new version of relatorio (our openoffice templating tool if you never heard of it) yesterday, I took this opportunity to install trac's account manager plugin. It was surprisingly easy (I had memories installing the mercurial plugin where I had to debug the code and so on) and works like a charm !

So from now on you can register yourself on our trac and use your own login/password to login, which means you can get notifications when there are changes on content you are monitoring.

PS: On a side note, I started toying with the whole microblogging stuff, you'll find me on identi.ca.

I am quite happy to inform you that relatorio is now packaged in the debian distribution !

We should make a release quite soon, since there is a bug fixing a huge regression on py:when tags.

Today, somebody asked me if Relatorio could generate sheets (aka tabs) dynamically. We had never done so and I did not know if it would work. It turns out it works nicely out of the box. The trick is to create a sheet with a <relatorio://for each="xxx"> link, then the sheet(s) you want repeated, then an empty sheet with only a <relatorio:///for> link.

Unfortunately, the name of the sheets created this way cannot be set dynamically so far. Instead, the first sheet so create will have the name of the repeated sheet and subsequent sheets will be named automatically by OpenOffice: TableXX

If anybody want to try it for himself, I've added a demo of sheet looping to the examples directory of Relatorio...

Here is a post I have started to write a long time ago but always postponed its completion...

Reading Elixir's mailing list and some comments about Elixir on various blogs, I came to realize that many people don't get what the real goal of Elixir is. To be honest, I didn't realize it myself until a couple months ago.

Sure, it abstracts some of the little details, but this has never been a goal in itself and is only a consequence of the goal. The initial goal was only to provide a declarative syntax. This goal is now also filled by the SQLAlchemy built-in declarative extension.

But what differentiate Elixir from declarative is its ability to generate columns (and other structures) and thus save people from repetitive declarations, both by providing built-in constructs for common patterns as well as providing a way to define their own patterns. For example, if you declare a many-to-one relation between a source entity and a target entity, you nearly always want to add a column in the source entity table with a foreign key constraint to the primary key column of the target entity table. When using pure SQLAlchemy, you have to declare the relationship and the column separately as in:

class Address(Base):
    __tablename__ = 'addresses'
    id = Column(Integer, primary_key=True)
    email_address = Column(String, nullable=False)
    user_id = Column(Integer, ForeignKey('users.id'))
    user = relation(User, backref=backref('addresses', order_by=id))

while in Elixir, this is done in one step, as in:

class Address(Entity):
    email_address = Field(String, required=True)
    user = ManyToOne('User')

So, yes, Elixir generates columns for you, but it is not (and never was) meant to hide them from you. It is just meant to save you the trouble to explicitly declare them over and over again. In short, Elixir is a sort of templating system for SQLAlchemy, but to best benefit from Elixir, you should know what it generates for you, and thus you should understand how "raw SQLAlchemy" works.

Ok, now that I said that I hear people coming with the complaint that in our documentation we don't explain clearly nor prominently what gets generated for all constructs. You would be right. I wonder why nobody ever complained about this... For what it's worth, I consider those issues bugs and I am committed to fix them in time. Of course, I would gladly accept patches adding such documentation.

As to better clarify my "vision" of Elixir's future, here are the "abstract" goals I have for Elixir:

• Implement more useful patterns,
• provide ways to customize all the provided patterns the exact way you want them,
• and do not get in the way when you do not want to use them at all.

The only limitation Elixir should add is the inherent declarative limitation, which is that you can't map the same class to different tables/selectables.

Incidentally, these are roughly the release criteria for Elixir 1.0, whenever that will happen.

After being in the pipeline for a while, my article about Elixir was published in the January issue of Python Magazine. To my surprise, it even made the cover. Maybe, the editors meant it as a little present for my birthday (which is today), who knows... ;-)

Within the article, I build a simple collection manager using Elixir, SQLAlchemy, CherryPy and Genshi. This is the first time I write an article for a technical magazine, and I would really love to hear what people think about it.

Update: As I have been given access to the PDF version of the issue, I noticed the "Useful/Related Links" of my article are not the ones I put there (and are completely unrelated -- I wonder where they come from?). For what it's worth here are the links that should have been included:

• Source code for the program built within the article - http://www.openhex.com/products/elixir/pymag
• Data Mapper Pattern - http://www.martinfowler.com/eaaCatalog/dataMapper.html
• Active Record Pattern - http://www.martinfowler.com/eaaCatalog/activeRecord.html
• REST - http://en.wikipedia.org/wiki/Representational_State_Transfer

Now I understand why there was not any hit on the page holding the application source code...

Update: The version they distribute now has been corrected.

Thanks to someone who let us know by email, we just realized the comment form on our blog has been broken for the last 2 months for people who were not using the "follow-up by email" feature. This is fixed now. Sorry for the inconvenience.

I'm quite happy to announce the new release of relatorio. Thanks to the sponsoring of b2ck, we added some nice features such as looping on columns in OOTemplates and the improvements in the closing/opening tag detection algorithm, many thanks to them !

Here is the full changelog:

• Added Text and XML Template to the TemplateLoader
• Splitted mimetypes and ids in the ReportRepository
• RelatorioStream now has a __str__ method
• OOTemplate: ChartTemplate can be included
• OOTemplate: Correctly handle content type in the table cells
• OOTemplate: Better closing/opening tag detection algorithm
• OOTemplate: Looping on columns now work in OOTemplates
• OOTemplate: Using compression

And here is a screenshot of the looping feature:

Well the colours are not great but I'm not the one to blame !

A few weeks ago we reached a nice milestone in the development of our own web application framework : openhexperience., and I did not even think to blog about it.

But first let me introduce openhexperience. This framework is constructed from the experience we have gathered once we were working at Tiny. There we worked on TinyERP (now OpenERP), but we did not want to make the same mistakes that we thought were made in this piece of software. So we decided to rewrite it from the ground up using all the nice goodies the python ecosystem provides and if necessary create the missing pieces.

Gaëtan worked on elixir (a thin layer on top of SQLAlchemy) so that we have an abstracted and easy to use layer on top of the database world. I created relatorio and now we can generate pretty reports. We are using genshi to generate the xml views that are sent to the client. The glue between all the components being a cherrypy server with a custom dispatcher so that we can access the resources in a REST way. To handle translations we opted for the UNIX approach of using gettext, this was made easy by babel and the translator filter of genshi. To all the contributors of all those projects, I have to give a big kudo : your code is a great source of inspiration.

To build our client, we choose the AJAX framework qooxdoo to have a cross-OS, easily deployable solution.

And as I said earlier we reached a nice milestone quite recently because for the first time, we began to mix all the pieces together and so here is the first screenshot:

For now, we still have a lot of work to do to reach a releasable state (some crucial features are yet to be done or integrated, there is no documentation yet, there are not nearly enough showcase modules, etc.), but it begins to look good and we are quite satisfied with the choices we did so far.

If you ever want to try out our framework the sources are available in our mercurial repository.

Since this is my first post on planet python: Hello !!

A few days ago, I commited a change that enables relatorio to output charts in png. I use PyCha as the plotting module since its graphics looked appealing and the syntax was simple enough to be used by lambda users. Since PyCha does not support negative values, I patched it and while I was working on it I also add a few features that I hope to see included upstream.

The nice stuff about this is that I can finally include a chart into an ODF file without to much hurdle, it works just like an image, the OpenDocument plugin will detect you are using a relatorio report and make the necessary call to create the chart.

This is all good and fine except that I don't like the way I templatize (is that a word) the chart: I use a genshi template of a yaml file like this one:

options:
    background: {hide: true}
    legend: {hide: true}
    padding: {bottom: 10, left: 70, right: 10, top: 10}
chart:
    type: pie
    width: 600
    height: 400
    dataset:
    {% for line in o.lines %}
      - - ${line.item.name}
        - - [0, $line.amount]
    {% end %}

When this file is generated with the relevant data, the options dictionary is transmitted to PyCha and the chart dictionary is then used to create the chart. Going through the yaml step feels like it is unnecessary but I fail to see how I can make this work without requesting the user to learn python.