# Choisir des outils de développement Mac



## Bernard Senior (7 Janvier 2006)

Bonjour à tous,

	Tout d'abord, mes félicitations à Thierry Santacana pour l'excellent site de Project:Omega et pour la qualité de ses traductions. En français, c'est quand même plus simple, non ? 
	Et puis... mon problème. Je suis confronté à un choix à faire dans les mois qui viennent concernant une migration vers d'autres outils de programmation et j'aimerais avoir l'avis de pros du secteur. Je programme depuis 1981 en autodidacte. J'ai une formation d'ingénieur (1976...la préhistoire !) et ai passé les 50 piges. Depuis 1994 je travaille sous FoxPro 2.5 Mac (SGBD langage XBase, programmation procédurale). J'ai développé deux applications principales d'environ 10 000 lignes de code chacune (Gestion de bibliothèque, gestion de fichiers d'adresses/VPC) + du menu fretin. Microsoft a abandonné FoxPro Mac en 1996. FoxPro 2.5 tournant toujours sous Mac 0S9, je ne m'étais pas trop alarmé. Le problème c'est que l'OS9 est petit à petit mis au placard au profit de Mac OS X. Si je ne fais rien et que je ne veux pas switcher sur PC  , je vais droit dans le mur dans un avenir plus ou moins proche. Je gère actuellement un parc d'un trentaine d'ordinateurs (G3 B/B pour la plupart + quelques G4) + 3 PC (eh ! oui). Nous sommes sur Mac depuis 1987.
	J'ai plusieurs possibilités, (il y en a probablement d'autres...) :
	1. Migrer sous 4D.
	2. Développer avec les outils XCode et Webobjects (maintenant gratuits mais pour combien de temps ?).
	3. Utiliser le couple PHP/MySQL gratuit aussi.
	Pour 4D, bien que le langage soit complètement différent, je me retrouve quand même en pays connu. Mais pour les deux autres, programmation objet et technique web... bon... pas trop évident pour moi. Je ne demande qu'à être convaincu mais il me faudrait des arguments massifs et percutants.
	L'avis de ceux qui ont déjà été confrontés à un problème similaire me serait très profitable. Par exemple, combien de mois en moyenne (à raison de 35 h par semaine s'entend et sans y passer ses nuits !) il faut ramer à toute force avant d'être un peu à l'aise avec la programmation objet (en auto-formation).
	Bien sûr, je tiens toute information complémentaire à votre disposition. D'avance merci.

	Bonne année 2006 à tous.


----------



## OlivierL (7 Janvier 2006)

Le passage à l'Orienté Objet me semble une bonne piste pour rester dans le coup.
Pour Java, le gros avantage, c'est la portabilité.
Tu développes aujourd'hui avec Eclipse (gratos) sous MacOS, et demain avec Eclipse sous Windows si besoin est.
Ou tu développes sous MacOS, tu déploies sur Unix...

Bon le passage à l'objet, on peut considérer qu'en 6 mois, tu auras acquis pas mal de chose, mais ca dépend tellement des gens.
Si tu programmes proprement en "procédural", tu programmeras proprement en objet, une fois les concepts compris. Le piège étant de coder en procédural, avec un langage objet, car là, y a pas de gain.

Et si je ne m'abuse, je crois que la dernière version de PHP est Orientée Objet également.

Bon courage.


----------



## Bernard Senior (7 Janvier 2006)

OlivierL a dit:
			
		

> Si tu programmes proprement en "procédural", tu programmeras proprement en objet, une fois les concepts compris. Le piège étant de coder en procédural, avec un langage objet, car là, y a pas de gain.


Merci de ta réponse et d'avoir pris la peine de me lire. Une grande part du problème est cette assimilation des concepts. La conception et la programmation orientées objet constituent un changement radical par rapport à la programmation procédurale standard. C'est cette radicalité qui me rend perplexe.  Par où commencer ? Existe-t-il des tutoriels en français ? Pourquoi choisir Java plutôt qu'un autre langage ? Java ne me paraît pas d'un rapidité extrême à en juger par la lenteur de l'open source NeoOffice sur Mac.
Je programme du sur mesure pour une utilisation en interne. Pas question de déployer en externe. Je peux donc n'employer que des outils pour le Mac. Encore faut-il que ces outils soient perennes. Je me suis déjà foutu dedans avec FoxPro... bon. Je n'ai pas trop envie de recommencer. Qui me dit que WebObject a de l'avenir ? Des bruits de couloirs le donnaient déjà pour condamné. C'est difficile de s'y retrouver, non ?  
A plus.


----------



## GrandGibus (7 Janvier 2006)

Bonsoir,

Peut-être pourrais tu décrire d'avantage les besoins: le choix des outils (et des langages) se fait d'avantage en fonction des besoins et non l'inverse .

Pour revnir à certaines remarques: Pourquoi Java ? 

Parce qu'il est bien plus _propre_ dans sa syntaxe (comparé à d'autres langage)
Parce qu'il est multi-plateforme (mais faudrait voir tes besoins)
Parce que beaucoup de solutions open source gravitent autour
Une communauté sympa et hétéroclyte (because multi platforme)
... la liste pourrait être encore longue !

Comme très bien dit par OlivierL, le point de vigilence dans ton cas sera de ne pas faire du procédural en objet. Outre l'apprentissage de la syntaxe inhérente à l'objet (mais comme tout langage de programmation), il conviendra surtout d'apprendre... enfin, de comprendre les design patterns... Si tu passes à l'objet, ils seront tes meilleurs compagnons... et ce quelque soit le langage.

Pour WebObject, il s'agit d'une solution Apple pour faire facilement du J2EE (tout ce qui gravite autour du web en Java)... Là encore, dis-nous en plus sur tes besoins.


----------



## Bernard Senior (8 Janvier 2006)

GrandGibus a dit:
			
		

> Peut-être pourrais tu décrire d'avantage les besoins: le choix des outils (et des langages) se fait d'avantage en fonction des besoins et non l'inverse.


Merci de tes avis. Ta remarque est très juste. Je voulais simplement ne pas être trop long pour amorcer la discussion et ne pas lasser le lecteur. 
Pour les besoins, je vais me limiter à l'application maison qu'il me faut migrer en premier, à savoir une gestion d'adresses. Pour la gestion d'une bibliothèque, c'est moins pressé et on peut éventuellement acheter un progiciel tout fait (bon... c'est qd même aux alentours de 15 000/20 000 euros minimum).
Les outils basiques dont j'ai besoin sont une gestion de base de données et des outils pour gérer l'interface et les sorties papier. Les SGBD font cela très bien. J'aurais bien gardé FoxPro que je connais bien maintenant . Mais désirant rester sur Mac, je suis coincé. En plus, la possibilité de consulter sur intranet les fiches-adresses sans avoir à installer le logiciel sur tous les postes clients (Mac ou PC) serait vraiment bienvenue. 4D sait faire cela. Mais le choix de 4D est un choix définitif étant donné que le langage de 4D est propriétaire et il faudra mettre la main au porte-monnaie pour toutes les mises-à-jour. Les centaines de milliers de développeurs 4D augurent bien de sa pérennité et militent en sa faveur... Mais, bon..., je voudrais m'assurer que je mise sur le bon cheval. Puisse que je dois tout remettre à plat, je ne privilégie d'emblée aucune solution.
La base comporte une trentaine de fichiers. Le fichier-adresse est d'environ 35 000 fiches. Il y a environ 100 000 historiques. Mon interface est assez fournies : la fiche-adresse comporte environ 50 objets (champs, cases à cocher, pop-up, boutons...). Actuellement, tout cela tient sur un écran 1024x768 et c'est bien commode de n'avoir pas à faire défiler plusieurs écrans pour avoir une vue d'ensemble de la fiche. Il y a aussi pas mal de sorties papier : mailings, bordereaux transporteur, La Poste, comptabilité VPC... L'utilisateur peut modifier lui-même sans programmation les modèles d'impression. Voilà pour l'essentiel.
Ce qui me paraît séduisant dans les techniques objet, c'est la possibilité de réutilisation et de déclinaison du code. Ce qui est beaucoup plus difficile avec les fonctions de la programmation classique où, le plus souvent, on est obligé de dupliquer et d'adapter le code. Les techniques web, elles, permettent de s'affranchir de la plateforme et de n'avoir pas à distribuer le logiciel sur tous les postes clients. Elles ouvrent des possibilités qu'on ne peut envisager avec les programmes classiques.
Merci de m'avoir lu jusqu'au bout...


----------



## GrandGibus (8 Janvier 2006)

[cirage_de_pompes ON]

C'est d'autant plus un plaisir de te lire jusqu'au bout qu'il n'y a pas de fautes d'orthographe tous les 3 mots (quoique pas souvent sur macgé comparé aux autres forums)... et en plus tu sais exactement dont tu as besoin et tu l'exprimes clairement !

[cirage_de_pompes OFF]


A la lecture de tes besoins, il est clair que Java et PHP sont des bons candidats.

A la facilité de PHP, on pourra opposer la capacité de Java d'intégrer des modules _plus complexes_. Sans vouloir froisser les supporters de php, il ne faut pas oublier que c'est un langage qui a été conçu à la base pour faire du web et uniquement du web... donc la partie de présentation des données. A ce titre, même les récentes évolutions du langage et ses rapprochements avec d'autres langages ne le permettront d'avoir le statut de VRAI langage de programmation. A titre d'exemple, essaie de faire du threading ou de l'asynchrone en php :rateau:.

Tout ceci pour dire que le choix se fera en fonction de la _complexité fonctionnelle_ que ton programme devra rendre. Pour tout ce qui est _présentation des données_, sans soucis, c'est php qui sort grand vainqueur (facile d'apprentissage, dans la réalisation...). Par contre si tu dois intégrer un moteur de recherche basé sur une indexation de données (comme google) et pas un simple générateur de requêtes SQL, et que ce genre de fonctionnalité est d'une importance capitale... alors, il conviendra de considérer Java.

Dernier point, et la tendance récente le montre: le client WEB semble être le meilleur choix pour ton besoin (facilité de déploiement, migration des versions...)... on parlera alors d'application web. 


Ceci n'est que mon avis et je n'ai pas non plus science infuse :rateau:.


----------



## olof (8 Janvier 2006)

C'est clair que le client web est une bonne solution. Par contre, Bernard parle de sortie papier dont l'utilisateur peut gérer lui-même le modèle... A ce niveau, ça risque de pas être facile... A moins qu'il existe déjà des outils ?!?!


----------



## Bernard Senior (8 Janvier 2006)

GrandGibus a dit:
			
		

> Tout ceci pour dire que le choix se fera en fonction de la _complexité fonctionnelle_ que ton programme devra rendre. Pour tout ce qui est _présentation des données_, sans soucis, c'est php qui sort grand vainqueur (facile d'apprentissage, dans la réalisation...). Par contre si tu dois intégrer un moteur de recherche basé sur une indexation de données (comme google) et pas un simple générateur de requêtes SQL, et que ce genre de fonctionnalité est d'une importance capitale... alors, il conviendra de considérer Java.


Merci de tes compliments et de la qualité de cette discussion. Je m'efforce, en effet, de ne pas trop écorcher le français... C'est l'âge probablement... 
Pour ce qui concerne la recherche des données, je travaille dans FoxPro surtout sur les index combinés : par exemple, pour appeler les fiches-adresses, Pays + Nom, ou Pays + Code postal, ou plus simplement Numéro de fiche. J'utilise SQL dont l'implémentation essentielle dans FoxPro est l'instruction SELECT. Le problème, c'est que ma version ne gérant pas le client-serveur et de plus le système de fichiers XBase n'étant pas une base SQL à proprement parler, les temps de réponses sont prohibitifs (3 à 4 minutes sur 35 000 fiches). En effet, les fichiers se baladent tout entiers sur le réseau (100 BaseTX). Je ne l'utilise que pour les mailings. Je n'ai aucune idée des temps de réponse que je pourrais obtenir dans une base SQL avec interrogations en PHP ou Java.
L'idée de pouvoir accéder à toutes les données des champs de mes fiches-adresses me sourie assez mais je n'en fais pas un absolu. Avec le système actuel, l'utilisateur tombe très rapidement sur la fiche recherchée (j'ai quand même à épurer régulièrement des doublons !). Ce serait seulement un plus.
Pour la base SQL, laquelle choisir ? Il y en a pas mal sur web.
Un dernier point. Si je me lance dans une application web, quels outils sont les plus rapidement assimilables outre le langage Java ou PHP à apprendre ?

Pour répondre à Olof


			
				Olof a dit:
			
		

> Par contre, Bernard parle de sortie papier dont l'utilisateur peut gérer lui-même le modèle... A ce niveau, ça risque de pas être facile... A moins qu'il existe déjà des outils ?!?!


C'est un outil assez puissant intégré au SGBD FoxPro. Cela permet des personnalisations assez poussées et des sorties de qualités puisse qu'il y a un éditeur avec outils graphiques. Mais là encore, je n'en fais pas un absolu...


----------



## GrandGibus (8 Janvier 2006)

Quelques réponses en vrac:

Concernant le choix du moteur de la base de données, Mysql semble être tout désigné pour faire un bon candidat.

Les performances dans tes recherches ne dépendent pas du langage qui fait le requêtage (java...), mais du moteur proprement dit . De même, le réseau n'intervient pas dans l'exécution de la requête. 

Pour le reporting, il faut peut-être regarder du coté de Jasper Reports. Bien que c'est du Java, il y aurait moyen de faire quelque chose tout en gardant du php... ou bien tout faire directement en php. A jeter un oeuil coté développements open source sur sourceforge... ça fourmille de modules php. 

Si le reporting est la seule _fonction avancée_, php me semble donc être la voie à suivre... car coté technos Java, la marche est beaucoup plus haute, pour un gain incertain.


----------



## cretinoïde (8 Janvier 2006)

Quand à moi, je te donne mon avis de développeur Cocoa.

Quitte à "migrer" de Foxpro autant le faire vers en priorité vers :

4D ou FileMaker.

Ensuite, quitte à faire quelque chose de plus évolué, sophistiqué et puissant, autant le faire sans Java mais en Cocoa. 

Dans ce dernier cas, surtout pas de MySQL mais SQLite qui est le micro-moteur intégré idéal pour une "application nouvelle génération". CoreData est aussi un tres bon choix technique bien qu'audacieux.


----------



## GrandGibus (8 Janvier 2006)

Une amorce de débat... Selon toi, quelles raisons amènerait à faire les choix que tu cites ?


... Non pas que je sois d'accord ou pas, mais pour mieux mettre au clair les avantages et les inconvénients de chacune des options possible à notre ami...


----------



## Nicky Larson (8 Janvier 2006)

Apparemment, il y a des macs ET des PCs. Je ne vois pas trop comment cocoa pourrait l'aider.


----------



## molgow (8 Janvier 2006)

Je partage l'avis de GrandGibus. L'application web me semble une bonne solution. Ça facilite la distribution, l'utilisation multiplateforme et la création des interfaces graphiques. Après J2EE est quand même un monstre qu'il est difficile à apréhender. PHP est au contraire plus facile, mais il faut savoir bien l'utiliser car il est vite fait de coder pas propre à la "façon procédural".


----------



## Didier Guillion (9 Janvier 2006)

Bonjour,

Une question qui me turlupine et qui a trait aux outils de développement basés sur Obj-C/Nibs/Cocoa.
Enormément d'informations étant rangées dans les Nibs qu'utilisez vous comme outil pour vérifier que les Nibs des différentes langues sont bien synchronisés. J'ai une appli basés sur des Nibs en 6 ou 7 langues différentes et c'est vraiment un gros boulot de vérifier cela a la main. Et encore l'appli n'a qu'une dizaine de boite de dialogue...

Cordialement


----------



## Bernard Senior (9 Janvier 2006)

Merci à tous pour vos contributions. Je ne pensais pas que ma question susciterait autant de réponses...



			
				cretinoïde a dit:
			
		

> Quitte à "migrer" de Foxpro autant le faire vers en priorité vers :
> 4D ou FileMaker.



Ton avis n'est pas "crétin" . 4D fait partie des possibilités. Je l'ai pratiqué un peu et je dois dire qu'il fait tout ce que fait FoxPro et bien plus puisqu'il est ouvert sur le web. Ma seule objection contre 4D est que c'est un langage propriétaire et que ce choix s'avère définitif, pour autant qu'il puisse se maintenir indéfiniment..., avec l'obligation de passer au guichet à chaque mise-à-jour.
Pour FileMaker, il y a un truc vraiment gênant, c'est l'impossibilité d'exécuter un script quand on quitte un champ ou un objet. Les utilisateurs le réclament à cor et à cri. Du reste, je ne sais pas quelle astuce ils ont trouvée pour s'en passer.



			
				GrandGibus a dit:
			
		

