Shhhh

Hay dos o tres situaciones que siempre me asustaron. No sé si puedo nombrarlas una a una, pero sí al menos a la primera.

Algo a lo que siempre tuve una especie de miedo y respeto es una de esas cosas que pasan muy de vez en cuando. 

Sólo se siente en la tranquilidad del anochecer, cuando todavía hay claridad pese a que ya se haya puesto el sol. 

Es cuando en los oidos se percibe el perturbante y adormecedor sonido del silencio, y se escucha a la brisa revolviendo los dos mechoncitos de pelo tras los oidos.

Y los dedos de las manos, apenas arqueados, descansando.

Es ver a esa misma brisa formar mareas verdes en el suelo, creando olas de hierbas sacudidas por el viento

Es todo eso.

Pero en realidad es mucho más.

Supongo que ese mucho más es lo que un poco asusta pero también lo que lo hace interesante.

Supongo que ese mucho más hace que cada verano me desespere por volver a asustarme.

Será por eso mismo que cada vera vuelvo a las montañas buscando ese silencio.

(A la foto la saqué de acá)

Se nos murió un manzano en las manos

Hace más de un año con la Juli compramos un terreno en Villa Rivera Indarte, lugar que elegimos para vivir. Estaba lleno de árboles frutales en la parte de adelante. Disfrutamos de sus manzanas, peras, ciruelas y duraznos. Las naranjas y mandarinas son muy secas o chiquititas como para decir que las disfrutamos, pero igual hicimos mermeladas.

Estamos prontos a empezar la obra de construcción de nuestra casita y la verdad es que siempre supimos que tendríamos que sacar varios de estos árboles. Pero una cosa es saberlo, y otra cosa es efectivamente hacerlo.

Empecé por un duraznito chiquito, apenas un poco más alto que una silla. Hice un pozo grande, un metro de diámetro más o menos, y fue saliendo. Después, lo llevé tranquilo al fondo donde lo esperaba un pozo recién hecho. Lo plantamos y regamos.

Y después le tocó al manzano. Este era más grande, un tronco de más o menos 20 centímetros en la base, y como 4 metros de alto. Por alguna estúpida razón siempre creí que podríamos transplantarlo. Por más estúpidas aún razones nunca hicimos todas las averiguaciones pertinentes para saber cuándo y cómo hacerlo de la mejor forma posible. Y así fue que llegamos a tener que empezar a preparar el terreno para la obra, y encontrarnos con el lindo manzano ahí.

Estúpido aún, seguía pensando que era cuestión de hacer un pozo grande para sacarlo.

Muy grande fue el pozo, tan grande como la decepción al ver que las raíces principales eran en su mayoría horizontales, y que no habría pozo capaz de sacarlas enteras. Después de varias horas de trabajo terminó saliendo, mal herido, sin raíces, desangrando savia y tierra por sus pies.

Recién entonces me di cuenta de que me había estado mintiendo.

Y con el árbol acostado sobre el piso, me senté, y acaricié su tronco ya en el suelo, y mientras le pedía perdón con una mano, lloré agarrando a la Juli con la otra. Acaricié su tronco, suave y gris. Recorrí las heridas en su piel, pasadas y curadas y miré las que acababa de provocar. No me quedó más que volver a pedirle disculpas.

Me pregunto cuantos tendrémos que plantar para olvidarme de este.

--

Que bueno, ahora después de escribir este post soy un tipo sensible, en vez del reverendo hijo de p*** que mató a tan lindo árbol.

--

Que bueno, después de la ironía sobre el lavado de culpas, ya me siento más libre

--

Que bueno, etc, etc, etc.

plone.app.batch 0.1 release

That's right, I tagged the work done so far in what we can name the first release of this nice product.

In case you are interested on it, here it is: plone.app.batch-0.1

End of Summer

Don't scare, your summer is not ending yet. Don't scare, my winter here neither. The thing is that the Google Summer of Code period is finishing in about 10 hs, and last 2 weeks I worked hard adding and cleaning things.

