Polishing

Last week I had unexpected complications trying to polish translations. Some things like content type names were almost a battle. I finished having to write my own widgets for displaying translated content type names using portal_types.getTypeInfo.

I preferred my own widgets for multi-selects also cause I did not find any of the default ones not needing javascript to function properly. Did I miss something?

Later I realized that the set up form I made about a month ago was not based on plone.z3cform but in formlib, so my new widget wasn't able to work there. I could create another widget (a formlib one) but instead I preferred to unify the code, and use plone.z3cform only, so I re wrote that form.
In that re-writting I seriously improved the way that data is managed, using an IDataManager provider instead of silly formlib handlers. I'm happy with that. Things looks much more clear now :)
Surprises not ended there. The template I had for the setup page wasn't working with a plone.z3cform.

For the selector page I also had to create a textwidget for Content types names translated.

With all those changes, I created a complete spanish translation that is now in the code.

I'm a little ashamed, but the work mentioned above consumed most of the last days work time. Anyways, I feel that the quality of the things re-done is higher. I'm feeling more comfortable every day with how development is going.

The other tiny thing I did was a more serious testing of the plone.app.batch functionalities with 3rd party content types.

Warning: I made some tiny changes in the installation profile. Re install plone.app.batch or you will find some broken links.

Take a look how is working plone.app.batch with Martin Aspeli Optilux Cinema content types:

The last thing I have to tell you is that I'm preparing a talk for showing plone.app.batch development inside the Google Summer of Code program for 8th Jornadas Regionales de Software Libre. Is one of the biggest (if not the biggest) south American free software event, and this year will be in Buenos Aires, Argentina. I hope to be giving the talk with the GSoC t-shirt :). Wish me luck.

Spanish Translation

Last week wasn't the most productive on the SoC, but I produced some new stuff.
Anyway, I'm doing 2-3 night hrs sessions this week days for recovering lost time.

What new things I have to report:

• Started Spanish translation. Not finished because the code and templates are still changing, but most of the work was in the setup things for allowing translations, than in the translation it self. I can use any other language translation help: Portuguese, French, Italian, Dutch, etc, etc, etc. Contact me in case you can.
• batch search form simplification again, taking off the ugly template based previous one, creating a plone.z3cform one.
• Tested the product to see how it behaves with non default Content Types. I played with Martin Aspeli optilude.cinemacontent contents. Working fine so far.

In case you are checking out new stuff, you will have to wait until next post, because I did not check in last work yet.

Here, how it looks like in spanish, and as you can see there are several details that need to be translated yet (like Content type' names)

Batch error handling

I enjoyed last weekend in my father's cottage in Los Reartes, coding, and coding. I didn't have internet connection in the town, but I enjoyed the productivity.

I submitted my survey Wednesday, had a short except morning work from home, and took the bus to the hills.

I worked basically on improving the validation and error handling of batch editions.
The work was put on:

• at2z3field adapter: now behaves more close to the ATField it's adapting: Datetime, Int, Float, Decimal, Bool, Object, Text zope schema field used when appropiate, Textline otherwise.
• Archetype fields validation run when validating the field for batch-editing.
• When some error on validation occured, a form only displaying errors is presented to user, letting him know that the other objects will be also edited when fixing the errors.
  

Sounds like a short thing, but took me lot of hours, mainly the first one, given and I could not find which interface Archetype fields are providing.

Reaching the first half

So, we arrived to the end of the first code period, and I think that more or less we have a good job done. During this week my mentor and I have to complete some forms and surveys... bureaucratic stuff that is part of the summer of code program. I do not enjoy doing that kind of things, but I understand why are those needed, so I'll do that without complaining :).

About what happened last week, I couldn't put the amount of hours I was wanting to, but anyways I could solve a couple of things.

First, I created some installation instructions for making easier to have people with time and energy testing plone.app.batch. Here the instructions are!

Second, we had the first issue created :). Thanks Matthew Wilkes for issuing it. I think I already fixed it, so I committed the patch and added it as resolved.

Third, I finally added a good more real set of tests to the product.

Fourth, I started to work on the error handling as we talked last week with Alex.
I have now the back-end behaving as we decided (i.e: if any error, no change is made). Now I have to work on the user interface Alex suggested. Shouldn't be hard, I just have to sit down and do some functional tests and templates work.

Fifth, Alex and I started the talk last Friday about what things expect to have implemented for the first version of plone.app.batch, and what things postpone. We could not finish that talk, but we are on that. I own him an email yet.

I feel that I can't make a weekly post without including some screen shot, so, here it is:

It works!

Ok, yes, there are many things to do, fix, implement and improve yet, but after a long weekend we have a very basic working version of plone.app.batch

Last Friday after talking with Alex we (he) decided to:

• do allow heterogeneous edition
• do not commit batch editions until no errors found

I still need to figure out what to do if someone want to edit a field for objects A and B, and the field has different types on those objects. What should we do? I think that we are going to handle this situation as an error.

During this weekend I found a tricky bug on the code I previously developed. I was modifying an interface on the fly, adding it the fields that the user was wanting to edit. Doing such a thing, was crashing if two users (or the same user, but in different windows or tabs) were doing a batch edit. Each was modifying the interface, so the last one was overwriting the previous one interface customization.

Yes, I know. You may be wondering "why this guy decided to modify the interface, instead of adding the fields to the form directly". The long answer is because looked the easy way using crud under the scenes. The short answer is the thing that you thought :).

I fixed that issue, adding the field to the z3cform directly , and in the same bunch of work I decided to store user configurations (like objects to edit, or field to edit) on user session instead of context annotations. Looks cleaner now.
With the code I have now, a user can't be doing 2 or more batch editions from the same context at the same time (the context of a batch edition is the folderish object where the user started the batch process: search, select and edit). Be careful tab-openers fans! What will actually happen if a user do so, is that the last batch-edition will overwrite previous ones for that user on that context.

The other thing I did this past weekend was the creation of the AT2Z3Field adapter: ArcheTypes-to-Zope-3-Field. So far is a very, very dummy adapter creating always a zope.schema.TextLine field, but of course here we are going to be creating zope3 schema fields with some closer correspondence with the original archetype field.
The code of this adapter I think can eventually be a separated product, but I wont do that until it's more mature.

Finally, the edit form now is alerting the user if some of the items she selected to edit does not have the selected field to edit. Here, as usual, a couple of screen shots:


Next weekend is the last long development period before the mid term evaluation, which I hope to pass :).
I think that I'll be working mostly on improving the AT2Z3Field adapter, input validation and handling errors, and some cleaning.