Bonjour !
 
 
J'ai un petit problème =( Je viens d'être engagé dans une boite pour remettre toute l'informatique d'aplomb. En bref, je dois :
- remplacer toutes les applications en évitant les encodages multiples (--> centraliser les données). Cela concerne un fichier client, l'encodage des rapports de visite, l'utilisation du planning de charge, etc ...
- prévoir que certaines applics doivent être accessibles de l'extérieur par les commerciaux.
 
Mon problème, c'est que je ne sais pas dans quel langage je vais bien pouvoir faire ça, ni quelle architecture utiliser. J'ai pensé à pas mal de trucs :
- tout dans des pages web (avec ou sans frameworks, avec Xml, Java, Php, ASP.Net, ...) ;
- applications classiques client-serveur avec serveur de données (via sockets et un protocole made in myself) ;
- les trucs genre EJB en Java pour séparer la logique de l'applic de la présentation ...
 
D'un point de vue personnel, j'aurais bien aimé passer à Linux dans l'entreprise. Je connais plus ou moins superficiellement pas mal de langages et je suis prêt à investir le temps qu'il faudra pour maitriser une approche intéressante, propre, modulaire, robuste au temps... (et si possible rapide à mettre en route ...).
 
Si vous étiez à ma place, que choisisseriez-vous ?

Ben non. Je peux le faire de pas mal de manières, mais j'aurais souhaité des retours de personnes qui ont plus d'expérience que moi, qui utilisent quotidiennement des outils que je ne connais pas forcément ...
 
C'est juste pour mieux faire que je demande. En tant que jeune diplômé, j'estime qu'il est normal que je ne maitrise pas encore tous les outils de développement pro. Entre faire un projet pour l'école et une applic complètement fonctionnelle, y a un monde ...
 
Toi qui es développeur web, tu utiliserais quoi pour réaliser ce type d'application ?

moi j'utilise php / Mysql pour la partie serveur , et un peu de javscript cote client pour améliorer l'ergonomie
 
ceci dit, il faut voir quelles sont tes connaissances en développement ?

Merci pour ta réponse !
 
La solution classique quoi ... Je me demande si ce n'est pas le plus simple ... Utilises-tu des frameworks pour t'aider ? Genre Dojo, Zend, etc ? Ou tu fais ça en dur ?
 
J'ai regardé un peu les frameworks JS, mais je me pose tout de même quelques questions :
- que donnent toutes ces applics basées sur Ajax ? Si la communication des données se fait par des requêtes/réponses en xml, toute personne qui accède au code de ma page (sniffer, via le cache du navigateur, ...) peut également manipuler les données sur mon serveur ! Ou alors j'ai raté une étape ?
- comment traites-tu les problèmes d'accès concurrents à ta base de donnée ? Une première requête qui locke les éléments et une seconde pour (éventuellement) en modifier certains ? Ca me semble pas mal, mais comment éviter de bloquer le système si l'utilisateur sort fumer sa cigarette avant de libérer les enregistrements ? Il faudrait un timeout ou quoi, non ? C'est disponible en php ?
 
Niveau connaissances, je suis à l'aise en C++ et Java. J'ai déjà fait du php, javascript (avant la sortie de Prototype, etc), etc mais j'ai besoin de rafraichir mes connaissances et d'approfondir certains sujets ...

Si t'es à l'aise en java, pourquoi ne pas le faire ne Java avec Hibernate pour le DAO qui a l'air de te poser problème ?

Salut !
 
Merci pour ta réponse.
Effectivement, je suis à l'aise en Java, mais je ne connaissais pas Hibernate. Comme quoi ma demande initiale n'était pas tout à fait dénuée de sens
 
Après documentation, je vois que ça aurait pu se faire avec Hibernate comme tu le proposes ... Mais là, je me suis lancé pour de bon dans une approche php/Javascript sans framework. On verra bien ce que ça donnera !

does not compute ...

Si tu as des informations susceptibles de m'aider, n'hésite pas à les donner. Là j'ai un peu l'impression que tu as de l'expérience, que tu me vois peut-être aller dans une mauvaise direction et que, plutôt que de me prévenir en m'expliquant ce que toi tu ferais, tu me laisses continuer ... !
 
Le php/Javascript, au moins, je connais et je sais à quoi m'en tenir. C'est peut-être pas optimal (c'est même sûr), mais c'est pas bien plus malin de me lancer dans des solutions inconnues aujourd'hui et me rendre compte dans quelques mois que j'ai mal utilisé l'outil et que je ne peux pas faire proprement ce que je dois faire.
Par contre, le php/html/js c'est très simple au déploiement et à la maintenance, du moins de mon point de vue de débutant. C'est cet aspect qui me plait beaucoup. Bien sûr, je découvrirai peut-être plus tard une dure réalité ... Eh bien tant pis, on verra bien ...

Ok je vais étayer quelque peu mon propos.
Mais d'abord résumons la situation:
Tu as un projet à réaliser sur lequel tu vas être tout seul à travailler.
Tu as choisi un langage souple et permissif pour te permettre d'arriver "rapidement" à un résultat.
Tu as choisi de ne pas utiliser de framework PHP ( y'a pas de framework js à proprement parler, plutôt des toolkits).

Morale de l'histoire: tu vas faire ce truc comme tu as envie, comme tu le sens, à ta façon.
D'ou

Pas vraiment .
Tu choisis de n'utiliser que des choses que tu connais "un peu", niveau pédagogique c'est pas très interessant.
Tu peux à juste titre répondre: "Oui mais ça me permet de savoir où je mets les pieds".

Et bien je suis scéptique quand même car tes posts ne transpirent pas une profonde maitrise des différentes choses nécessaires à la mise en place de ce projet ( ce qui semblerait normal si tu sors de l'école. Ce n'est en aucun cas une critique).

Prenons ne serait-ce que l'aspect sécurité: de ce que je comprends tu dois faire une appli intranet dont une partie des fonctionnalités devra être accèssible de l'extérieur. Hors les contraintes qui vont s'appliquer à ces des parties vont être totalement différentes.

ça me parait compliqué ne serait-ce qu'à cause de PHP.
Je ne dis pas qu'il est impossible de faire du PHP propre, je dis juste que généralement les 1eres fois c'est dramatique.
Demandes à n'importe quel dev PHP quel avis il garde de sa 1ere appli, je suis sur qu'à 90% on te répondra: "C'était dégueu" ( les 10% restant étant pour ceux qui diront "ça n'a jamais marché, on a abandonné" ).

encore une fois ça va dépendre de toi et de la même façon, les 1eres fois sont rarement une réussite.
Néanmoins si, comme tu le dis, tu es à l'aise en C++ et java, cela te permettra vraisemblablement de faire de la POO sans trop de difficulté.

enfin ça c'est totalement n'importe quoi.
Ton appli, il ne va y avoir que toi pour la comprendre dans la mesure ou tu ne vas pas utiliser de framework normalisant ton dev.
Tu vas donc te faire tes trucs à toi qui te sembleront parfaitement clairs et vraisemblablement tu arriveras à le maintenir pendant ton séjour dans la boite ( sauf erreur de conception monstrueuse, ce qui n'est pas inenvisageable pour un 1er projet).
Maintenant si un autre dev est amené à travailler sur ton appli, ça va être complètement incompréhensible pour lui.
Sauf si biensur tu as pris le temps de rédiger/tenir à jour des docs techniques complètes sur ton appli...

Ouala
edit: je vais compléter en disant que ce genre de projet ou on prend un jeune sorti de l'école en esperant que tout se passe bien ça m'inspire autant confiance qui si j'allais me faire opérer de l'appendicite et que je tombais sur un étudiant de 3eme année en medecine qui me dise "c'est ma 1ere opération, mais vous inquiètez pas j'ai eu de très bons profs, pas besoin d'un chirurgien pour m'aider".

Si t'as le choix et que la boite t'en donne les moyens, laisse tomber le php et approfondis java/j2ee pour leur faire une appli intéressante, propre, modulaire et robuste au temps.
 
Sinon, tu veux le faire en php5 ou moins ?

you missed the whole point.
Je peux refaire exactement mon post si dessus en remplaçant php par java ou perl ou haskell.
 
Dans son cas précis ( une première expérience sans encadrement), le langage n'a plus d'importance que ça, c'est la façon dont il va s'en servir qui va poser des problèmes.

 
 
Je sais, mais il avait parlé de java au début et je développe moi même en java (proprement), ceci expliquant cela.
 
Sinon, j'ai posté sans voir ton post qui est un petit peu plus intéressant que le mien    
 
(oui, j'ai mis 1/2 heures à écrire 3 lignes )

.NET y'a que ça de vrai

Moi aussi, ça me semble mal partie au vu de ton manque d'expérience. C'est pas un reproche contre toi (on est tous passé par là) mais contre ton employeur qui cherche à faire des économies sans se rendre compte que ça risque de lui revenir deux fois plus cher au final (à cause des erreurs que tu feras vraisemblablement et que tu devras corriger parfois en modifiant d'autres trucs et ainsi que du temps que tu passeras à modéliser l'organisation des données et du module)
 
Si je résumes ce projet en terme purement technique, ça revient à passer de plusieurs logiciels type client lourd (exécutable sur le poste client) à un seul logiciel (type client lourd ou type intranet) + une partie déporté sur un serveur web.
 
Vu que j'ai pas mal d'expérience en programmation et que je connais plus de langage que toi, pour ce projet, je le ferais soit en java ou en C# (langage .net) si je veux fournir un client lourd en plus de l'extranet soit en java ou en php si je suis sur de ne pas avoir à faire plus qu'un intranet et un extranet. Le C# et le java permettent d'avoir une partie commune entre le code du site web et le code du client lourd. C'est pour ça que je choisirais l'un de ces deux là si je dois fournir un exécutable.  
 
A noter que php permet lui aussi de faire des applications graphiques et donc d'être utilisé en local mais je ne suis pas fan du tout de cette solution alors que c'est un des deux langages que je connais le mieux.
 
 
Pour l'utilisation du php pour un premier projet web (alors que c'est un gros projet relativement critique pour la société) , je n'ai qu'une chose à dire : hou la la la cata. Je m'explique, mon premier site web, c'était un chat en html+php. En dehors de la connexion que j'avais bien géré, le reste était faillé comme pas possible. Pour te dire dans la toute première version que j'ai mise en ligne, il suffisait de changer une valeur numérique dans la barre d'adresse pour aller sur les chats réservé à quelques personnes. En plus de ça, n'importe qui pouvait faire exécuter le javascript qu'il voulait sur le navigateur de ceux qui l'utilisait (heureusement, j'ai réalisé le problème quand on m'a posté un exemple bénin de javascript par le biès du chat) et les accès à la base de donnée n'était pas beaucoup plus sécurisé.
Quand j'y repense, j'avais vraiment fait de la grosse merde en barre. Au niveau du code php en lui même c'était à peine mieux. Si j'avais été embauché à l'époque pour faire du php, j'aurais surement connus des journée difficile. Après ça, j'ai fait d'autres versions mineures pour corriger les problèmes et améliorer l'ensemble. Puis, j'ai tenté une nouvelle version majeure que j'ai laissé tombé au bout de quelques mois sans l'avoir mise en ligne par ce que ça ne correspondait pas à ce que j'espérais (j'avais fait une grosse erreur de conception au niveau de la séparation de l'html et du php ce qui rendait le rendus trop dépendant du code php de chaque page).  
 
 
Enfin bon, c'est toi qui voit quel langage te semble le mieux. De toute manière quelque soit le langage que tu choisiras, un certain nombre de règles de sécurités ne changeront pas d'un iota et si tu veux faire un système évolutif, tu devras quand même passer autant de temps à modéliser le code et la base de donnée que tu utilises un langage ou un autre. D'ailleurs en passant oubli donc l'idée que tu puisses avoir à la fois quelque chose de "rapide à mettre en route" et d'évolutif. Ca sera soit l'un soit l'autre vu que soit tu pondras du code très vite sans avoir suffisamment réfléchis à l'ensemble, soit tu prendras le temps de bien penser les choses et il faudra du temps avant de pouvoir montrer quelque chose d'utilisable. Dis toi bien qu'il t'arrivera surement de passer plusieurs jours sur des éléments qui semblent simple au premier abord mais dont les implications pourraient être important quand on regarde de manière plus globale.
 
 
PS : Java dispose d'un système permettant d'exécuter des objets sur un serveur tout en le gérant comme un objet local au niveau du code (sauf pour la déclaration qui change)
C# et les autres langages .net permettent d'utiliser des objets géré et exécuté par une application serveur comme si c'était des objets local. D'ailleurs, c'est dans un fichier de configuration utilisé à la compilation qu'on indique quelles classes sont des classes locales et lesquelles sont géré par l'application serveur.
Il n'y a donc pas besoin que t'invente ton propre protocole de communication entre un client et un serveur avec ces langages là.
 
 
PS2 : Bonne chance dans ce gros chantier. Je te souhaite de le réussir sans trop de problème et sans que ton employeur ne rouspète trop.

Ou de faux. J'arrive toujours pas à voir la différence entre le couple de client/serveur que j'ai trouvé en exemple et qui marche et celui que j'ai pondus et qui marche pas. (je hais les langages où le comportement dépend en partie des fichiers de config)

 
Coin coin ?
C'est quoi cette histoire ? C'est qui ? C'est où ? Ca marche comment ? Pourquoi on m'a rien dit ? Ca sert à quoi au faite ?
 
Tu peux donner plus de détails ?

Hein ?
 
En fait je pige rien de ce que tu racontes

JE te pensais meilleur que ça en C#.
 
En gros, tu fais ton applis client comme si elle disposait de tous les objets en local tout en se connectant à une applis distante sans dialoguer avec elle. Puis dans le fichier de config utilisé à la compilation, tu indiques que telle et telle classe sont en fait situé dans une application serveur et non dans l'application locale (super logique pour le coup vu que l'applis locale à quand même besoin de la dll qui contient ces objets pour connaitre l'interface des dit objets)
Evidemment, ton applis locale doit s'être connecté au serveur sinon elle n'aura pas accès aux objets construits avec l'une de ces classes.
 
Là où ça devient super drôle c'est que si tu te plantes dans le fichier de config, l'applis locale utilisera les classes locales pour créer des objets en local plutôt que d'aller les chercher sur le serveur et tu peux passer des jours entiers à développer ton application sans te rendre compte qu'en fait ton serveur ne s'est même pas branché sur un port pour attendre les connections d'un client.
 
C'est pas cool le .net ?

C'est quoi ce truc de goret ?
 
Tu peux pas faire un webservice comme tout le monde ?

Sans serveur web, non pas vraiment. Et puis je voulais découvrir un nouveau langage, pas utiliser un langage à la mode comme du php.
 
EDIT : En fait, c'est surtout que je voulais faire une applis dont une version ne marche qu'en local et une autre en client/serveur sans m'embêter à devoir réécrire 25% de l'applis pour passer de l'une à l'autre.

Ben c'est exactement ce que font les Webservices
 
Dans un cas, tu références tes classes grace à une URL, et dans l'autre tu lies directement la DLL à ton application.
Tout le reste du code reste strictement identique

A par que dans un cas tu utilises les objet comme s'ils étaient là tandis que dans l'autre, t'es obligé de créer et analyser un flux de donnée et rajouté à celà une vérification de l'identité de celui qui appelle le webservice à chaque appel.
Mine de rien ça fait plus de différence qu'un simple "tu remplaces le 'new maclass' par 'open myURL' ".
Enfin bon, là n'est pas le sujet. N'allons pas perdre yannick_frere dans des considérations qui ne le concerne pas encore.

Point de vue "flux de données", t'as absolument rien à gérer. En .NET tous les types de base (y compris les DataSet par exemple) sont sérialisables, et le saut automatiquement. Que ce soit côté client ou côté serveur, t'as aucun souci à te poser, tu utilises les types natifs de .NET et tout fonctionne. La où ça peut se compliquer, c'est si tu veux retourner un objet ou une structure, là il faut effectivement mettre en place quelques traîtements supplémentaires, mais rien de bien sorcier.
 
Pour ce qui est de l'authentification, rien ne t'empêche de te connecter au web service en utilisant une connexion sécurisée (avec authentification HTTP + SLL si tu le désires). Au pire des cas, les WebService .NET pouvant travailler en session, tu peux parfaitement d'authentifier au moment de la construction de l'objet. Ensuite t'as plus besoin de quoi que ce soit, c'est ta session qui décide si t'as le droit d'interroger les méthodes ou non (donc une bête ligne à rajouter en début de chaque méthode :

if (this.authentificated == false) throw new Exception("DTC" );

vos gueules
C'est pas "SOS detresse amitié C#" ici, allez pourrir un autre post

Bonjour ! Merci à tous pour vos réponses ! En particulier à Anapajari pour son effort suite à ma petite remarque : j'apprécie vraiment !
Un instant, j'ai eu peur que la partie programmation de HFR soit définitivement interdite aux débutants ^^'

Alors pour éviter tout de suite un débat autour de .net, j'ai totalement écarté ce choix pour mon applic principale. J'ai la possibilité de me former convenablement à certaines technologies, j'aimerais un peu voir ailleurs que chez Microsoft de temps en temps. J'utilise cependant C# .Net pour les petites applications annexes et pour tous les "vrais" programmes que je devrai écrire (pour l'instant : extraction des données des bases existantes et injection dans mes bases à moi). Pas que je n'aime pas MS, mais j'aimerais varier les plaisirs et ne pas limiter mes connaissances à un outil précis.
De plus, comme le disait Omega2, je n'apprécie pas plus que ça les petits fichiers de configuration, voire même tous les petits fichiers qui peuvent se rajouter à mes projets. Et dans Visual Studio, il y en a pas mal ... Ok, il y a d'autres IDE que Visual Studio, mais j'aimerais pas me présenter dans une prochaine boite en expliquant que je fais du C# avec UltraEdit : je ne serai absolument pas en phase avec les équipes de développement, je pense.
Visual Studio me semble très intéressant à apprendre et j'aimerais le maitriser mieux, mais je ne peux pas en faire acheter un à l'entreprise d'une part. D'autre part, je crains que cela demande déjà pas mal de temps à maitriser l'interface du truc, comprendre le rôle de chaque petit fichier créé, c'est du temps que je ne pourrai pas consacrer à mon applic. J'aimerais apprendre tout cela plus à mon aise, à côté.

Au niveau de mes connaissances, j'ai déjà réalisé des projets en C++, Scheme, Java, C# (.net, asp.net), php, mis en pratique les Enterprise JavaBeans, Corba, j'ai de bonnes notions d'architecture logiciel (design patterns, UML, ...), et j'applique tant que faire se peut le schéma MVC à mes applications.
Bref, je ne me sens pas du tout sous-qualifié pour entreprendre un tel projet. Maintenant, les applics qu'on fait à l'école, c'est pas grave s'il y a un bug, ou si on n'a pas pu faire les 10 derniers pourcents à cause d'une erreur d'architecture au départ, les profs comprennent bien ... Mais là j'aimerais ne pas me tromper, comme je l'ai fait pour concevoir le site de l'entreprise : www.pmt.be : j'avais bien gentiment présenté tout le contenu en xml et fait la présentation en xsl (et CSS), mais impossible de faire accepter une minuscule partie de mon code sur les navigateurs IE et FireFox (ne parlons pas des autres donc ~~). J'ai dû tout recommencer en html pur et dur. Pas dur, mais bon, ça aurait pu être pire ...

Concernant mon employeur, il sait parfaitement tout ce que vous avez expliqué : il sait que son applic complète ne tournera pas avant 1 an grand minimum. Il sait aussi que le développement d'outils informatiques est nécessaire avant de voir la première applic sortir. J'ai donc le temps de faire mes outils et de faire quelque chose de bien ...
Il me paie très bien et je reste moins cher que la boite de consultants à laquelle il avait fait appel. Il n'est pas pressé : il veut juste une informatique qui marche (je maintiens donc le système actuel), une informatique qui marche mieux (pour l'avenir, donc) et surtout ne plus devoir s'en occuper !

Voici comment je compte m'y prendre pour réaliser mon projet. J'ai commencé comme ceci : j'ai une toute petite applic à faire (c'est pour moi, c'est pas demandé). J'ai fait l'inventaire des ordinateurs de l'entreprise et j'aimerais une petite applic qui m'indique qui dispose de quels ordis, qui me permet de savoir quels ordis peuvent bénéficier de la ram que je commande, etc ...
Donc, j'ai mis en place les idées que j'ai au sein d'un petit framework perso et je développe cette applic en même temps que le framework... Quand je constate qu'il me manque quelque chose dans le framework, j'ajoute. Ou je modifie quand je constate qu'il n'est pas pratique, que les différentes couches sont mal séparées ... Une fois que l'applic sera terminée avec mon framework, je regarderai du côté de la sécurité et j'apporterai les modifications nécessaires pour que le framework dispose d'une bonne sécurité. Une fois que je serai sûr que le framework est opérationnel, j'entammerai les premières applics et apporterai les modifications nécessaires si je constate des manques. Cependant, le risque d'une erreur monumentale de conception du framework devrait être relativement réduit, puisqu'il aura déjà été testé avec une applic complète ...

Pour leneufjuillet2006, c'est bien le php5 que j'avais choisi (pour les variables de type référence comme en Java).

Voila, j'espère avoir resitué un peu le contexte ...

Maintenant, j'ai une question qui me taraude ... Vous avez tous l'air de me conseiller des applics sous la forme de "vrais" programmes (avec la logique déportée sur un serveur d'application éventuellement, style J2EE ou Hibernate, si j'ai bien compris). Pourquoi ? Pour la sécurité ?
L'idée de mettre tout sur des pages web n'est pas bonne ? Ca me semble pourtant extrêmement pratique, non ? Il faut bien tenir compte d'une chose importante : tous les employés qui vont utiliser les applics ne sont pas vraiment formés à l'outil informatique. Il s'agit donc de faire du simple et de l'intuitif. Moins ils devront en faire au niveau de leurs applics (pour mettre à jour, etc), mieux ce sera !

Le site que j'ai fait pour la boite devra être recommencé. Je suis donc certain d'avoir du développement web à faire. Faire tout dans le même site web et avec les mêmes outils risque de me faire gagner du temps, non ?

Pourrait-on recentrer ma demande initiale dans un premier temps sur le choix applic web ou programme installé, svp ?

Dernière petite précision : mon appréhension à utiliser des frameworks trop complets pour une applic web. Mes raisons :
- les standards évoluent assez rapidement dans ce domaine et les navigateurs les interprêtent plus ou moins bien. Donc tout cela bouge et un framework est sensé pouvoir faire abstraction de tout cela à condition qu'il soit mis à jour. Or, beaucoup de frameworks php sont faits par une petite équipe bénévole qui peut arrêter ou se disloquer à n'importe quel moment ... C'est la raison pour laquelle je ne choisirai par exemple pas des outils comme EXT JS pourtant bien tentants (fait par une seule personne ...).
- j'avoue ne pas adorer tout ce qui est externe aux outils packagés avec un langage donné (les librairies standards Java, .net, etc ...). L'avenir me dira si j'ai tort ou non, mais je crains que, parfois, on passe plus de temps à apprendre comment utiliser un outil que d'en développer un petit bien spécifique à nos besoins (sans tout l'enrobage que l'on n'utilise pas) ...
- quand je parle du framework que je développe pour mon entreprise, il faut bien se dire que c'est petit ! C'est juste ce dont j'ai besoin pour accélérer mes développements. Je maintiens une doc pour tout ce que je fais. L'avantage est que l'entreprise ne restera jamais bloquée à cause d'un problème de maj : les sources sont petites et documentées : n'importe quel programmeur pourra reprendre le flambeau et corriger d'éventuelles incompatibilités directement dans le code source de mes outils.
- Au niveau sécurité : l'utilisation d'un framework complexe donne parfois l'envie de croire que parce que tout semble fonctionner comme on le souhaite, la sécurité est ok puisque gérée par le framework. Je peux me tromper, mais utiliser un framework de manière incorrecte risque également d'introduire des trous de sécurité. En travaillant directement avec les langages natifs (js, php), j'ai l'impression de mieux pouvoir gérer cet aspect des choses. Malheureusement, je ne suis pas un pro de la sécurité informatique, ça m'ennuie un peu.

Voila, désolé d'avoir fait un peu long : il y avait beaucoup à dire en réponse à vos messages également longs (et intéressants, je vous remercie encore ! )

 
Et ça nous mène où, tout ça?
 
Le fait est que tu n'as pas d'expérience (ou ne semble pas en avoir) et que la description du boulot semble demander pas mal de bouteille.
 
Tu sors de l'école et tu vas devoir jouer les analystes, architectes, DBA et développeur, ou qq chose comme ça. Tu vas sans doute apprendre plein de chose, ce qui est le bien, mais ton employeur doit avoir des tendances suicidaires (ça lui apprendra a être so cheap).
 
Je ne sais même pas si on peut valablement te conseiller, tellement c'est large et exprimé de manière générale. Rien que le choix client lourd / client léger ne peut se faire comme ça, sur base de ce qu'on lit ici.
 
"je ne me sens pas du tout sous-qualifié pour entreprendre un tel projet."
 
Ca contraste quelque peu avec le reste de ton discours et avec les questions que tu poses, AMHA. Si par "qualifié", tu te bases sur ton diplôme, tu t'exposes à des déceptions.
 
Enfin, je ne vois pas bien comment valablement t'aiguiller plus avant.

Ou des attentes qui ne correspondent pas à ce que tu imagines ... Laissez-le un peu tranquille, le topic n'est pas là pour parler de lui ...
 

S'il manque des informations, je peux les fournir. Je ne demande à personne de choisir à ma place. De simples retours d'expérience, style : "J'ai fait un projet intranet/internet pour une boite en php et ça avait foiré parce que ceci ou cela", ça serait déjà très bien ... Et plus particulièrement des retours sur l'utilisation de clients légers en entreprise, puisque je semble être le seul à préférer cette approche !
 

"Je ne me sens pas sous-qualifié" != "Je me sens qualifié". Il est évident que je fais ma première expérience avec un gros projet. Je pense connaître bon nombre des problèmes que je vais rencontrer, mais je ne connais pas toutes les réponses modernes à ces problèmes (frameworks, outils divers, ...) simplement parce qu'on ne voit pas ça à l'école ... Ces solutions étant trop nombreuses, je me suis tourné vers des gens d'expérience pour tenter de m'orienter plus rapidement.
Le fait que je sois venu ici semble montrer que je m'attends évidemment à des déceptions si je fonce tête baissée, je pense. Tout le monde me parle de clients lourds alors que j'envisageais plutôt des clients légers. Je me demande pourquoi ... la démarche est bonne, non ?
 

Merci quand même pour ton intervention =/

yannick_frere > On te propose de faire un client lourd principalement pour trois raisons :
1) avec un client lourd, tu maitrises l'ordre du déroulement des taches et le fonctionnement général. Avec un client légé, tu n'es jamais à l'abri d'un "page précédente" ou d'un changement de config dans le navigateur (javascript désactivé et c'est la panne assuré)
2) avec un client lourd, tu maitrises l'affichage. Avec un client légé, tu n'est jamais à l'abris d'une incompatibilité ou de l'interférence d'un skin. (par exemple, pour ce forum il existe une extension de firefox qui modifie la zone de saisie en changeant sa taille et en rajoutant des listes d'icônes)
3) tu dis qu'il faut faire simple par ce que les utilisateurs sont des utilisateurs basiques. Mais par expérience, il est beaucoup plus facile de faire comprendre à l'utilisateur qu'on ne peut pas faire marche arrière avec un client lourd qu'avec un navigateur. Un cas classique, c'est l'utilisateur qui se plante dans l'orthographe du nom du client. Avec un navigateur il aura tendance à faire "page précédente" puis à modifier le nom et recliquer sur "valider" ce qui va créer deux clients. Avec un client lourd : retour impossible mais bouton "modifier" à l'écran et il modifiera la fiche du client sans avoir à se poser des questions. En plus, il vaut mieux ne pas avoir de retour possible à la page précédente que de devoir vérifier que l'enchainement théorique a bien été respecté ce qui est quasiment impossible si la personne à plusieurs fenêtres ou onglets d'ouverts. (sur le forum t'as des exemples de discutions où certains se sont pris la tête pendant plusieurs jours avant de réussir à forcer des utilisateurs à enchainer les pages comme ils le voulaient)

Bonjour !
 
 
Merci pour ta réponse, Omega2
 
J'ai parfaitement compris ce que tu m'as dit et j'ai pas mal réfléchis là-dessus tout en continuant de me documenter ... Voici ce que je pense :
1) Je ne compte pas (plus) trop utiliser massivement Javascript ... Peut-être de temps en temps une petite vérification ou une tentative de mise à jour dans le style Ajax. Pas de mise en page avec des outils 100% basés là-dessus en tout cas. Ce sera juste pour agrémenter l'utilisation, sans plus. Je tâcherai que tout reste plus ou moins fonctionnel sans Javascript. En tout cas, il faut bien se dire que les utilisateurs ignorent ce qu'est Javascript et comment le désactiver ...
2) Oui. Encore une fois, je ne vois pas les utilisateurs aller jusque là. Et si on l'envisage, on doit aussi envisager qu'ils peuvent effacer certains fichiers importants dans le cas d'un client lourd. Il n'y a pas vraiment de solution, je pense ...
Aussi, je pars dans l'optique que le serveur doit rester maitre des données qui lui parviennent : il aura la charge de vérifier que chaque opération qu'on lui soumet est bien valide. Dès lors, je pense que le client léger reste acceptable.
3) Le point le plus important. J'y ai pas mal réfléchis et ... je peux me tromper, mais j'ai l'impression que c'est contournable, non ? Si une opération se visualise comme une séquence de pages sachant que l'opération vers la base de donnée ne s'exécute qu'au niveau de la dernière étape et si je stocke les informations recueillie dans chaque page dans l'objet de session lié à un client, je pense qu'un retour en arrière ne posera pas de problème. Revenir en arrière ne fera que modifier les valeurs dans mon objet de session et ce n'est que lorsqu'on arrivera à la dernière page que le serveur vérifiera si les données sont valides (ex : si un client n'existe pas déjà) et exécutera l'opération vers la base de donnée.
Je peux me tromper, ce sera à tester, mais je peux peut-être stocker une valeur particulière dans un cookie qui me permettrait de contrôler quelle page est ou n'est plus accessible après un accès BD particulier. A tester ... Mais site de ma banque traite très bien les retours en arrière, donc ça doit être possible
 