A summary of the work done in the last 2 weeks can be summarized with the change log comments, which are:

• Added, fixed and improved tests and documentation.
• Minor imports fixes (and dependences changes) for working with plone.app.z3cform 0.5
• BeautifulSoup dependence added, for making functional tests easier.
• Fixed bug in editor: if unmarking object checkbox, now is excluded from the process (wasn't happening this).
• utilities (datetimes functions and makeBatchEditableField) added to utils.py
• Fixed ATValidation error class for displaying the message of the archetype validation error.
• BatchDataManager added, which adapts content and IBatchField fields. This cleans the code of the BatchEditor adapter.
• Dummy Lines field created, for handling different situations with archetypes Lines fields. So far, is only a Text field.
• Reference field added, which uses first version of AccessibleWidget.
• Accessible widget added: multiselect widget with javascript improvements, but also functional for non javascript browsers.
• Images and Files now can be uploaded with batch editor.
• In AT2Z3Field, removing plone.app.batch dependences, preparating the ground for making it a separated package.
• AT2Z3Field tries to grab a vocabulary for the z3field from the objects that is trying to adapt.
• Added TitledVocabulary (taken from PloneGetPaid), for easy creation of titled vocabularies.

refresh.txt now is plone.reload

Note: they are not the same thing, It's just the title of my post.

About 3 years ago, when I started to develope with plone/zope there was a nasty trick for speeding up development that consisted on putting an empty file named exactly "refresh.txt" in the root of your product. That way, each time you modified the code of your product, you were not pushed to restart your zope instance: you had to navigate thru an intricated path until you reach your product, and from there clicking on a magic refresh button saved us, reloading our code.

Sometimes, the code in your product was importing another modules, and then refresh were not able to reload things entirely, and there were some other oddities that I don't remember right now.

Anyway, that process worked fine for a while. But later things started to be more and more complex, until at some point the refresh thing ended been completely obsolete and non useful at all.

With the advent of Five and zcml configuration files, and probably many other new pieces on zope, refresh was wounded death.

Mourning and grief... I wored black clothes for a couple of weeks, but, slowly, I started back my normal life.

There I was when last week Anthony, who abandoned Plone development for a couple of years, asked me about our old friend refresh.txt... I started to carefully choose the words, trying to not hurt him with the terrible news, when I though "Hey, there must be some replacement out there".

I was doing a fruitless search when Matthew Wilkes introduced me the newest kid on the block: plone.reload. It simply works, and there is no need to explicitly tell it what to reload, and it is also able to reload zcml configurations!. What a joy.

Unfortunately, there are some issues on the product yet, but it's actively developed, and regardless those things, it's very useful.

- What issues did you find?

- Only this one: Does not work if you touch code in a class method that calls super. The thing is simple: the module is reloaded, so, when calling super, an internal isinstance call fail.

Accessible Multi Select Widget

While using plone.z3cform (a plone wrapper for z3c.form lib) I felt a bit frustrated when I could not find a multi select widget that were functional for a non javascript browser.

Yes, I know what you may want to say, that in the current century we web developers should not worry any more for non javascript browsers, but I think we do have to.

According to this stats (w3schools, and the counter) is about 5% of the users, and although this number is decreasing, I think that is still a considerably portion.

So, what I did is a widget that consist of a set of 3 html select fields. The actual
one (the one with the name that the form action will use) is the one that is viewed by default in a non javascript browser, and is something like in the first screen shoot.

If you have javascript enabled, the widget append a function to the onload event of the window, and then the default basic view is hidden, and shown a nicer one instead, like the one in the second shot. And each time the user do things on the nicer widget, that selection/de-selection action is reflected in the actual hidden select input.

Where is the code of the widget? So far, is inside my plone.app.batch product, but if anyone thinks may be useful we can incorporate it on a more generic package.

On this same aspect, I would like to do similar kind of things with other widgets, and I open to hear suggestions.

Olim.pyc

Are you a sports fan but you have to work instead of been watching the olympic games?

Would you like to be notified each time someone earns a medal, without needing to have a browser opened?

Well, more or less that was my situation, and that's why I dediced to create Olim.pyc. Unfortunately, during these days I was finishing (or at least working hard on it) my GSoC project, so I made a very rough version of what could be a much nicer program.

What does Olim.pyc do? This is an screen-shot of it:


It consults the official Olympic games site and refresh it's internal database. Each time some country increase it's medals counter, you will be warned. If you want to consult how the medals ranking is, just clicking on the Olim.pyc systray icon will open a summary like this one:



Wanna make a try? You'll need a linux box, with BeautifulSoup and libnotify installed. It's done in Python, of course, but there is no decent linux on earth without a Python installed.

You can download an alpha release here (don't expect a real release never).

Disclaimer: I could not make libnotify to use a certain font, and the formatting options it provides are too small for creating a decent table, so don't be surprised if you find yourself having an ugly layout.
I'll be glad of you want to help me to improve my fast and nasty code.

Of course, it's GPL.

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.

Officially Started my Winter of Code

The past Saturday the winter started here, so my summer of code changed to a cold winter of code in the south hemisphere.

A summary of my progress can be read on the docs/HISTORY.txt file on the product itself, but here I'll paste last changes.

• Outlined BatchEditorForm, so far only showing a list of contents to edit, but not editable yet.
• Added Empty Interface and Adapter for BatchEditable contents.
• Created uninstall profile that removes all created actions.
• Created first tests: tests_setup.py and base.py inside tests module.
• User search parameters and items selection stored on content annotations.
• Re done BatchSelectorForm for displaying search results and select items to edit using plone.z3cform.crud.
• Added Interface and Adapter for BatchSelectable contents.

Although what we have is still not even an alpha release, I invite you people to checkout the code and try it (on a sandbox instance please). I also encourage you to file anything you find odd here.

Also, I want to thank Daniel Nouri for his great work on plone.z3cform.crud.

Here, an screen shot of the selector user interface. As you can see, needs some ui love yet.

About things for next week, I must say that is the same list than for the previous one:

• display Archetypes schema fields on plone.z3cforms.crud
  
• create the batch edit action for saving changes (shouldn't be hard using crud).
  
• add more tests.

Handle errors

Here I have a question for which I don't have a clear answer yet, and is what to do when trying to submit a batch-edition and the values provided for some of the fields is not valid. Can be an empty required field, or any other kind of validation error.

What I think we should be doing is:

• not save changes for any object on the form
• display the form with the given values on each input field, and the errors displayed
• allow the user to disable the re-submit of problematic objects with a check box next to each.
• A global disable all problematic objects check box for JavaScript enabled browsers.
  

This way, if the user have dozens of objects with correct data, and only a couple are failing, he can save the correct ones, and later care about the problematic ones.

Previously, Martin suggested to put the disable check box at the beggining, which I also think it's good idea.

Again, your comments will be very appreciated.

Edit heterogeneous content

Martin Aspeli asked how us will be handling the batch-edition (yes, I invented that verb) of several objects of different content types. Moreover, what fields let the user select to edit, and what to do if the user selected to edit a field that does not exist for any of the objects to edit.

My first though was report that request as an error. Wasn't very powerful, nor useful, but was the first though. After a week of thinking, I prefer another more user friendly option: when displaying the batch-edit-form, for each content object that does not have the field to edit, just inform the user that fact, but not report any error, and also display in the form all input fields for objects that do have the field to edit.

With this in mind, I think that shouldn't be hard to let the user actually select more than one field to edit for the set of content objects.

I'll be glad to read your thoughts.

plone.app.batch

New name, new code, new ideas, new functionality.

We still not have the real batch-edit functionality in place, but we are building the pieces to finally have it.

In this past weekend, I progressed in three different paths.

In first place, after a couple of recommendations, I decided to take a deep look to the z3cform package and it was a nice and enlightened reading. Although I didn't put z3cform forms in my package yet, it's for sure that I'm gonna do it.

In the second path, I cleaned and re-though a couple of ideas. Following Martin Aspeli advices (or should I write Martín?) I separated in interfaces and adapters what things will be able to be batch-editable, how will that be done, etc. In this way, I added a setup configuration page to the plone setup area to select which content types can be batch-editable. This work took me more than what I expected, but I think that real timer-consumer thing was the gain-experience-in-the-process thing. Anyways, my past in PloneGetPaid helped :-D. Here above in the right is a scree-shoot of that page.
Another thing I did in the cleanup was: simplify batch search form, and prettify the batch results page, which I was thinking on name batch-selector (Is the form where you have the content objects you want to modify, and you select what to do with them).

Finally I created an entry on plone.org/products and I'm waiting the approval. If you got a Log In page instead, means that was not approved yet. After approval, I want to add an issue tracker there and invite you my dear reader to test what I have, and file issues, or request. Probably I wont be able to add much functionality things to the project during the summer of code period, but I plan to continue later, so do be shy.
I also added my code to the plone collective, so if you want to take a look:

svn co https://svn.plone.org/svn/collective/plone.app.batch

I was going to add Alex Limi and Martin Aspeli as owners of the product too, when I realized that they already have that role inherited because it seems that they are plone.org administrators. My assigned and not assigned tutors rocks :). I added Jon Sthal (the owner of the idea) and Matthew Wilkes (the guy that's coordinating this summer of code from plone) as owners in case they want to do things there.

The plan for next week:

• study Alloy Analyzer: I have an exam next Friday.
• buy gifts (or better, make them): my girlfriend birthday is this Thursday.
• code and code for SoC:
  • start work to display Archetypes schema fields on z3c forms.
    
  • create the batch_edit form using the previous work.
    
  • add some tests (shame on me)

A little request: if you have things to say, I'll appreciate if you can add comments here in my blog. It's much easier for organize information than searching emails.

Plone Batch Plan

After the first two weeks of lot of plone3 studying, and first lines of code, here I'm trying to have a first plan for this exciting summer of code project.

I'm very excited after writing the first pieces of this project cause things are looking fine, and I'm enjoying the pretty plone3 style :-D.

The plan

I think that the entire project can be contained on a single plone theme product, which I was thinking to call plone.batch. I'm very original, don't you think :-)? Yes, like in all other things in this post (and in this project) I'm open to accept better ideas.

The separated pieces that glued together will eventually make the plone.batch that I think are:

1. Generic setup profiles for install/uninstall the product
2. zope3 browser form, very similar to the current "advanced search form", accessible as an object action for any folderish content.
3. zope3 browser view/form that displays search results, but in a new form that allows the user to select which objects to edit, and what operation to do. So far, the operations that I have in mind will be:
   • edit a field (with a drop-down of available fields)
   • enable / disable comments
   • transform (with a drop-down of transformations)
4. zope3 browser form for real batch editing content fields (finally!). Should be a listing with a widget for editing the selected field and a save button for each selected object . For non-javascript users a global save button will be available.
5. Server side logic for kss
6. Set of basic, default transformations. I think that this will be done with a set of adapters.
7. Tests, tests and tests. I was thinking on making unit tests for the back-end, functional tests for the basic user interface, and selenium tests for the ajax interface.
8. I would also like to have time to include some i18n work, and a Spanish translation.

Bureaucracy

I have a couple of bureaucratic things that I need to get done for making communication easy:

• Include my code in the svn.plone.org/collective. So far I worked on a local svn repo, which let me have versions, but not allow people to see my work nor prevent me for accidents if anything happens to my laptop.
• Create bug-issue tracker (in plone.org?)

What did I do so far?

• I created a very basic install profile that adds the "batch" action to folderish contents
• I created the zope3 search form based on the default plone advanced form, putting all the python calculations on the view code instead of the template, and trying to eliminate as much as possible the old plone things that template was carring (like doing here.portal_something, or use of isAnon, etc)

Here are a couple of screen shots of this initial work: