It has been too long.
Today alpha2 is ready.
Instead of having separate fields for currency id and quantity, I wanted to combine those into one widget which would be more drupalish. Looking into Drupal's Field API it seemed that widgets were applied only to Field API fields, so I bit the bullet and defined a new field, called 'worth' with two columns, currency ID and quantity, with it's own widget. As the module installs it attaches the field to the transaction entity. Field API fields have excellent views integration. This was all a lot of trouble but we now have:
- A proper field with a widget for entering values on forms and displaying values
- A field denoting price or value which can be added to any entity type
- The ability to have several values per entity. This means we can do single payments in a mix of currencies.
Having agonised with the Belgians about displaying system stats, user stats, performance stats, time periods, trading categories, visualisations, etc, and coming to no conclusions about what was required, I decided to drop any kind of storage of aggregated data. In version 2 I stored user totals, and a big blob of preprocessed transaction data, but no kind of preprocessing helps in all circumstances. Looking closely at views 3 I started to realise the power of the new group by feature. If the data could just be stored in the right columns we could pull out all we need dynamically using views. So there is now a transaction index table which is designed for grouped queries and which is very powerful. What we need now is more work on the charts module, to make the data pretty.
I wanted the data to work with taxonomy as well. Transactions, like offers and wants can go in categories which help monitors to understand what is happening. Drupal 7 taxonomy requires an index table to be exposed to views, and what's provided only works on the node entity. I started work on a taxonomy_transaction_index module but fortunately found a taxonomy_entity_index module which is nearly ready.
Finally I've simplified the currency permissions system, though there is more to do. For each currency, for each transaction operation (view, update, delete), and for each transaction state, the currency owner specifies from a dropdown which function determines whether the operation is permitted. This is of course extendable using hooks.
Time to turn my attention back to Community Forge, where we are doing some improvements and restructuring to make a discreet set of tools based on the one 'custom' module we use at the moment. I'll be starting to test the alpha in soft situations, but it will be a good while before I make the upgrade path from drupal 6 to 7.
Comments