Voila ! Donc j'envisage toujours le client léger ... Côté serveur, je laisse le php et je vais probablement passer au Java avec :
- servlets pour les contrôleurs
- jsp pour les vues
- EJB pour la logique de l'applic et l'accès aux données
- https + achat d'un certificat pour la sécurité
 
Ainsi, comme tu me l'as très bien conseillé précédemment d'ailleurs, j'ai toujours bien des clients légers mais le développement de clients lourds reste possible dans le même langage et sans avoir à réécrire tout : je pourrai partager toute une partie du code entre les clients légers et les éventuels clients lourds.
De plus, le java est plus connu que php (je pense à mon successeur).
 
Donc niveau serveur, je pense avoir fait mon choix !
 
Au niveau client, par contre, les choses sont plus floues. J'aimerais bien me faciliter la vie en essayant de créer des composants réutilisables, organiser un traitement plus ou moins systématique des événements que l'utilisateur pourra déclencher sur la page, ce genre de choses, mais ça ne me parait pas bien facile ... Auriez-vous des solutions ? Pas vraiment un framework ou un toolkit, mais une manière de d'organiser pour faire les choses le plus proprement possible.

 
Je me permets de revenir sur cette partie. Par curiosité, comment ça se fait que ton site en xml/xsl n'a jamais pu fonctionner sur les 2 navigateurs les plus utilisés? Sur quel navigateur t'as développé avant de te rendre compte que ça marchait pas Mon site perso est tout en xml/xsl, j'ai pas de pb...
 
