Tuesday, July 01, 2008

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.

No comments: