"l semble très simple à customiser"
Sans vouloir envenimer le débat et en espérant simplement suciter votre curiosité pour OpenERP, je pense que vous dite cela parce que vous n'avez pas vu:
* le view designer en Ajax d'OpenERP qui permet de construire les vues par simple glisser-déposer et de traduire les champs à l'envie (marche sur le SVN, preview non effective possible sur les démo en ligne; bouton 'customize view')
* l'éditeur de workflow en Ajax aussi qui permet une vétitable gestion BPM des process. ça n'est pas Intalio non plus mais franchement ça va très loin avec une simplicité maximale (cf SVN).
* l'extension des structures de données par héritage et éventuellement dans l'interface graphique. La modularité est très grande et le code résultant toujours propre, lisible et maintenable.
Ceci vaut aussi pour les controllers et méthodes métiers qui respectent la programmation objet et offrent ainsi différent niveaux de lisibilité et contrôle, c'est très différent du code procédural en pl/SQL de Compiere ou d'Openbravo... (le pl/SQL c'est bien, mais je préfère quand c'est utilisé sur des optims parcimonieuses plutôt qu'un recours systématique). C'est quand même aussi bien pratique de mettre ses breakpoints dans Pydev pour introspecter/modifier le code plutôt que de savoir comment avoir une license SQLDevelopper d'Oracle...
C'est vrai que Compiere et Openbravo rendent assez triviale l'extension des structures de données et de leurs vues associées (comme OpenERP donc), mais je pense que sur les process métiers, que ce soit au niveau de la modélisation BPM de haut niveau (genre l'état monitorable sur un graphe de workflow de tes lignes de commande dans OpenERP) ou le code objet vs pl/SQL, il y a une vraie différence de productivité.
J'ajoute que j'ai au moins 5 ans d'expérience de dev Java et j'avais seulement 3 jours de Python quand j'avais découvert OpenERP. Pourtant, tout comme les autres ressources de ma boîte, on préfère DE LOIN apprendre les rudiement de Python (en une semaine on fai beaucoup) plutôt que de faire des centaines/milliers de lignes de pl/SQL dans un ERP qui se prétendrai codé en Java (juste parce qu'il y a du Java entre le bout de HTML et l'appel de la proc stock quand on clique sur un bouton). En plus Python ça ressemble à Ruby et Ruby ça dépôte.
[^] # Re: GPAO
Posté par rvalyi . En réponse à la dépêche OpenERP : la gestion d'entreprise libre. Évalué à 3.
Sans vouloir envenimer le débat et en espérant simplement suciter votre curiosité pour OpenERP, je pense que vous dite cela parce que vous n'avez pas vu:
* le view designer en Ajax d'OpenERP qui permet de construire les vues par simple glisser-déposer et de traduire les champs à l'envie (marche sur le SVN, preview non effective possible sur les démo en ligne; bouton 'customize view')
* l'éditeur de workflow en Ajax aussi qui permet une vétitable gestion BPM des process. ça n'est pas Intalio non plus mais franchement ça va très loin avec une simplicité maximale (cf SVN).
* l'extension des structures de données par héritage et éventuellement dans l'interface graphique. La modularité est très grande et le code résultant toujours propre, lisible et maintenable.
Ceci vaut aussi pour les controllers et méthodes métiers qui respectent la programmation objet et offrent ainsi différent niveaux de lisibilité et contrôle, c'est très différent du code procédural en pl/SQL de Compiere ou d'Openbravo... (le pl/SQL c'est bien, mais je préfère quand c'est utilisé sur des optims parcimonieuses plutôt qu'un recours systématique). C'est quand même aussi bien pratique de mettre ses breakpoints dans Pydev pour introspecter/modifier le code plutôt que de savoir comment avoir une license SQLDevelopper d'Oracle...
C'est vrai que Compiere et Openbravo rendent assez triviale l'extension des structures de données et de leurs vues associées (comme OpenERP donc), mais je pense que sur les process métiers, que ce soit au niveau de la modélisation BPM de haut niveau (genre l'état monitorable sur un graphe de workflow de tes lignes de commande dans OpenERP) ou le code objet vs pl/SQL, il y a une vraie différence de productivité.
J'ajoute que j'ai au moins 5 ans d'expérience de dev Java et j'avais seulement 3 jours de Python quand j'avais découvert OpenERP. Pourtant, tout comme les autres ressources de ma boîte, on préfère DE LOIN apprendre les rudiement de Python (en une semaine on fai beaucoup) plutôt que de faire des centaines/milliers de lignes de pl/SQL dans un ERP qui se prétendrai codé en Java (juste parce qu'il y a du Java entre le bout de HTML et l'appel de la proc stock quand on clique sur un bouton). En plus Python ça ressemble à Ruby et Ruby ça dépôte.
A bon entendeur... Bien cordialement,
Raphaël Valyi.