> Tout ceci pour dire que le choix se fera en fonction de la _complexité fonctionnelle_ que ton programme devra rendre.


Il me semble être passé à côté de ton expression _complexité fonctionnelle_. Me permets-tu d'y revenir ? J'ai pensé qu'une copie d'écran vaut mieux qu'un long discours. Au premier plan, le formulaire d'expédition VPC. En arrière plan, une partie de la fiche-adresse avec les historiques et la liste des fiches à gauche. Il y a pas mal d'interactions entre les objets avec beaucoup de contrôles et messages d'alertes pour vérifier la cohérence des enregistrements. Ce module est un des plus complexes (1750 lignes dBase). Le programme comporte plus de 50 formulaires, dont la moitié environ sont simples. J'ai peut-être un peu sous-évalué le nombre de ligne de mon appli car je n'ai pas de compteur.
Comme tu peux le voir sur la copie d'écran, le formulaire fait pas mal de chose à la fois : comptabilité (on enregistre les ventes comptant, c'est donc ce module qui permets de générer une facture VPC qui regroupe toutes les ventes d'une période), traitement de la commande, statistiques avec le code pub., articles et emballage, poids pour éditer en auto les étiquettes colissimo avec le logiciel de La Poste Expeditor i-net (qui tourne sous Virtual PC). En sortie, on édite une liste des colis à faire, la course correspondante (tous les articles à sortir du stock), les bons de colisages à mettre dans les colis.
Il y a aussi beaucoup de raccourcis-clavier pour gagner du temps à la saisie. Comment un navigateur web peut-il gérer cela ? S'il faut cliquer partout, cela devient rapidement la galère.

Voir la pièce jointe 8343


----------



## SuperCed (9 Janvier 2006)

Une appli orientée web te donnera un accès quelque soit la machine et te permettra de concentrer tes données.
Le choix est donc maintenant restreint à php ou Java (J2EE).

Je te conseille php/mysql. C'est éprouvé, facile d'accès, rapide. Tu trouveras énormément de documentation.

J'ai pu tester un peu J2EE, mais pour moi, ça ne vaut pas le php, certe plus simpliste mais plus rapide pour le développement et les tests.

Molgow, je ne suis pas trop d'accord avec ta phrase qui dit associe le codage procédural avec du "mauvais" codage. Je pense qu'en objet comme en procédural, on peut mal ou bien programmer. La bonne ou mauvaise programmation est de toutes façons plus ou moins subjective.

PHP est pour moi, vraiment un langage qui sort du lot. Quand, en local, on peut discuter sur le C/C++/ Java pour savoir quel est le meilleur, sur le web, on ne discute plus trop la supériorité de php, même si certains cas bien précis s'adapte mieux à Java (surtout quand il y a déjà un existant dans ce même langage).


----------



## GrandGibus (9 Janvier 2006)

Si le choix du web est fait uniquement pour des questions de migration, déploiement... tu peux déployer très facilement et à grande échelle en faisant du Java WebStart. 

De plus, à regarder ton appli, il y a l'air d'avoir énormément de contraintes ergonomiques. Là, sur ce plan le web ne peut rivaliser avec du client _lourd_ !

Une solution pourrait être de développer ton application en Java standard (donc pas de web)... et n'ouvrir que les fonctionalités qui le méritent au web (facilement faisable). Ceci serait bien entendu valable que si le nombre de ces fonctions est restreint.

Pour résumer donc: si grosse contrainte d'ergonomie, liée à une utilisation majoritairement en intranet: Java (Swing) redeviendrait mon choix principal. 

Si par contre, tu veux faire de la consultation massive distante, alors il faudra dire un peu adieu à l'ergonomie et passer à du php. 


A noter que Swing n'est pas compliqué à apprendre, possède un modèle objet pas trop mal foutu (comparé à MFC, pour ceux qui connaissent ). De plus, il n'est pas si lent que ça, et on peut faire des choses qui ressemblent vraiment à du mac os en Swing (la preuve).


----------



## molgow (9 Janvier 2006)

SuperCed a dit:
			
		

> Molgow, je ne suis pas trop d'accord avec ta phrase qui dit associe le codage procédural avec du "mauvais" codage. Je pense qu'en objet comme en procédural, on peut mal ou bien programmer. La bonne ou mauvaise programmation est de toutes façons plus ou moins subjective.



Oui, je me suis pas très bien exprimé. Ce que je voulais plutôt dire c'est que PHP permet de faire de l'objet, mais ne t'y contraint pas... et donc c'est vite fait de tomber dans le piège d'utiliser des objets mais de programmer en procédural... ce qui donne qqch de très moche !


----------



## Bernard Senior (10 Janvier 2006)

Bon... Je crois qu'on a avancé d'un grand pas et qu'on arrive bientôt au bout.



			
				GrandGibus a dit:
			
		

> De plus, à regarder ton appli, il y a l'air d'avoir énormément de contraintes ergonomiques. Là, sur ce plan le web ne peut rivaliser avec du client _lourd_ !


Pour l'ergonomie, il m'est difficile d'y renoncer pour les postes de production. En effet, quand tu reçois, après un mailing catalogue, 100 commandes le 1er jour, puis 80 le second, puis 60..., (ce n'est pas La Redoute quand même!) si ton programme n'est pas rempli d'automatismes, de raccourcis, de contrôles de cohérence, c'est rapidement l'engorgement avec pour conséquence des retards et erreurs dans les envois, ce qui est du plus mauvais effet.  



> Une solution pourrait être de développer ton application en Java standard (donc pas de web)... et n'ouvrir que les fonctionalités qui le méritent au web (facilement faisable). Ceci serait bien entendu valable que si le nombre de ces fonctions est restreint.
> Pour résumer donc: si grosse contrainte d'ergonomie, liée à une utilisation majoritairement en intranet: Java (Swing) redeviendrait mon choix principal.


D'accord pour un client lourd pour les postes qui ont l'accès à l'ensemble des fonctions. D'accord aussi, pour un accès limité par intranet (en fait la consultation et éventuellement la modification des adresses). Il n'est pas question pour moi de consultation massive à distance.

Pour me lancer dans Java sans perdre trop de temps, il faudrait que tu puisse m'indiquer les raccourcis pour démarrer. J'ai regardé un peu sur Google Java et Java Swing (ton interface CCAM+ est superbe !  ). C'est la forêt ! Comment ne pas s'y paumer ! Voici quelques unes de mes interrogations :
1. Qu'est-ce qu'il faut installer sur Mac pour commencer à programmer en Java ? Editeur, compilateur ? Où trouver cela ?
2. Quel Interface Builder s'il en existe ? Quelle base de données ? Pilote JDBC ?
3. Quel tutoriel progressif choisir en français (le meilleur évidemment) ? Je lis l'anglais mais passé un certain degré d'abstraction technique, je suis largué. Si déjà c'est difficile à comprendre en français, alors l'obstacle de la langue ne fait qu'empirer la situation.
4. Parmi les bouquins proposés sur Project:Omega, quel est celui par lequel commencer en toute sécurité ? Puis, que choisir comme manuel de référence ?
5. Enfin, last but not least, il se peut que la marche s'avère trop haute pour moi (faut rester modeste !  ), quel délai minimum me donner avant de jeter l'éponge et me rabattre sur 4D ? Mes responsables n'apprécieraient pas trop que je passe 6 mois à me former pour finalement aboutir à une impasse.
Merci pour tout.


----------



## GrandGibus (10 Janvier 2006)

Tant mieux si tu y vois un peu plus clair . Voici quelques réponses en vrac:



			
				Bernard Senior a dit:
			
		

> 1. Qu'est-ce qu'il faut installer sur Mac pour commencer à programmer en Java ? Editeur, compilateur ? Où trouver cela ?


Java est par défaut en standard sur mac os x. 
De l'avis de beaucoup de gens (moi compris), Eclipse est l'un des meilleurs IDE (open source) du marché. Par contre, il est relativement gourmand, et tu pourras pester contre quelques lenteurs quand tu maîtriseras tous les raccourcis . Attention toutefois, il fait un peu peur au début, mais pas de panique. 



			
				Bernard Senior a dit:
			
		