ps : j'ai regardé ton site www.pmt.be. J'aime bien le design, mais vu qu'a priori, t'auras à développer un bout d'appli web, tu ferais bien d'apprendre le xhtml et le css afin de te passer de la mise en page par tableaux (une technique datant d'au moins 1999 où le css était pas bien supporté par les navigateurs et pas très riche en fcts non plu!!!).

tu t'es pas planté dans le lien ?
parceque là c'est juste le webmail d'ovh  
 
ah non...
 
vire le "." après "be". chais pas pourquoi, sinon ça renvoie chez ovh

 
Moi, ça me renvoie malgré tout sur le bon site... Le ., c'est le parseur de mise en forme du forum qui merdouille. Une phrase, ça finit toujours par un point (même si le dernier "mot" est une url, na!)

une url qui est à mettre entre ""

Bon, je commence pas des aveux : je m'étais très rapidement formé à XSL. Juste les fonctions principales, ça suffisait. Le résultat était peut-être pas trop optimisé ni trop propre. Je ne sais pas.
Donc, je stockais le contenu xml de mes pages dans un fichier .xml dans lequel se trouvait une référence vers un fichier .xsl. Le navigateur recevait tout cela et appliquaient la transformation. Si je me souviens bien, voici ce qui se passait :
- la transformation sous IE était OK ;
- la transformation sous FireFox produisait exactement le même code html/css (vérifié à 100% sur un exemple très simple souffrant du même problème), mais mes images étaient mal alignées, comme entourées de marges horizontales ;
- le code html récupéré après transformation par l'un ou l'autre des navigateurs fonctionnait sans aucun problème sur les deux navigateurs.
 
J'en ai donc conclu que le problème provenait de la transofrmation xsl ou peut-être de la manière dont elle était opérée par le navigateur. J'ai tenté pas mal de trucs pour tenter de résoudre ça mais j'ai pas approfondi : j'étais en retard, j'ai converti tout en html. D'ailleurs, le code source du site n'est que le résultat d'une application à la main de mes règles de production xsl ...
 
Si ça t'intéresse, je dois avoir les sources quelque part encore ... Il est possible que ce soit une erreur de ma part.
 
En tout cas, j'avais adoré utiliser l'xml/xsl et si jamais il y a moyen d'organiser très proprement les événements JS, de réutiliser des composants complets, etc avec, je suis tout à fait prêt à investir du temps dans l'apprentissage correct du truc.
J'ai également vu que l'on pouvait définir nos propres tags en Java dans les JSP, cela pourrait être une alternative plus qu'intéressante.
 
A noter que je réalisais la transformation xsl du coté du navigateur et pas du côté du serveur comme certains outils le permettent.
 

Le livre sur le CSS est commandé Cependant, il n'est pas encore dit que je l'utiliserai pour la mise en page. L'âge de la technique que j'utilise, ça m'importe peu. Le fait est que la petite image d'introduction sur le site est centrée verticalement. En CSS, je ne suis pas parvenu à le faire. J'ai cherché la solution sur le web, mais la réponse ne s'est pas faite attendre : c'est un point très délicat en CSS apparemment. J'ai été voir des layouts en CSS2 sur AlsaCreation et les types expliquaient bien que CSS n'est pas encore parfaitement au point. C'est pas dans le principe ni dans l'idée, mais il semblerait que l'implémentation n'est pas encore parfaite. Tout le monde attend le CSS3, je suppose (et moi aussi !).
 
Je compte refaire quelques essais propres (avec un bon livre) avec CSS pour voir comment ça se comporte aujourd'hui et avec les nouveaux navigateurs, mais je ne refuserai pas d'utiliser une table de temps à autres pour éviter de se casser la tête sur des problèmes d'incompatibilité.
 
A vrai dire, la présentation et les langages à utiliser ne me posent pas vraiment problème ... Je cherche le moyen d'avoir un code côté navigateur bien ordonné, bien clair, intuitif, etc ...
J'y pense maintenant : la possibilité de définir de nouveaux tags dans des pages JSP me permettra peut-être de déclarer un composant (avec un nom, ses propriétés, etc) et puis le code Java sous-jacent se chargera d'inclure les bonnes fonctions JS dans un fichier, éventuellement de fournir un id unique, de paramètrer les méthodes JS pour qu'elles fonctionnent avec cet id, etc ... A voir ! (A voir si c'est une vraie aide aussi ~~)

 
Une transfo XSL ne fait pas de la mise en forme mais structure un doc xml en xhtml (ou autre format comme du pdf). T'as pas eu l'idée d'aller regarder du côté du css Ce genre de différence entre des navigateurs est notoirement connue pour être un pb de css...
 
