Yhann

, oui, et encore, que s'ils ont un firewall qui bloque tout... De toute façon, saisir un login + passe dans un cybercafé, c'est suicidaire... Aller, au boulot !

Comme dis plus haut, tu vas sur une page, tu t'authentifies (comme si tu accédais à un backoffice en ligne) et là, tu as un lien. Tu rappatrie l'exe sur ton poste. Il est déjà configuré avec les paramètres du serveur pour le FTP. L'exe ne nécessitant pas d'install, tu double-cliques et voilà. Une appli Director compressée (projecteur shockwave) n'excède pas 2 Mo ! Alors, qu'en dis-tu ? Maintenant, sur Linux, bein pas possible avec Director

Je pense que c'est surtout l'auteur de Génération-libre qui parle Ne le prends pas mal, mais jamais je n'ai eu un client qui m'a demandé ça. Je répète que je fais des petits sites, pas d'énormes projets non plus... 99.99 utilisent XP, le reste Mac... Attention, je n'ai rien contre Linux, et contre le libre Je parle juste d'une réalité du marché... Maintenant, j'avoue que Director (c'est lui que j'utilise) ne permet pas de créer une appli sous Linux. A moins que pour la version 11 à venir en 2007, ont ait une excellent surprise ! A++

Salut, Peut-être, peut-être pas. On parle de plus en plus de clients riches. Les clients riches proposent des interfaces performantes et ergonomiques, qui ne sont pas réalisables en 100% line. On essaye plutôt de déporter sur les ordinateurs locaux une part importante des ressources. Si j'en reviens à mon backoffice, il ne s'agit que d'un exe qui travaille bien en ligne, puisque connecté au web. Et je vous assure que l'utilisation d'une telle application ne donne pas envie de se tapper un backoffice html dans un navigateur. Je crois que je vais me lancer Pour moi, le plus pénible, c'est de fournir un client ftp et de former la personne dessus. J'utilise ça pour l'upload de fichiers supérieurs à 2 Mo. Autant directement fournir l'application qui fera tout ça. Autre exemple, je propose un petit soft de traitement par lot pour le redimensionnement des images. Utiliser la bibliothèque GD de php, c'est bien pour un besoin ponctuel. Si la personne à 100 photos à publier, comment il fait ? C'est tout l'avantage d'une appli locale, qui en quelques clics de souris, permet à un néophite de mettre à jour ces pages le plus simplement du monde, et avec un confort appréciable.

Sympa la participation ! Quelques explications supplémentaires sont nécessaires... L'application, elle, serait effectivement connecté au web en permanence, mais elle tourne en local, et non sur un serveur distant. Cela dit, j'avais fais un truc avec Access, qui comportait une base identique à celle présente en ligne sur MySQL. J'avais ensuite développer un bout de code permettant de générer un fichier sql depuis la base access, pour mettre à jour la base MySQL distante. Cette solution permet le travail hors-ligne, mais n'est pas très adapté à une utilisation multi-users. Tout à fait, j'avais étudié cette solution, qui permet de diffuser facilement une application. Le tout étant de trouver un petit serveur web sans installation, sécurisé, transparant et paramétrable. Je l'ai trouvé, c'est ZazouMiniWebServer. Un truc formudable. Cela permet également de faire du ftp depuis un poste local vers un site distant. C'est moins évident qu'une appli en ligne, c'est sûr. Mais développer de façon modulaire, cela peut être relativement simple. Comme un anti-virus en mise à jour automatique, elle peut vérifier périodiquement si une mise à jour existe, et lé télécharger. Les exe que je peux produire ne nécessite aucune installation. On double-clique, et c'est tout. Ce qui faciluite grandement les mises à jour ! Non, parce que mes besoins sont modestes. Je fais toujours un peu les mêmes sites (des éditos, une rubrique d'actus, galerie d'images, sondages, etc..)

Bonjour, Depuis toujours, je développe mes sites dynamiques avec un backoffice en ligne permettant la mise à jour de certains contenus. J'utilise php/MySQL. Souhaitant proposer une plus value à mes clients, je me penche sur la réalisation d'une interface off-line, sous la forme d'un programme exécutable. Il ne s'agit pas d'un projet qui me vient à l'instant, mais qui a été très réfléchi. Seul le temps me manquait pour me lancer dans une telle réalisation. Si je vous en parle, c'est parce que je n'arrive pas à me décider vraiment sur le choix de me lancer dans un backoffice off-line ou si j'améliore l'existant on-line que je propose actuellmeent. Vous trouverez ci-dessous mon état de réflexion à ce sujet, et j'aurais bien aimé que vous me donniez votre avis, vos expériences, etc. Le tout étant, pour moi, de faciliter ma prise de décision. Je précise que je ne fais pas entrer en ligne de compte l'apprentissage d'un langage de programmation permettant la création d'un éxécutable, puisque j'en maîtrise un, qui me permettrait de générer une application pouvant fonctionner et sur PC, et sur MAC. Avantages d'un backoffice off-line - Plus agréable à utiliser (pas de chargements superflus, réagit mieux aux événement souris que des liens web dans un navigateur) - Traitements locaux (gain de temps et de performance énorme. Exemple, recadrer des photos, y appliquer un masque... Très rapide, ne mobilise pas les ressources d'un serveur distant, pas de risque de timeOut, traitements par lots possibles, etc) - Fonctionnalités sans équivalent possible on-line (intégration dans le soft d'un client FTP, permettant l'upload de gros fichiers, idem pour l'Upload) Oui mais... Si la personne utilisant le backoffice est nomade, et doit pouvoir utiliser différents ordinateurs ? Dans mon cas, 99% des clients mettent à jour leur site depuis un même ordinateur. Pour les 1% restants, c'est pas grave. Je peux mettre en place une interface en ligne, donc accessible depuis n'importe quel ordinateur, et sur laquelle on peut télécharger le backoffice (il fera moins de 5Mo). Par contre, c'est vrai que chez certains, il faudra configurer le firewall pour autoriser l'application à se connecter. Un backofice off-line permet d'être beaucoup plus productif. C'est nettement plus rapide que l'emploi d'une interface en ligne via un navigateur. C'est beaucoup plus agréable à utiliser. Cela permet d'automatiser certaines actions (alimentation d'une galerie photo, etc...). Ajax permet de tendre vers ce type d'interface, en terme d'ergonomie et de confort d'utilisation. Mais ça reste bien en dessous. Je vous laisse la parole

Salut, J'ajouterais léger (en terme de ressource), très facilement personnalisable (via css), rapide, et j'en oublie sûrement Yhann.

Salut, le fantome, Je ne suis pas sûr que tu trouves quelques chose de plus pratique... Fréquemment, sur les backoffices, les gens collent un contenu créé dans Word. Ce dernier génère des caractères typographiques non valides en xhtml strict. Tout le problème est là. A moins d'empêcher une telle manipulation, c'est difficilement contournable. Il te faut donc créer une fonction qui remplace les caractères non conformes en caractères compatibles avec les exigences de l'xhtml strict. Pour ce faire, tu as 2 solutions : - enregistrer dans la BDD les caractères originaux (et pouvant êtres non conformes) et appeler une fonction qui sera chargée de les remplacer, lors de l'affichage des données. - appeler la fonction de remplacement de caractères avant l'enregistrement dans la BDD. Je t'ai donné quelques caractères à remplacer. Pour faire bien, il faudrait tenir compte de l'ensemble des caractères énumérés sur le site d'OpenWeb, dont je t'ai indiqué le lien. A ce jour, je ne vois pas d'autres solution. S'il faut contrôler la saisie des rédacteurs, il faut malheureusement en passer par là. Une autre solution serait d'utiliser des formulaires en Flash (je vais faire bondir les intégristes de l'accessibilité). Je travaille actuellement sur un petit éditeur Fash, qui permet de styler du texte. Si l'utilisateur ne dispose pas de Flash, c'est un simple textarea qui s'affiche. Mais c'est destiné à un backoffice, et il est donc acceptable de conseiller une configuration minimale, contrairement au frontend. L'emploi d'un tel champ Flash est, de mon point de vue, bien plus fiable et ergonomique que tous les htmlArea ou autres FCKeditor... Mais ce n'est qu'un point de vue subjectif... A+ Yhann.

Salut, Tout est très bien expliqué sur cette page du stie d'openWeb. Il suffit ensuite d'utiliser la fonction str_replace() de php pour procéder au remplacement des apostrophes. Cependant, il peut y avoir des problèmes avec d'autres caractères, comme les guillemets, ... Il ne faut donc pas oublier de les traiter également. Pas sûr, mais pour les guillemets , on trouve souvent des : chr(132), chr(139), chr(155), chr(147), chr(148) Que l'on peut remplacer par des char(34) Pour les apostrophes : chr(145), chr(146) à remplacer par chr(39) Il y a aussi les tirets, les points de suspensions... A+ Yhann.

Salut, Oui, sauf dans les cas où la gestion d'index et l'emploi de jointure est inutile... Je ne parle pas d'une galerie de 100 000 photos, mais d'une galerie devant évoluer vers un nombre de la sorte. Franchement, tu n'es même pas obligé de le dire à ton patron ! Récupérer un array et remplir des tables, c'est quand même pas long ! On est bien d'accord, et c'est exactement ce que je disais. Là où je ne suis pas d'accord avec les "pro-bdd", c'est lorsqu'ils veulent utiliser une BDD sans même se demander pourquoi. Quand l'emploi d'une solution procure un avantage, pas de problème. Dans les exemples que je cite, l'emploi d'une BDD ne procure aucun avantage, c'est tout le contraire. Pour beaucoup, l'emploi d'une BDD n'est pas réfléchit, ou justifié par le côté technique "ouais, j'utilise une BDD...." Mais comme je l'ai expliqué, c'est bien la démocratisation de MySQL et la facilité de prise en charge via php qui on engendrés un tel phénomène. Pourtant, les fichiers textes ont leurs avantages (je ne reviens pas dessus, c'est expliqué plus haut) et ceux-ci ont été injustement délaissés, souvent au sacrifice de la performance, ce qui est un comble ! Beaucoup de jeunes développeurs ne voit la gestion de données que par une BDD, alors qu'il faut savoir mesurer l'utilité réelle d'une telle solution, qui n'est pas adaptées à toutes les problématiques. C'est bien ce que je disais aussi. A+ Yhann.

Bonjour à toutes et tous. Il s'agit de mon premier post : je suis tombé sur ce sujet par hasard, et n'ai pas résisté à l'envie de doner mon avis. Ce dernier vaut ce qu'il vaut, mais s'appuit maintenant sur 10 années d'expériences en développement multimédia, dont le web avec PHP. Pour moi, une base de données n'est absolument pas toujours nécessaires, et comme il l'a été dit, sur les hébergement mutualisés, c'est bien les accès MySQl qui sont responsables des lenteurs ressenties lors de la consultation d'un site, sans parler des cas extrêmes, où le serveur MySQL "tombe". L'emploi d'une base de données est justifiée dans les cas que vous citez, et notamment : - quantité impoprtante de données à pouvoir traiter selon différents paramètres - évolutivité - nécessité de gérer les accès concurents Mais l'emploi d'une base de données ne dispense pas de placer en cache (dans des fichiers textes) les pages à afficher. C'est rarement pratiqué, et pourtant, je vous assure que le gain est énorme. Mais bon, ce n'est pas le sujet et les sceptiques trouveront de nombreux benchs sur internet pour s'en persuader. Je tenais à décrire des exemples simples, qui ne devrait pas employer une BDD. Sites modestes, avec un backoffice mono-utilisateur. Sur un site dont l'arborescence est statique, vous placez un édito sur la page d'accueil. Beaucoup emploie MySQL pour cela, alors qu'un fichier texte sera bien plus performant (page s'affichant bien plus vite). La fréquence des mises à jour est faible (moins de 1 fois par jour). Autre exemple, une galerie d'images, avec photos légendées. galerie simple, quelques rubriques à gérer... Dans php, vous utilisez un array tout simple, avec le nom de la rubrique, le fichier et sa légende. Eventuellement un array par rubrique. Vous sérialisez l'array dans un fichier texte. Vous récupérer directement cet array lors de l'affichage. Quel gain de temps, et de ressources. Vous pouvez toujours affirmer que le traitement php est lent, je vous assure, encore une fois, que rien n'est plus lent qu'un accès à MySQL sur un hébergement mutualisé. C'est vraiment le maillon faible. On ne parle pas içi d'espaces disque, mais bien de ressources. Dans l'exemple ci-dessus, j'utiliserai une BDD si je dois gérer des centaines de photos, et pouvoir effectuer des recherches sur leur légendes. Dans les autres cas, jamais je n'employerai une BDD. Attention, cela est valable pour des besoins modestes, avec une évolutivité limitée. Maintenant, si du jour au lendemain, je dois gérer 100000 photos, ce n'est aucunement un soucis. D'une part, cela aurait sûrement été plus ou moins prévu, et dans ce cas, j'aurais utilisé dès le départ une BDD (avec l'emploi de caches, toujours), et d'autre part, quoi de plus simple que de récupérer son array et de remplir une BDD. On ne peut pas dire que dans un tel cas, le passage des fichiers textes à une BDD soit si handicapant que cela, pour peu que l'on maîtrise la programmation et que l'on sache faire des "moulinettes". Si je devais résumer, je dirai que les BDD ont été faites à l'origine pour traiter des besoins spécifiques. Mais la démocratisation de MySQL chez les hébergeurs ont fait que tout le monde utilise une BDD, sans forcément se demander pourquoi. Beaucoup ne connaissent d'ailleurs pas les fonctions php permettant la lecture/écriture de fichiers textes, alors qu'ils savent insérer des données dans une table ! Je rapelle aussi que sqLite est une BDD pouvant être utilisée avec PHP5, et que sur des applications "moyennes", elle se révèle plus rapide que MySQL. Et oui, elle utilise des fichiers plats... A+ Yhann