> 2. Quel Interface Builder s'il en existe ?


Il existe de nombreux _interface builder_... mais aucun n'est vraiment convaincant. Je suis moi-même assez opposé à ce genre d'outil, surtout lorsqu'il s'agit de dépasser le cadre du simple maquettage. Là, c'est un point, je l'avoue, qui pourrait se révéler rédhibitoire au début: les interfaces sont _codées à la main_. D'un autre coté, cela t'apporte la maîtrise totale de ton code. Perso, je vais plus vite à la main qu'avec un builder...



			
				Bernard Senior a dit:
			
		

> 2. Quelle base de données ? Pilote JDBC ?


MySQL ! Il est dispo sous mac en distrib binaire. Le seul reproche (mais ça n'en est pas un pour toi), c'est qu'il est soumis à des contraintes pour le redistribuer. Sinon, que du bonheur. Tu trouveras des pilotes JDBC qui vont avec. D'ailleurs, la question de l'accés à la base de données est entière: peut-être envisageras-tu d'utiliser un ORM comme Hibernate/ ?



			
				Bernard Senior a dit:
			
		

> 3. Quel tutoriel progressif choisir en français (le meilleur évidemment) ?


Je passe :rose:... Peut-être chez developpez.com ?
Par contre, je me souviens avoir beaucoup utiliser les tutoriels de chez Sun pour tout l'apprentissage de Swing (le bon choix à mon avis pour ton programme comme librairie IHM). 



			
				Bernard Senior a dit:
			
		

> 4. Parmi les bouquins proposés sur Project:Omega, quel est celui par lequel commencer en toute sécurité ? Puis, que choisir comme manuel de référence ?


Je passe :rose:...



			
				Bernard Senior a dit:
			
		

> 5. Enfin, last but not least, il se peut que la marche s'avère trop haute pour moi (faut rester modeste !  ), quel délai minimum me donner avant de jeter l'éponge et me rabattre sur 4D ? Mes responsables n'apprécieraient pas trop que je passe 6 mois à me former pour finalement aboutir à une impasse.


Tout dépend de l'implication que tu mettras à l'apprentissage. Au début cela te fera un gros volume de nouveautés à absorber. Cependant, la communauté est sympa... Tu peux poster ici-même d'ailleurs. Je me souviens être passé à Java après une semaine de formation. Le seul point critique à mon avis est sur la conduite de projet elle-même. Il faut que tu appréhendes les problématiques dans le bon ordre si tu ne veux pas te trouver noyé sous des tonnes de docs ... mais ton expérience devrait t'aider sur ce point. 

Peut-être pourrais-tu négocier une semaine de formation à Java ? 

A voir sinon avec les modos du forum, s'il n'y a rien de confidentiel dans l'appli, tu peux ouvrir un fil consacré à cette dernière. Tu peux également te lancer dans l'avanture Open Source (et ainsi avoir de l'aide)...


----------



## OlivierL (10 Janvier 2006)

Attaquer seul pendant 6 mois un projet Java Swing sans encadrement me semble un risque énorme 

Tu vas forcément tomber dans tous les pièges possibles et imaginables. Tu vas devoir acquérir une masse d'information énorme : 

la programmation + conception OO (en incluant les Design Patterns) ;   
la syntaxe et le fonctionnement du langage Java ;   
les APIs Java (Swing ; JDBC...)   
la maitrise des outils choisis pour être productif   
...
Si tu es super motivé c'est un bon défi à relever.
Mais si j'étais ton chef, je refuserai un tel risque (mais je ne te connais pas, tu es peut être super autonome, débrouillard et bosseur).

Il te faudrait un "partenaire" à temps plein pendant 3 mois pour te lancer sur de bonnes bases. Mais là, gain énorme car tu connais alors un des langages les plus utilisés en entreprise, avec une énorme communauté derrière


----------



## Bernard Senior (10 Janvier 2006)

C'est une super discussion à rebondissements !



			
				GrandGibus a dit:
			
		

> Peut-être pourrais-tu négocier une semaine de formation à Java ?


Pour un tas de raison, cela ne m'est pas possible. Et quand bien même ce serait faisable, le prix d'une semaine de formation à Java risque fort de coûter plus cher que plusieurs années de mise-à-jour de 4D ! 




			
				OlivierL a dit:
			
		

> Attaquer seul pendant 6 mois un projet Java Swing sans encadrement me semble un risque énorme


Je crois que tu as raison de me refroidir. Je me suis laissé entraîner par l'enthousiasme communicatif de *GrandGibus*.  
Finalement, je me demande si l'avis de *Crétinoïde* n'est pas la voix de la sagesse !  
Je vais sérieusement y réfléchir.

En tous cas un grand merci à tous pour vos contributions et d'oeuvrer bénévolement à faire de ce forum un espace de convivialité et d'entraide.   (Dans la cambrousse en Provence à 6,5 km du central téléphonique, nous n'avons pu avoir l'ADSL qu'en août dernier ! )


----------



## SuperCed (10 Janvier 2006)

molgow a dit:
			
		

> Oui, je me suis pas très bien exprimé. Ce que je voulais plutôt dire c'est que PHP permet de faire de l'objet, mais ne t'y contraint pas... et donc c'est vite fait de tomber dans le piège d'utiliser des objets mais de programmer en procédural... ce qui donne qqch de très moche !


On est d'accord.


----------



## Macbasse (21 Janvier 2006)

D'abord merci aux contributeurs qui font qu'on peut encore lire des fils d'une telle qualité sans étripage stérile. 
Quand on parle de programmation c'est tellement rare...

Je voudrais simplement savoir si, 10 jours plus tard, tu (Bernard Senior) as pu prendre une décision plus ou moins définitive car tu exposes un cas qui n'est -- malheureusement ? -- pas isolé (et qui est aussi le mien dans une moindre mesure).

Bref, as-tu avancé dans une voie ? 

Merci.

A+


----------



## GrandGibus (21 Janvier 2006)

C'est marrant, car je me demande si une structure légère (genre asso de programmeurs libres Java sous mac) pourrait _proposer ses services_ à coûts réduits ?

Juste histoire de financer ses pasions (la prog et le mac) ? Car de mon coté (progs), je connais des personnes qui seraient prêtes à tenter l'expérience... et c'est pas la première fois que j'entends parler de ce besoin de migration _applis natives java_ à re-écrire dans un langage un peu plus moderne et plus _long terme[:i]... si toutefois cela peut vouloir dire quelque chose en informatique :rateau:._


----------



## Bernard Senior (25 Janvier 2006)

Macbasse a dit:
			
		

> Je voudrais simplement savoir si, 10 jours plus tard, tu (Bernard Senior) as pu prendre une décision plus ou moins définitive car tu exposes un cas qui n'est -- malheureusement ? -- pas isolé (et qui est aussi le mien dans une moindre mesure).


Excuse-moi de répondre seulement maintenant à ta question. J'avais vu mon fil s'enfoncer dans les profondeurs du forum et je pensais qu'il était définitivement noyé ! Je constate avec surprise et intérêt qu'il revient à la surface !
A vrai dire, je n'ai pas encore pris de décision et je continue mon évaluation.
Une chose est sûre, j'ai éliminé Java. En effet, l'apprentissage de Java représenterait un investissement trop lourd en terme de temps. Ce serait prendre un marteau pour écraser une mouche ! Java est certainement un magnifique outil mais je pense qu'il est hors de ma portée.
Restent en lisse, PHP et 4D.
Pour le couple PHP/MySQL, j'ai téléchargé MAMP. http://www.mamp.info/fr/home/. C'est simple et rapide pour une première évaluation. J'ai fait un essai d'import d'un fichier de 67000 codes postaux. Structure très simple : code pays, code postal, ville, plus quelques codes spécifiques pour le routage en France. phpMyAdmin ne permets pas d'importer des fichiers textes de plus de 32 ko. J'ai donc dû passer (un peu laborieux au début) par le terminal et le programme mysqlimport. Les résultats sont stupéfiants : moins d'une seconde pour importer 67000 fiches ! Ça décoiffe ! Dans phpMyAdmin j'ai fait quelques essais de manipulation du fichier. Je n'ai crée aucun index sur mon fichier code postaux. Je fais une requête SQL : trouver tous les fiches dont le nom de la ville finit pas "EINS". Résultat : 91 fiches en 0,25 sec. .... Ça laisse rêveur ! Une telle rapidité ouvre des possibilités vraiment intéressantes, hors de ma portée avec les outils que j'utilisais jusqu'à présent.
Le gros point noir des solutions Web, c'est que précisément, elles ne sont faites que pour une consultation intensive. Pour une application, disons classique, les impressions papier deviennent rapidement un casse-tête. Et aussi, l'ergonomie en prends un coup : plus de raccourcis-clavier, quickeys... Cela force à redessiner complètement l'appli pour limiter ces effets négatifs. Je suis en train de regarder du côté de JasperReports indiqué par GrandGibus mais ce n'est pas trop évident.
On m'a conseillé par ailleurs de regarder du côté de Dolibarr. http://www.dolibarr.com/. Ce n'est pas mal construit. On peut se servir du noyau de l'appli, contrôle des accès, niveaux d'accès, logique générale, en coupant tous les modules inutiles et en greffant ses propres modules. Cela permets de ne pas partir de zéro. Les impressions sont résolues (pas très souple pour les modif)  par la génération de fichiers PDF. Enfin, gros boulot en perspective quand même.
4D garde des atouts... payants. Les impressions sont faites à travers un éditeur graphique qui facilite énormément les modifications. De plus, au fil des années, 4D est devenu un gros truc, qui grossit toujours plus de l'apport des différentes technologies pour rester dans le coup. Et puis, langage propriétaire... donc, on ne bouge plus.
 Conclusion, je continue d'évaluer. Il faut tout de même être prudent quand on sait qu'on va devoir mettre les mains dans le cambouis pendant des mois...


----------



## GrandGibus (25 Janvier 2006)

Je ne sais pas si je l'avais mentioné précedemment, mais il y a iReport: l'éditeur de templates JasperReport...


----------



## Bernard Senior (26 Janvier 2006)

GrandGibus a dit:
			
		

> Je ne sais pas si je l'avais mentioné précedemment, mais il y a iReport: l'éditeur de templates JasperReport...


Merci du tuyau.
J'ai oublié une petite précision pour le test de MySQL. La machine que j'ai utilisée est un Mac Mini 1,33 GHz, donc pas le haut de gamme Apple.
Pour ceux que cela intéresse, la presse spécialisée a consacré des articles à Dolibarr : GNU Linux Magazine France n° 77 de novembre 2005 et Linux Pratique n°32 de novembre-décembre 2005.

A+


----------



## Macbasse (27 Janvier 2006)

Bernard Senior a dit:
			
		

> Excuse-moi de répondre seulement maintenant à ta question. J'avais vu mon fil s'enfoncer dans les profondeurs du forum et je pensais qu'il était définitivement noyé ! Je constate avec surprise et intérêt qu'il revient à la surface !
> A vrai dire, je n'ai pas encore pris de décision et je continue mon évaluation.
> Une chose est sûre, j'ai éliminé Java. En effet, l'apprentissage de Java représenterait un investissement trop lourd en terme de temps. Ce serait prendre un marteau pour écraser une mouche ! Java est certainement un magnifique outil mais je pense qu'il est hors de ma portée.
> Restent en lisse, PHP et 4D.
> ...



Merci de ta réponse et pour ces pistes. Ca permet de suivre les investigations des autres, ce qui est souvent instructif.  

A+


----------



## SuperCed (27 Janvier 2006)

En fait, ton problème est plutôt de savoir si tu veux une appli basée sur du web, donc très compatible, ou une vrai appli, qui serait orientée réseau, avec une meilleure interface.

L'option web a certains avantages, la compatibilité en est un énorme. par contre, en effet, tu perdras certainement en ergonomie par rapport à une solution 4D.

Si le fait de centraliser tes données et que l'aspect réseau est très important, alors la solution web est très bonne.
Si c'est plutôt une appli qui tournera sur un réseau local, avec seulement quelques postes qui vont s'en servir, alors peut-être que 4D est meilleur.

Il faut que tu saches aussi que si 4D rassemble la base de données et la partie interface, la solution php mysql t'apporte plus de souplesse.
En effet, rien ne t'oblige à l'avenir à rester sur une formule web avec ta base mysql. Tu peux garder celle-ci et faire une interface avec la plupart des langages existant aujourd'hui.
Tu pourras par exemple faire du Java (J2SE) qui dialogue avec ta base MySQL, ou du python, perl, Cocoa, X11, bref, vraiment ce que tu souhaites. Si ça se trouve, même 4D te permet d'utiliser des bases MySQL, mais bon, peut-être que je m'avance un peu là... c'est à vérifier.


----------



## Bernard Senior (28 Janvier 2006)

SuperCed a dit:
			
		

> En fait, ton problème est plutôt de savoir si tu veux une appli basée sur du web, donc très compatible, ou une vrai appli, qui serait orientée réseau, avec une meilleure interface.


Merci de ton avis. Je suis tout à fait d'accord. C'est exactement le dilemme. Cependant, et précisément pour les raisons que tu donnes, je penche de plus en plus vers une application web. Cette solution me semble plus prometteuse. C'est également exact que j'ai plus de possibilités de repli en cas de problème avec une base MySQL puisque je peux la piloter avec tous les langages que tu cites, 4D compris ainsi que je l'ai lu dans la doc. de présentation (il faut simplement un pilote ODBC).
Encore merci à tous pour vos avis éclairés.   Il me faut maintenant aller au charbon !


----------



## Anonyme (28 Janvier 2006)

Simple curiosité de ma part : puisqu'on est dans les interfaces Web, est-ce qu'il y en a parmis vous qui travaillent avec Xul pour faire des applications Web (je ne suis pas informaticien :rose? 

Si je suis hors-sujet dites-le...


----------



## SuperCed (30 Janvier 2006)

Bernard Senior a dit:
			
		

> Merci de ton avis. Je suis tout à fait d'accord. C'est exactement le dilemme. Cependant, et précisément pour les raisons que tu donnes, je penche de plus en plus vers une application web. Cette solution me semble plus prometteuse. C'est également exact que j'ai plus de possibilités de repli en cas de problème avec une base MySQL puisque je peux la piloter avec tous les langages que tu cites, 4D compris ainsi que je l'ai lu dans la doc. de présentation (il faut simplement un pilote ODBC).
> Encore merci à tous pour vos avis éclairés.   Il me faut maintenant aller au charbon !



N'hésite pas à me contacter si tu as besoin d'un coup de main pour démarrer ou pour poser le problème. Pareil si tu as besoin de voir comment organiser ta base de données.
J'ai l'habitude, et je n'ai pas de travail avant avril, donc je peux t'aider à mettre en place ton appli.

Bien sur, je facture, mais bon, ça vaut peut-être le coup si tu veux vraiment partir sur de bonnes bases ou si tu désires un avis extérieur.


----------



## molgow (30 Janvier 2006)

gloup gloup a dit:
			
		

> Simple curiosité de ma part : puisqu'on est dans les interfaces Web, est-ce qu'il y en a parmis vous qui travaillent avec Xul pour faire des applications Web (je ne suis pas informaticien :rose?



Intéressant comme idée, je n'y avais jamais pensé. Mais ça limite tout de même d'être obligé d'utiliser Firefox ou Mozilla ensuite. Je suis pas sûr que les fonctionnalités que XUL pourrait offrir en plus (par rapport à HTML/CSS/JavaScript) en valent la peine ?!


----------



## Anonyme (30 Janvier 2006)

Ben tu peux faire une application avec _une vraie interface graphique_ multiplateforme. Mais c'est vrai faut avoir firefox installé. 

http://filemanager.mozdev.org/

http://www.faser.net/mab/chrome/content/mab.xul


----------



## Raleur Pro X (31 Janvier 2006)

Bernard Senior a dit:
			
		

> Merci de ton avis. Je suis tout à fait d'accord. C'est exactement le dilemme. Cependant, et précisément pour les raisons que tu donnes, je penche de plus en plus vers une application web. Cette solution me semble plus prometteuse. C'est également exact que j'ai plus de possibilités de repli en cas de problème avec une base MySQL puisque je peux la piloter avec tous les langages que tu cites, 4D compris ainsi que je l'ai lu dans la doc. de présentation (il faut simplement un pilote ODBC).
> Encore merci à tous pour vos avis éclairés.  Il me faut maintenant aller au charbon !


 
Confronté au même choix (4D-php/SQL), j'ai choisie MAMP.
pour les raisons suivants :
1- 4D politique de license (il faut une license par serveur en plus du prix 4D)
2- 4D est très flexible ayant lu les manuels 4D (4.000 page !) et deux livres php/MySQL, je pense que le php n'est pas aussi dificile que l'on ne pense, il y a beaucoup de similitude avec 4D.
3- 4D sera mis à jour en 2007, ce sera une grande mise-à-jour, et selon le podcast de MacG, 4D ressemblera plus à mySQL.. alors quelle en sera l'avantageµ
4- 4D Serveur sur Mac c'est n'est pas terrible en tant que serveur, les performances sont beaucoup mieux sur PC (un Pentium 2.6 Ghz et plus de deux fois plus rapide qu'un dual G5 2.7... dixit support après vente 4D) et comme on veut tous du Mac...  

Mon conseil :
- MAMP (seulement je n'ai pas d'info quand à la disponibilité d'une version dual binary...:sleep: )
- CSS
- xServe (quand seront ils mis à jour :hein: )

Comme livre pour le php je peux vous conseiller : (en Anglais) "Beginning PHP, Apache, MySQL Web development" de Wiley Publishing, Inc (WROX), c'est un très bon livre éventuellement le compléter avec un livre sur MySQL (ils en parlent que vaguement)

Pour les rapports iReport à l'air prometteur.. avez vous achetez le iReport manual v1.1 ? et oui il faut payer pour voir si un produit convient, le monde à l'envers, mieux vaudrait payer pour le produit...
Une autre option se serait d'utiliser Runtime Revolution, une version (d'il y a un an) est offert à l'achat de Mac Format (UK), c'est une sorte de Hypercard avec lequel on peut compiler des applications avec interface mySQL, SSL etc..  donc à priori facile à utiliser... je ne l'ai pas encore essayé, mais cela à l'air prometteur aussi...


----------



## Bernard Senior (31 Janvier 2006)

Raleur Pro X a dit:
			
		

> Confronté au même choix (4D-php/SQL), j'ai choisie MAMP....
> Comme livre pour le php je peux vous conseiller : (en Anglais) "Beginning PHP, Apache, MySQL Web development" de Wiley Publishing, Inc (WROX), c'est un très bon livre éventuellement le compléter avec un livre sur MySQL (ils en parlent que vaguement)


J'ai lu avec beaucoup d'intérêt ta contribution. Cela me conforte dans l'orientation que je prends. Merci pour tes tuyaux sur la doc. Quelqu'un m'a passé "Programmation en PHP" de Leon Atkinson (en français) éditions CampusPress. C'est un peu ancien (PHP3) mais cela me parait bien pour débuter. Pour MySQL j'ai téléchargé sur le site de Nexen la doc. version 4.1 entièrement traduite en français (1000 pages quand même !). Pour construire ma base c'est plus que suffisant.



			
				SuperCed a dit:
			
		

> N'hésite pas à me contacter si tu as besoin d'un coup de main pour démarrer ou pour poser le problème. Pareil si tu as besoin de voir comment organiser ta base de données.


Merci de ta proposition. Je pense que cela devrait rouler... Construire une base MySQL ne me parait pas trop difficile. L'analyse de mon appli. étant déjà faite, il me suffit de reprendre les structures de mes fichiers dBase.

A+


----------



## Tarul (31 Janvier 2006)

Excusez moi de cette intrusion, mais démarrer php avec un livre traitant du PHP3 me parais une trés mauvaise idée.

Principalement pour 2 raisons : 
-si les structures des scripts php sont les mêmes de php3 et de php4, php4 apporte un gain de sécurité plus important(logique) mais ca passe par des petits truc qui change au niveau syntaxique. Et si tu commences par php3 sur un serveur php4(les serveur usant encore php3, ben j'en ai pas trouvé ) tu vas avoir des problèmes qui viendront de petites chose qui change(mais faut le savoir). et il te faudra tôt ou tard t'habituer à la syntaxe de php4.
-enfin il me semble que plus ou moins brève écheance, nous allons passer de php4 à php5(les principales différences entre php4 et ph5 vient de la syntaxe objet).

bref, je ne peux que te conseillais de démarrer toute de suite par php4 pour sa syntaxe plus récente, et parce que la majorité des serveurs php tourne encore sous php4.
il existe des sites biens pour débutant.(je pense à http://www.phpdebutant.org)

@++


----------



## Bernard Senior (1 Février 2006)

Tarul a dit:
			
		

> Excusez moi de cette intrusion, mais démarrer php avec un livre traitant du PHP3 me parais une trés mauvaise idée...


Un grand merci. Tu n'as pas à t'excuser. C'est sympa de me prévenir des pièges avant que je n'ai vraiment commencé. Je pensais naîvement que la compatibilité était assurée entre les différentes versions de PHP, autrement dit que PHP4 faisait tout ce que faisait PHP3 sans modif... Je vais aller faire un tour sur le site que tu me conseilles. Je cherchais en plus un site pour débutants. Pas évident de s'y retrouver avec le foisonnement de sites dédié à PHP. Me voilà servi. Encore merci.


----------



## Tarul (2 Février 2006)

pas de soucis. 

et si tu vas sur http://www.php.net/manual/fr/ et sur http://www.nexen.net/docs/php/annotee/tu trouveras de la documentation en ligne de php en francais et quelque trucs à ne pas faire(ou à faire. )


----------



## Bernard Senior (3 Février 2006)

Tarul a dit:
			
		

> pas de soucis.
> et si tu vas sur http://www.php.net/manual/fr/ et sur http://www.nexen.net/docs/php/annotee/tu trouveras de la documentation en ligne de php en francais et quelque trucs à ne pas faire(ou à faire. )


Merci pour ces nouveaux tuyaux. J'ai commencé le tutoriel de phpdebutant. C'est au poil ! Exactement ce que je cherchais pour débuter.  J'ai aussi téléchargé la doc de php en format chm. Impeccable pour la consultation !


----------



## Macbasse (3 Février 2006)

Bernard Senior a dit:
			
		

> Merci pour ces nouveaux tuyaux. J'ai commencé le tutoriel de phpdebutant. C'est au poil ! Exactement ce que je cherchais pour débuter.  J'ai aussi téléchargé la doc de php en format chm. Impeccable pour la consultation !


Salut !

Puisque je vois que tu sembles glisser vers une solution "Web" pour créer une application, as-tu jeté un oeil du côté du framework Ruby on Rails (http://www.rubyonrails.org/) ? 
J'imagine que l'idée de pouvoir s'appuyer sur un outil plus avancé pour créer des interfaces n'est pas négligeable dans le projet que tu as. 
Personnellement c'est ce qui me fait traîner les pieds dans l'idée d'utiliser PHP/MySQL. RoR mise sur AJAX qui est visiblement fort prometteur en ce qui concerne les possibilités qu'il laisse pour les interfaces.

Il y a par exemple un bouquin sympa sur le sujet : 

http://www.eyrolles.com/Informatique/Livre/9782212117462/livre-ruby-on-rails.php

Reste qu'il faut se taper un nouveau langage et que je ne connais pas la courbe de progression d'un novice en Ruby.

Quelqu'un a-t-il du recul là-desus ?

A+


----------



## Bernard Senior (5 Février 2006)

Macbasse a dit:
			
		

> Salut !
> Puisque je vois que tu sembles glisser vers une solution "Web" pour créer une application, as-tu jeté un oeil du côté du framework Ruby on Rails (http://www.rubyonrails.org/) ?


Merci de ton avis. Décidément, ce fil lancé voici plus d'un mois, n'en finit pas de rebondir grâce à vos multiples contributions.   Cela semble prouver que nous y abordons ensemble des thèmes qui sont au coeur des préoccupations de beaucoup.

J'ai pris le temps hier après-midi d'examiner ta suggestion. J'ai même téléchargé le tutoriel Ruby de Projectomega.org. Il s'avère que Ruby est un langage de POO pur et dur, puisque "tout est objet" (cf. tuto. par ailleurs très pédagogique). Pour moi, qui vient d'une longue pratique de la programmation procédurale, cela constitue un obstacle supplémentaire. En effet, c'est déjà lourd de changer de langage de programmation mais si en plus on plonge sans transition dans la POO, la marche peut s'avérer trop haute, à moins d'être un petit génie !  PHP présente pour moi l'avantage de permettre les deux approches de programmation. Je sais que les puristes considèrent que c'est un peu bancal. Certes ! Mais je ne vise pas impérativement la programmation concise, élégante et tout et tout... Je cherche avant tout l'efficacité et une certaine pérennité. PHP doit bien avoir quelques qualités notables pour être devenu si rapidement un must sur le web  et sa très forte implantation augure bien de l'avenir.

Quand à Ruby on Rails, je suppose que l'utilisation de ce framework (charpente, bâti, cadre, squelette...au choix) impose d'avoir bien assimilé la programmation en Ruby, afin de pouvoir y implanter et développer son propre code.

A+


----------



## SuperCed (6 Février 2006)

Bernard Senior a dit:
			
		

> Je cherche avant tout l'efficacité et une certaine pérennité. PHP doit bien avoir quelques qualités notables pour être devenu si rapidement un must sur le web  et sa très forte implantation augure bien de l'avenir.



C'est indéniable. Autant pour faire de la programmation d'applicatifs, il reste toujours des débats entre celui qui va utiliser du Java, ou alors du C, ou encore du C++, ou encore Python, etc. Autant pour le web, c'est très clair. S'il n'y a pas un gros bloc métier en Java déjà présent, c'est php qui est loin devant. pour le web, sa suprématie n'est plus à démontrer.


----------



## Tarul (7 Février 2006)

c'est vrai, j'avais oublié ruby. j'avais un peu maté le tutoriel video. c'est quand même impréssionnant. mais contrairement à php, il n'y a pas beaucoups d'herbergeur à ma connaissance qui le propose.

pour le developement ne objet, c'est pas si dur que cela semble être. le tout est de trouver des bon tuto lorsqu'on ne peut pas être en cours de dev(comme moi ^^, licence info powa ). sinon comme ressource supplémentaire il y a http://www.developpez.com/ et [URL="http://www.codes-sources.com"]http://www.codes-sources.com. Sinon il y a aussi [URL="http://phpfrance.com"]http://phpfrance.com, et enfin [URL="http://asp-php.net"]http://asp-php.net
Si les deux premiers sont généraliste, ils disposent de bon tutoriels en tout genre, des codes sources, des FAQ complète et un forum dynamique. les deux derniers sont plus orienté php, avec des explications de comment faire certaines chose(comme un uploadeur de fichier).[/URL]
[/URL]
Je dirais qu'au final l'idéal est de choisir le langage qui te plait le plus, qui sera rapproche le plus a ton objectif, et le plus répandu(dans le cas d'une utilisation sur un serveur web).[/URL]

Je terminrais par dire, je te déconseilles fortement le java pour faire des pages web ou des servlets(comme on dit). c'est peut être puissant, mais faut s'y mettre pour faire ce que l'on veut.(en plus d'apprendre l'objet, le java, il te faudra apprendre l'api correspondant au servlets, et l'utilisation du serveur tomcat qui gère les servlet). On a commencé à en faire en cours, et j'ai beaucoups de mal(faudrais peut être que j'y passe plus de temps dessus aussi ).
[URL="http://www.codes-sources.com"][URL="http://phpfrance.com"][/URL][/URL]


----------



## Bernard Senior (8 Février 2006)

Tarul a dit:
			
		

> Pour le developement ne objet, c'est pas si dur que cela semble être. le tout est de trouver des bon tuto lorsqu'on ne peut pas être en cours de dev(comme moi ^^, licence info powa ). sinon comme ressource supplémentaire il y a http://www.developpez.com/ et [URL="http://www.codes-sources.com"]http://www.codes-sources.com. Sinon il y a aussi [URL="http://phpfrance.com"]http://phpfrance.com, et enfin [URL="http://asp-php.net"]http://asp-php.net


Merci de tes tuyaux. J'avais déjà repéré phpfrance.com. C'est vrai que le développement orienté objet n'est peut-être pas si difficile. Mais bon... J'ai regardé un peu sous le capot de Dolibarr, une application web libre. Cela fait quand même un peu peur...  Il faut s'accrocher ! Enfin, on verra.


----------



## OlivierL (9 Février 2006)

*C'est vrai que le développement orienté objet n'est peut-être pas si difficile

*C'est pas si difficile, mais c'est surtout très facile de faire n'importe quoi et même pire 
Si on passe aux technos objets, il faut avoir conscience de ce que ca veut dire. Si c'est pour faire du spaghetti en Java, alors là c'est la cata !


----------



## Bernard Senior (10 Février 2006)

OlivierL a dit:
			
		

> *C'est vrai que le développement orienté objet n'est peut-être pas si difficile
> *C'est pas si difficile, mais c'est surtout très facile de faire n'importe quoi et même pire
> Si on passe aux technos objets, il faut avoir conscience de ce que ca veut dire. Si c'est pour faire du spaghetti en Java, alors là c'est la cata !


Qu'est-ce tu veux dire par là ? Je ne vois pas trop ce que peut être de la prog. en spaghetti !  Peux-tu m'éclairer là-dessus ? Si je me lance dans l'objet, j'aimerais démarrer sur de bonnes bases. La difficulté pour moi, c'est d'arriver concrètement à transformer du code procédural en code orienté objet. J'ai regardé quelques tutoriels simples sur les classes en PHP. Cela reste un peu théorique. Je ne vois pas trop comment appliquer cela à mes propres lignes de code.
Je me demande également si je fais bien de vouloir reprendre et adapter une application web existante. Cela suppose que je comprennes parfaitement la structure du code. De plus, Dolibarr est une appli. PHP4. Or, d'après ce que j'ai compris, le changement entre PHP4 et PHP5 porte surtout sur le modèle objet. Comme Dolibarr est entièrement programmée en objet, il me semble que ce serait préférable de me lancer directement en PHP5.


----------



## GrandGibus (10 Février 2006)

[ce n'est que mon avis]

Pour ma part, je commencerai par analyser mes besoins et essayer de séparer le fonctionnel: les actions à mener du structurel: les structures qui véhicules les données. En cela, l'application existante pourra s'avérer très utile, puisqu'il s'agit d'un portage. 

De plus, autant il est bien de _s'inspirer_ de code existant: genre telle fonction comment ont-ils pu faire ?... Mais cela peut s'avérer aussi dangereux: Pour tordre un cadre existant, il faut bien avoir conscience des risques et des limites, sous peine de voire ce cadre tenir guère longtemps et se retrouver prisonnier d'un carcan (image du cadre ).

Donc, pour résumer, je mets d'un coté tout ce dont j'ai besoin:

identifier les acteurs (qui)
identifier les services rendus (fait quoi)
identifier les structures qui vont véhiculer les données pour ces mêmes services (avec quoi)

A cela il pourrait convenir de distinguer le modèle de persistence: l'organisation des données en base. 

Tout ceci peut d'ailleurs être réalisé sans aucune notion de quel langage que ce soit. Par contre, étant donné que tu pars d'une application Web, une attention particulière sera portée sur la _granularité_ des services et des traitements. 

[/ce n'est que mon avis]



... mais ce n'est que mon avis :mouais:


----------



## Tarul (11 Février 2006)

GrandGibus a dit:
			
		

> [ce n'est que mon avis]
> 
> Pour ma part, je commencerai par analyser mes besoins et essayer de séparer le fonctionnel: les actions à mener du structurel: les structures qui véhicules les données. En cela, l'application existante pourra s'avérer très utile, puisqu'il s'agit d'un portage.
> 
> ...



c'est déjà une trés bonne base comme réflexion.
En programmation si on a analyse mal, on se retrouve a programmer n'importe comment. Et en objet cela peut avoir beaucoups de conséquence puiseque le but de l'objet est de pouvoir réutiliser ce qu'on a déjà créé(ou par d'autres). Et donc un objet mal programmé peut créer des problèmes dans les applis qui l'utilise.

pour en revenir entre la difference entre PHP4 e t PHP5 porte effectivement sur les objets. PHP5 introduit des conceptes objets supplémentaires comme l'heritage qui était inexistant dans PHP4. ce n'est qu'un exemple. Si tu va sur php.net tu verras les changements dans le change log de php5.

Si tu reprends une appli web, avant de faire quoique ce soit, prend bien le temps de l'étudier. Afin d'en faire une critique, et de voir ce que toi tu veux y apporter comme modification.
et mais comme dit Grandibus, ce n'est que mon avis


----------



## Bernard Senior (11 Février 2006)

GrandGibus a dit:
			
		

> Pour ma part, je commencerai par analyser mes besoins et essayer de séparer le fonctionnel: les actions à mener du structurel: les structures qui véhicules les données. En cela, l'application existante pourra s'avérer très utile, puisqu'il s'agit d'un portage.


Bon. Attends ! ... Je suis déjà un peu largué !  Tu navigues à trop haute altitude pour moi !
Je te dis ce que je comprends : tu me proposes de (ré)-analyser mon problème. Autrement dit, tu me demandes de coucher sur le papier ce que j'ai dans le ciboulot. En effet, jusqu'à présent, j'ai fait l'analyse au fur et à mesure de la programmation et c'est d'ailleurs, la plupart du temps, les faits dûment constatés qui m'ont forcé à modifier mon application. Exemple : pour le module VPC, je n'avais pas prévu de gérer les stocks, pour la raison que nous ne proposions que des articles (principalement des livres) de notre fonds. En octobre dernier, sur un conseil extérieur, nous avons proposé à nos clients en plus de nos articles, des articles d'autres éditeurs. Et là, catastrophe, évidemment ! Nous avons eu des difficultés de réapprovisionnement chez les éditeurs extérieurs, délais, indisponibilités,... . D'où des commandes bloquées sans aucune possibilité de les enregistrer à l'avance, puisque le programme met systématiquement en expédition toute commande saisie. Puis, quand les articles manquants sont arrivés, nouvelle difficulté pour les servir dans l'ordre des commandes. Comme il y avait plusieurs articles manquants en même temps, cela a engendré une belle pagaille ! Conclusion : il faut modifier le programme !
Ma philosophie n'est pas de faire le programme nec plus ultra mais celui qui colle à la réalité du moment. Evidemment, un changement dans les conditions d'exploitation survenant, cela m'oblige à des modifications. Cela présente néanmoins l'avantage de ne pas me faire développer des fonctions qui à l'usage s'avèrent inutiles.
Pour reprendre ta proposition, je vais essayer d'appliquer tes conseils juste à la gestion du fichier des adresses (pour simplifier). Admettons que je n'ai que 2 niveau d'acteurs : utilisateur lambda et secrétaire. Les trois colonnes sont sensées correspondre à tes 3 points (Bon.. à peu près...pas évident de faire des colonnes. Je n'ai pas le truc)

1 Utilisateur lambda - 2 requêtes consultation - 3 liste/fiche détaillée
1 Secrétaire - 2 requêtes consultation -3 liste/fiche détaillée
2 ajout- 3 fiche détaillée
2 modification - 3 fiche détaillée
2 suppression​Est-ce que ça colle ? Ou bien est-ce que je n'ai rien compris ? Faut-il détailler davantage au niveau "fait quoi" et au niveau "avec quoi". Où donc les classes peuvent-elles intervenir ? Au niveau fonctions (services rendus) ?
Et la granularité ? Je ne vois pas trop. Serait-ce de ne pas avoir des classes trop volumineuses ? Mais plutôt de les multiplier en petites classes et sous-classes simples et facilement utilisables ?
En tous cas, merci de ton avis... qui n'est que ton avis


----------



## GrandGibus (12 Février 2006)

Bernard Senior a dit:
			
		

> Autrement dit, tu me demandes de coucher sur le papier ce que j'ai dans le ciboulot.


 Tout à fait. Cela présente les avantages de:
mettre du clair dans sa tête... de manière globale (et pas au fur et à mesure )
communiquer plus aisément avec d'autres personnes
se rendre ainsi compte d'incohérence(s)
et surtout d'avoir un excellent point de départ pour les tests, la documentation et la validation
Partant de ce constat, ce n'est vraiment pas une perte de temps !





			
				Bernard Senior a dit:
			
		

> pour le module VPC, je n'avais pas prévu de gérer les stocks, pour la raison que nous ne proposions que des articles (principalement des livres) de notre fonds. En octobre dernier, sur un conseil extérieur, nous avons proposé à nos clients en plus de nos articles, des articles d'autres éditeurs.


Partons de ce qu'UML appelle les cas d'utilisation. Ce que tu me décris là a tout à fait l'air de ressembler à un nouveau cas d'utilisation. Ainsi, il y a de fortes chances pour que cela se traduise par l'ajout d'un nouveau service au système. Il n'y a pas de raison pour que tes objets ou les autres services soient _impactés_ par l'ajout d'un nouveau service :hein:.




			
				Bernard Senior a dit:
			
		

> Et là, catastrophe, évidemment !


Je veux bien te croire :rateau:!



			
				Bernard Senior a dit:
			
		

> D'où des commandes bloquées sans aucune possibilité de les enregistrer à l'avance, puisque le programme met systématiquement en expédition toute commande saisie. Puis, quand les articles manquants sont arrivés, nouvelle difficulté pour les servir dans l'ordre des commandes.


Pour reprendre ton exemple et en amorçant le début d'analyse. Ton système (le logiciel) propose plusieurs services, dont on peut citer:
L'authentification
La gestion des utilisateurs du systèmes
Service d'expédition
Service de gestion des commandes
Le détail du service d'authentification pourrait être:
boolean login(User user);
void logout(User user);
Ici _User_ est _abstrait_. Ainsi, d'un point de vue du service d'authentification, il n'y a pas de différence entre un utilisateur lambra et une secrétaire !
Cela se traduit en objet par une interface (ou classe de base) User qui a 2 sous-classes dérivées: secrétaire et lambda.

Le détail de gestion des utilisateurs pourrait être:
void addSecretaire(String name, String password); // le nom doit être unique dans le système, sinon exception
void addLambda(String name, password);
void remove(String name);
Remarque, il n'apparaît nulle part des notions d'ID ou de design de base de données... ce n'est que bien plus loin dans les détails d'implémentation qu'il faudra se pencher sur ce point. 

Le détail du service de gestion des commandes pourrait être:
Command createCommand(String name);
void addArticle(Command cmd, Article art);
void removeArticle(Command cmd, Article art);
Ici encore, _Article_ doit être une notion _abstraite_ pour les mêmes raisons évoquées précedemment. 



			
				Bernard Senior a dit:
			
		

> Evidemment, un changement dans les conditions d'exploitation survenant, cela m'oblige à des modifications.


Pas forcément. En utilisant le bon niveau d'abstraction avec Article et User .... c'est à ça que ça sert l'objet !



			
				Bernard Senior a dit:
			
		

> Ma philosophie n'est pas de faire le programme nec plus ultra mais celui qui colle à la réalité du moment.


L'analyse nec plus ultra sera ton meilleur investissement . Tu auras tout le temps pour peaufiner l'implémentation (le passage aux lignes de code) et ainsi aboutir au _programme nec plus ultra_.


Si tu as tout _dans ta tête_, et vu la taille de ton application, tu ne devrais pas en avoir pour longtemps à ainsi faire l'analyse de ta problématique. De plus, à première vue, ton application ne semble pas avoir de problématiques _inconnues_... à savoir qu'on reste quand même dans des problématiques d'informatique de gestion très classiques, et donc, à ce titre, peut-être que des ouvrages d'analyse pourraient te montrer la voie.

C'est aussi sur la base de cette analyse que tu pourras définitivement décider s'il vaut mieux partir sur l'utilisation et le paramétrage de progiciel existants, ou bien partir sur la voie du développement maison ! (et la boucle est bouclée).


----------



## Bernard Senior (12 Février 2006)

GrandGibus a dit:
			
		

> Tout à fait. Cela présente les avantages de:
> mettre du clair dans sa tête... de manière globale (et pas au fur et à mesure )
> communiquer plus aisément avec d'autres personnes
> se rendre ainsi compte d'incohérence(s)
> ...


Un grand merci de passer du temps avec un béotien comme moi. Tu clarifies plein de choses. Peut-être bien que c'est toi qui nous vaut les 5 étoiles qui sont apparues hier sur ce fil. 
Je vais me mettre sérieusement à coucher sur le papier l'analyse de mon problème et ainsi mettre en application tes conseils.


----------



## Gabone (17 Août 2006)

Merci, pour votre poste qui est tr&#232;s enrichissant pour moi. Et qui m&#8217;a bien aid&#233;e.


----------