Un bon bouquin sur css est celui de l'auteur du site alsacreations (Raphaël Goëtter). Et franchement, dire que c'est pas forcément ce coup-ci que tu vas utiliser le css pour la mise en forme de ton site, c'est   Effectivement, le css 2.1 n'est pas encore parfait (le centrage vertical est un pb récurent) mais de là à ne pas l'utiliser Perds pas de vue qu'un site bien structuré en html (d'un point de vue sémantique) et mis en forme par du css, ça fait économiser de la bande passante de manière non négligeable si ton site a une forte fréquentation!...

Bien sûr que j'ai regardé les css pour tenter de déterminer l'origine de mon problème. Si je me souviens bien, mon exemple très simplifié de ma page ne comportait pas du tout de css et le problème survenait quand même (donc, ça ne venait pas des css). Je ne sais pas d'où ce problème venait.
 
Sinon, j'ai un ami qui est fort impliqué dans les technologies web (il travaille chez Canon sur le développement de technologies liées à Xml et est membre du W3C via son équipe) et il continue d'utiliser les tables pour une partie de sa mise en page. Si ça ne marche pas, ou très mal, pourquoi l'utiliser ? Mon but n'est pas de respecter un principe mais bien de fournir un outil à une entreprise qui n'a rien à voir avec l'informatique ... J'ai bien compris l'intérêt des css et je les utiliserai au maximum. Mais si j'ai un problème et si j'apprends que personne arrive à le résoudre en css, bah je devrai trouver une autre solution.
 
Surtout que cela ne concerne qu'une couche de mon applic' : je peux la changer plus tard sans toucher au reste ...
 
 
Sinon personne pour partager sa manière d'ordonner et organiser les fichiers et le code des différents langages côté client ? Une façon de faire qui permet de réutiliser des composants, gérer proprement les interactions (événements, etc) entre les différents éléments d'une page ?

Pour ceux que ça intéresse et surtout pour les autres débutants qui pourraient se poser les mêmes questions : voici un ultime rebondissement ...
 
En fait, je suis passé à .Net et Asp.Net 2 en particulier. J'ai pu m'entrainer et lire beaucoup au cours de ces derniers mois et il s'avère que Asp.Net est exactement ce que je cherchais ! Combiné avec l'extension Ajax, on gère très facilement tous les événements de la page côté serveur, aucune logique au niveau du client, et on conserve une bonne réactivité sans rechargement systématique de toute la page ! Vraiment très bien ! Je regrette vraiment mon appréhension du début, ça m'a fait perdre du temps !
 
Après avoir bouquiné le CSS (je suis prêt à faire un design 100% CSS maintenant ) et lu un (gros >_< ) bouquin sur les composants ASP.Net et le fonctionnement de l'engin, je m'attaque finalement à SQL Server 2005 (dans son édition Express) et le T-SQL ... Mon but est de placer un maximum d'opérations dans des procédures stockées de manière à :
- mieux isoler les opérations sur les données de tout ce qui concerne les pages web ;
- faciliter la validation de cette partie de l'application ;
- optimiser la réutilisation des opérations.
 
Ca me semble être une bonne idée, qu'en pensez-vous ?