Nuxeo Developers Blog

[GramOOo] petite réctification

A mon grand regret, j'ai appris que malgré que était considéré comme correct par l'accadémie française.

J'ai donc retiré cette règle de mon correcteur, qui dorénavant ne marquera plus malgré que comme faux.

(Post originally written by Myriam Lechelt on the old Nuxeo blogs.)

The sickness of Zope

Zope is great, but there are some things that are seriously annoying. Much of it comes from things showing their age. There is lots of code that does things in particular and complicated ways because of the need to behave the way things have always behaved, even if that no longer makes much sense. Also, CMF has a couple of basic design flaws, the biggest of them being portal_skins. So in this way, Zope3 will be very welcome, as it rewrites things from the start, and does thing The Right Way ^(tm).

But there is one thing that is not going to automatically be solved with Zope 3: Peoples tendency in the Zope community to first of all do things their own way, and secondly, not move these "own ways" into the common code base, even if they could be of use to others.

I was hit by one of the more typical examples of this today: I need to have permissions that i check dynamically. Usually in Zope, you protect methods or objects with permissions, using the "security.declareProtected(permission_name, method_name)" call. But sometimes, which permission you want to check is dynamic. This is quite possible to do, but first you then need the permission to exist, so you can set up a role to permission mapping, and then check for the permission based on what roles the user has.

And, it turns out, Zope has no method for creating permissions that are not connected to a method or object or a class. I tried various ways and looked through the code, and found nothing. I turned to Florent, and he pointed out that there is a method to do this. In CMF....

CMF is, just like Zope, created and maintained by Zope Corp. And still, this method, that belongs somewhere in the AccessControl module, is located in CMFCore, where is has no business at all.

The examples of are numerous. The fact that most people use DCWorkflow as the workflow with CMF wasn't reflected until recently, when CMF 1.5 came out, and finally included DCWorkflow. And after much nagging (mostly from us here at Nuxeo) Zope corp decided to include Stefan H Holeks excellent ZopeTestCase product in Zope 2.8, so that is no longer is a pain in the ass to write unit tests for Zope. Another good example are the almost infinite number of user folders that exist. Only last year did Zope corp update come up with a new user folder, instead of the default (and pretty much useless) user folder. The new user folder is PAS, a pluggable, extensible user folder.

And, if you expect it to be included in 2.8....ha! No, it's a separate product. Of course. Meaning that every time somebody needs to use it, they need to send an email to the Zope list and ask which of the different extensible user folders they are supposed to use, since they found at least 4 of the when googling...

This all means that when you use Zope, you have to look all over the place for the little thing that does what you want. There is no coherence, just a sprawling spaghetti, and this in turn has the effect that the learning curve for Zope never ends.

I don't know how to make sure this doesn't happen for Zope3, I guess we all have to just make an extra effort to identify the things that are useful to all, and make sure they end up in a place where everybody can find and use them. codespeak.net has a z3-base which is one effort to have a place for the things that are useful for many, but shouldn't be in Zope3 itself. Having a place like that from the start will at least help a bit. But the rest is up to us.

(Post originally written by Lennart Regebro on the old Nuxeo blogs.)

I'm so happy I'm using Python

http://www.ozonehouse.com/mark/blog/code/PeriodicTable.html

(Post originally written by Lennart Regebro on the old Nuxeo blogs.)

[GramOOo] tests de règles grammaticales et construction des règles

Je suis en train de tester quelques règles grammaticales sur les deux moteurs, Gramadoir et Languagetool, pour voir celui qui serait le mieux adaptable au français.

Nous l'avons dit, nous aurons besoin de travailler sur deux niveaux, que nous avons appelés "intrachunk" et "interchunk". Le premier concerne les règles qui définissent des erreurs au sein d'un chunk, à savoir des accords de type nom-adjectifs. Le deuxième niveau va permettre de corriger des fautes d'accords sujet-verbes par exemple.

Nous commencerons par les règles intrachunks.
Un exemple avec Gramadoir:
<D f s>ANYTHING</D> <J f p>ANYTHING</J> <N f s>ANYTHING</N>:ERREURACCORD

Un déterminant fémin singulier, suivit d'un adjectif féminin pluriel, suivit d'un nom féminin singulier est une faute, car il n'y a pas unification du trait nombre.

<D m s>ANYTHING</D> <J f p>ANYTHING</J> <N f s>ANYTHING</N>:ERREURACCORD
<D f s>ANYTHING</D> <J f s>ANYTHING</J> <N m s>ANYTHING</N>:ERREURACCORD
<D f p>ANYTHING</D> <J f p>ANYTHING</J> <N f s>ANYTHING</N>:ERREURACCORD

Notre lexique comporte 6 types de déterminants, 9 d'adjectifs et 9 de noms, plus de nombreux verbes. Je vous laisse calculer le nombre de combinaisons possibles pour décrire les erreurs... En effet, les systèmes décrivent des règles d'erreurs et supposent donc de prévoir toutes les erreurs possibles (ou du moins le plus possibles).

C'est pour cela que nous avons décidé de générer automatiquement les règles. Nous commençons par générer toutes les combinaisons possibles et nous supprimons celles qui sont correctes.

Pour l'instant nous n'avons généré que les cas suivants:
<D ...> <N ...>
<D ...> <J ...> <N ...>
<D ...> <J ...> <J ...> <N ...>
Nous obtenons alors 4244 règles d'erreurs.

Reste à savoir si les systèmes ne seront pas "perturbés" par de si nombreuses règles...

(Post originally written by Myriam Lechelt on the old Nuxeo blogs.)

Python Statement Considered Harmful

Martijn Faassen posted two entries on alternative template languages for Zope 3:

http://faassen.n--tree.net/blog/view/weblog/2005/04/15/0
http://faassen.n--tree.net/blog/view/weblog/2005/04/16/0

The idea behind this is simple: Templates should be data-driven! That is, they should contain no calls, no logic (other than for display) and no other monkey-business at all. It might be easiest to explain why this is a good idea by explaining the problems with NOT doing it.

In the beginning there was DTML

DTML was the first template language for Zope. Although a huge improvement on how PHP and ASP templates work, DTMLs syntax, gets ugly pretty quickly. Also, people tended to write complete aplications in DTML. That's OK; it was designed to do that, Python Scripts didn't exist in the first versions of Zope. DTML was the replacement of PHPand ASP. But this quickly tirned ugly and complicated (as it does in ASP and PHP too). Something better was desired.

Let there be TAL

ZPT was the next step: Better syntax (it's more verbose, but it is consistent, easy and doesn't degrade into uglyness), and less intelligence and magic. Again, a huge step forward. But if you look at the typical CMF template, you'll see masses of logic, usually complex logic that makes the templates hard to understand and error prone.

This happens because templates in Zope2 access objects. They have a context variable where you get the object you are displaying, and you can access the objects attributes and methods. You can also call python expressions. In short, even the new cleaner ZPTs doesn't enforce a strict enough separation between logic and presentation. You can still do too much.

So what if we don't do anything of this? We just have data, and display it? Is that feasible with ZPTs? Yes, absolutely. What you need is to somehow call a method before displaying the template, that fetches all the data and does everything that should be done before displaying.

Keeping your templates clean.

Luckily, we don't need a new templating system to do this, ZPT allows you to do too much, but it doens't force you too. You can do this by convention.

Zope3 has a system of view classes, where the class is supposed to do exactly, this:  prepare and react to the data for and from the template. So in Zope 3 you can prepare everything you need, do any actions that should be done and set the data to be displayed as attributes on the view object from the views __init__ method. All in pure, standard python. No longer should you need to call any more methods in the template, and you don't need to do any arithmetic, it's all done beforehand.

In CMF you don't have a view class, but there can call a python script, that returns a dictionary with the data to be displayed, with statements like tal:define="data context/update_script". Then you access it with "data/key" later in the ZPT.

Python statement considered harmful

As a rule of thumb, you should avoid any "python:" statements in ZPT, and you should also avoid using "context" unless it is to use another template via a macro. If you avoid this, you are a long way to keeping your ZPTs clean, and your code understandable.

(Post originally written by Lennart Regebro on the old Nuxeo blogs.)

Workshop: Making music with the internet

The 4th of May I'll be there talking about making music on the internet; communities, collaboration and distribution, an area where things are moving and changing very rapidly. This talk is a part of a larger event for DJs. The event is held at The Blue Tree in Gaborone, Botswana.

(Post originally written by Lennart Regebro on the old Nuxeo blogs.)

[OOo]DicOOo & Thesaurus V2

I worked on extending DicOOo to handle the new thesaurus format. I wanted DicOOo to propose the right files depending on the OOo version it was running on.

DicOOo handles all plateforms and all OOo versions and i want to keep this feature (at least for 1.1.x branch) as not everybody will switch at the same time to the great OOo 2.0 ...
The key point is that a wrong thesaurus file format will lead to errors and sometimes crashes in old Ooo versions.

So i designed, aggreed with lingucomponent project, a new list of thesaurus dedicated to v2. It already contains german, polish and french thesaurus. English one, which is shipped with OOo, will also be added but once it has been correctly renamed ...

DicOOo now detects the OOo version and use the right list according to the version. Off-Line packs engine have also been updated to handle this. Nevertheless they have to be updated to include the new thesaurus and the according list ....

So DicOOo 1.5 is out and update will be prompted by the self-update feature

In the mean time, i also worked on IZ47107 with Daniel Naber to solve a bug that added a closing parenthesis when selecting a word in the  thesaurus. I patched the patch and found the result working on my own build. Now, just to include it in the official sources ...

Still on the road of DicOOo 2.0 that is a complete rewriting and will allow to uninstall dictionaries ...

(Post originally written by Laurent Godard on the old Nuxeo blogs.)

[OOo] IRC conferences on #ooonlc

The Native-Lang Confederation is the association of all the native-lang projects in OpenOffice.org (French, German, Dutch, Japanese ...)

Daniel Carrera set up some times ago the IRC conference on the #ooonlc channel. At a given time, widely announced on OOo lists, everybody meet on #ooonlc and a "writer" speaks about a topic of its interrest. Slides are available before the start so everybody can follow the presentation. This is followed by Questions & Answers and discussions.

This IRC conference occurs every two weeks, during a week-end, at a time that suits the most of the attendees all around the world.

This week end, saturday at 17:00 (Paris time), Simon Brouwer, the  leader of Dutch project, will speak about european software patent as he is very active against them. Everybody is welcomed

Official announcement
Conference homepage
Time
IRC guidelines

The next conference, in two weeks, will be from myself dealing with addons development for OpenOffice.org

(Post originally written by Laurent Godard on the old Nuxeo blogs.)

[GramOOo] nécessité d'un segment intermédiaire entre les mots et la phrase

En examinant quelques fautes de français, et en se demandant comment il est possible de les corriger, on se rend vite compte de la difficulté à laquelle on est confronté.

Nous avons désambiguïsé les mots par rapport au contexte immédiat, gauche ou droit. On voit bien qu'on pourra faire la même chose pour corriger un accord entre un nom et un adjectif par exemple.
Si un adjectif masculin singulier est suivit d'un nom féminin singulier, il y a faute, car il n'y a pas concordance, unification des traits.

Mais prenons la phrase suivante:

      *  La grève des lycéens continuent.
( l'astérisque signifie que la phrase est agramaticale)

Comment le programme va-t-il détecter que  le verbe continuer doit s'accorder avec  le nom grève et non pas lycéens si on se base uniquement sur le contexte immédiat?
Nous avons besoin d'un segment intermédiaire entre les mots et la phrase. On parle de syntagme (groupe) ou de chunk (notion introduite par Abney).
Pour l'exemple, on pourrait effectuer le découpage suivant:

      * [La grève [des lycéens]] [continuent].

[ ] est un syntagme nominal (SN)
[ ] est un syntagme verbal (SV)
[ ] est un syntagme prépositionnel (SP)

Chaque syntagme comporte une tête qui est l'élément principal: nom, verbe, préposition (ici de car des est la contraction de de les), etc.
Le SN s'accorde avec le SV. Si le propriétés du SN ne correspondent pas à celles du SV, alors il y a faute.
Ici, le SN est féminin singulier, le verbe est au pluriel, il y a pas d'unification de traits, il y a faute.

Si notre outil ne se limite pas seulement aux mots et permet la notion de groupes supérieurs, nous pourrons alors corriger bien des fautes.

(Post originally written by Myriam Lechelt on the old Nuxeo blogs.)

[OOo] a patch for 1.1.4

A security patch has been announced on OOo release list by Martin Hollmichel

it covers a heap overflow on opening DOC files. This hole could then be exploited by a malicious document. Everybody using OOo 1.1.4 should update.

The patch is actually spreading over mirrors and should be available soon
It is located on the mirror at /contrib/rc/1.1.4secpatch/
(a french mirror : ftp://openoffice.cict.fr/openoffice/)

To install it (on linux - read announce for other OS)

• go to <ooo>/progam

• replace the file libsot645li.so by the new one (you may have to change permissions).it is advised to previously backup this file

This patch is only given for the official 1.1.4 version. For other versions (distrib specific and/or oldest versions) a new milestone 645_m53 containing the patch sources is available on CVS

It is good that such flows are adressed and patches given but OOo team will have to think to end-users that even do not want to (or can not) perform a simple file copy. Perharps an addon simplifying the process ...

updates :

• Announce on the french list
• A pacth for OOo 1.1.4 for MacOsX will also be available (named libsot645mxp.dylib)

(Post originally written by Laurent Godard on the old Nuxeo blogs.)