Loupilo

Hé oui David, TextPattern c'est bien Tu dis que tu « restes convaincu que le potentiel est du côté d'application nouvelles, ne serait-ce que parceque les choix effectués au départ sont plus en adéquation avec les exigences du web actuels ». Dans l'absolu, c'est pas faux. Mais quand tu appliques cette phrase à Spip, je ne suis plus d'accord. J'ai eu l'occasion de retravailler avec lui ces derniers temps, et j'avais oublié combien c'était agréable. Peut-être Spip est plus ancien, mais au moins, il dipose d'une vraie syntaxe ultra-performante. Elle a ses défauts, elle n'est paraît-il pas assez extensible, mais à le mérite d'exister et de fonctionner du tonnerre. Et il y a un fossé entre le système de ModX et celui-ci... Entre eux, il y a TextPattern. Celui-ci gère autrement, mais très bien également, les gabarits. Ceci dit, je préfère finalement Spip Tant que ModX n'aura pas saisi que la séparation du contenu et de la présentation c'est bien, mais que la séparation des squelettes et du PHP c'est mieux, il ne sera pas encore assez mûr pour moi. Proposer une flexibilité totale en nous permettant de traiter directement les données renvoyées par PHP, c'est un bon concept, mais et ceux qui ne veulent pas toucher au code méchant ? Les <BOUCLE> ne nécessitent aucune connaissance informatique particulière, seul un certain sens de la logique et un peu de concentration pour comprendre le mode d'emploi SPIP, c'est le bonheur pour réaliser des sites. ModX progresse, c'est bien, mais c'est justement la différence de philosophie qui me gène. Une syntaxe de type <BOUCLE> me paraît essentielle, et j'ai du mal à comprendre le "choix de départ". Le progrès, ce n'est pas nous simplifier la tâche ? Nous obliger à manier du PHP, est-ce ça, la simplification ? Je signale aussi que Spip 1.9 sera une petite révolution. Outre l'apparition des extensions pouvant tout faire, signalons une refonte du code qui permettra à terme de modifier presque entièrement l'administration sans toucher au noyau du logiciel. Les BOUCLE seront encore améliorées, le système de squelette refondé (plus de page.php3 ni page.html), ce qui permettra à terme d'intégrer nativement de bien jolies URLs. Bien sûr je garde un oeil sur ModX, mais visiblement il ne prend pas la voie d'une véritable syntaxe (si je suis le seul à la demander, je comprend ), et c'est tout de suite à mes yeux éliminateur. Pas envie de m'embêter à manier du PHP quand je fais des gabarits !

Moins de liens ? C'est changeable. La molette qui ne marche pas ? Tu buggues ! Et pour les liens... surprise, Ô surprise, ils sont dispos ! Regarde http://search.live.com/#q=sebastien%20billard&offset=9 : tu es expédié au 9è résultat sur la requête de ton nom... Plutôt fonctionnel ! Après l'avoir retourné dans tous les sens, j'ai fait un billet sur live search, et les défauts principaux que je relève, c'est surtout la lenteur et quelques limitations inhérentes au système... mais en général je trouve ça très réussi (notamment le coup des URLs qui m'a bluffé ) !

Au contraire, je trouve l'idée excellente(issime). Tout regrouper sur une page et télécharger les résultats au fur et à mesure, vraiment, très innovant et pratique. Plus besoin d'attendre un quelconque chargement ou de changer de page (même si avec 100 résultats par page sur google, c'est déjà bien). Là où ça plante, c'est dans la réalisation : ce n'est pas du tout fluide et ça n'est pas au niveau d'un vrai défilement. Dommage !

Fais un effort. Si tu veux ton site servi sur un plateau et fonctionnel en un claquement de doigt, demande à un pro de te le faire. Si tu veux te débrouiller seul, mets-y un minimum de bonne volonté. L'adresse de ton serveur MySQL t'a été fournie par ton hébergeur, il suffit de lire le mail ou le courrier qu'ils t'ont envoyé. Tu peux te renseigner un peu avant de demander ce genre de choses...

Comment ça, tu n'arrives pas ? Qu'est ce qui se passe ? Un message d'erreur ? Lequel ? Loupilo

Personnellement, je n'ai aucune expérience dans le domaine, mais j'ai pû voir pas mal de "blogs vidéos" reprenant le principe. En général, c'est un lecteur vidéo en Flash qui s'occupe d'afficher la vidéo. C'est une bonne solution car 95% des ordinateurs avec internet ont le logiciel de macromedia... mais pour le format, il faut convertir ta vidéo dans le format vidéo spécial de Flash (.flv), seul lisible. Par contre, je ne sais pas si le moteur de ces blogs est spécialisé dans les vidéos et si ce n'est pas un simple dotclear avec le plugin dcVideoPlayer ou plus artisanalement en utilisant le Flash Video Player mais qui ne bénéficie pas d'interaction avec le logiciel de blog. A noter que le plugin a un atout : il convertit tes vidéos AVI, MPEG, Quicktime, WMV dans le format de Flash Loupilo.

Je ne suis pas sûr, mais que vient faire un point-virgule ( avant l'accolade qui suit le if ?

Déçu ? As-tu vu la vidéo "création d'un blog en 15 minutes", en partant de zéro ? Ça m'étonnerait beaucoup que tu puisses en faire autant, quelque soit le langage que tu utilises. Tes classes, il faut les écrire... Ce qu'il fait mieux que les autres, c'est la vitesse de production

Note que le gimp t'ouvrira les fichiers psd ! Seulement l'importation ne se passe pas toujours très bien et il peut y avoir quelques ratés Loupilo.

Après avoir demandé, «1 an et quelques jours»

Effectivement le Gimp permet tout à fait de créer des gif animés. Un tutoriel pour faire une guirlande animée (retiens juste le principe, c'est très simple) : http://eric.lamarque.free.fr/index.php?ima.../guirlande.html

J'ai eu l'occasion de discuter un peu avec eux à l'occasion de la sortie de leur offre Rails et en plus d'être très sympas, ils ont l'air vraiment très réactifs et leurs services sont, à ce que j'ai pû en voir, excellents. Je n'ai pû n'en entendre que du bien...

Dur d'expliquer ma pensée. En PHP, pour te connecter à la BDD, tu t'y connectes. Pour récupérer les données, tu les récupères. C'est galère à faire, mais tu le fais. En Ruby, tu ne t'en charges pas. En PHP quand tu fais des liens vers une autre partie de l'application, tu fais des liens en mettant en lien l'adresse de l'autre page. RoR te génère tes liens. On a en apparence moins de contrôle (mais on peut se débarasser de la couveuse si on veut tout faire comme un grand), et c'est plus abstrait. En PHP tu as tes variables et ton code dans ton fichier. Avec RoR, c'est réparti dans plusieurs fichiers, en fonction de ce que fait ton morceau de code et sur quoi il agît. La vidéo du blog en 15mn est réellement impressionnante. Mais pour faire ça, il faut avoir compris comment ça marche en profondeur... Refais le tuto avec la vidéo et tu verras qu'au début on a non-seulement du mal à comprendre, mais aussi du mal à discerner la logique de l'ensemble. L'avantage de la VF, c'est qu'elle a été mise à jour pour Ruby on Rails v1.0 alors que la VO a été écrite avec la version 0.13. C'est aussi qu'on bénéficie de 50% de réduction sur l'offre rails de typhon. Et qu'on peut télécharger tous les codes sources sur le site d'Eyrolles. Faut voir si la différence de prix est flagrante ! Et merci encore pour tes compliments

Mon billet était plutôt dans la période "j'y comprend rien" En fait le problème, c'est que quand on n'a jamais fait de programmation, comme moi, certains concepts en Ruby paraissent très abstraits. C'est dur de suivre au début car il faut intégrer comment marche le langage. Si tu as acquis les bases de Ruby, ça passe déjà bien mieux. Mais comprendre ce qu'est qu'une classe, un objet, une méthode, quand tu sais pas ce qu'est qu'un langage orienté objet, c'est très sportif. Une fois que c'est (à peu près ) rentré, tout passe déjà beaucoup mieux et le bouquin se lit enfin agréablement. PHP est plus simple dans la mesure ou rien n'est abstrait, tout est concrêt. Là, je fais ça dans ce fichier, et ça dans celui-ci, etc. RoR est beaucoup plus structuré et donc déroutant. Mais c'est tout bénèf' : bonjour la puissance dont on s'aperçoit en suivant le pas-à-pas ! C'est un très bon livre (enfin j'ai pas fini...) si on ne se limite pas à la première impression. Et la traduction est admirable. Loupilo (merci pour l'"excellent design" )

Il faudra bien detroner PHP qui a plein de lacunes... RoR arrive à point. Tout est d'une grande simplicité. Pas besoin de réinventer la roue à chaque applicatiion. En codant avec Ruby on Rails, on code un script mais pas son environnement. C'est au langage de se charger de ce dernier. Au langage de se connecter à la BDD, à préparer les résultats à être exploités. Et puis une autre différence fondamentale entre RoR et PHP, c'est que le premier s'occupe de tout, de la vue html également. Tu es accompagné pendant le développement de l'application, pas seulement lors du développement du moteur (quoiqu'en PHP, tu n'es même pas accompagné). La devise de Rails : ne vous répétez pas. En PHP, ça veut rien dire, ça

Bonne nouvelle David Pour ma part, j'ai acheté le superbe bouquin Ruby on Rails... C'est que du bon. Rails vaincra !

Bonsoir à tous, Cette fois j'ai la primeur sur David... Plume CMS 1.1 est sorti ! Au menu des nouveautés : PHP5, les commentaires, amélioration en profondeur du noyau et d'autres encore. Et surtout, cette version sonne le retour en force du SGC, qui revient sur le devant de la scène grâce au retour de son développeur principal. Pour ceux qui ne connaissaient pas : Plume est un CMS qui reprend l'interface de Dotclear (interface de dotclear 1.2 disponible, d'ailleurs) tout en étant assez différent puisque c'est un CMS. Système de cache avancé, rubriques imbriquées à l'infini, brèves et articles, un gabarit possible par catégorie/brève/article, multi-(rédacteurs|sites), très léger, il est vraiment puissant et ses patrons fonctionnent en PHP, vous ne serez pas déboussolés (comme Dotclear). La version 1.2 est effectivement prévue pour bientôt et c'est elle qui sera officiellement stable. Car cette mouture est une version encore étiquetée TEST, bien que complètement opérationelle... Il faut traquer les bugs, perfectionner la prochaine mouture À vos plumes ! Loupilo.

Pas besoin de chercher loin, ni même aller sur un autre site (certainement pas concurrent, d'où sort cette annerie ?), tout est sur le Hub Vent40 Va voir dans les publications du Hub, il y a deux articles très intéressants qui t'aideront à faire ce que tu veux. Et voici à peu près ce que tu veux faire (la syntaxe n'est pas exacte) : RedirectPermanent ^(.*).html$ http://www.domaine.tld/$1.php Quand on essaiera d'accéder à page.html, on sera redirigé vers page.php...

Effectivement, la 1 a été mise en ligne juste après mon message Bon l'essentiel c'est que ça marche (et en français en plus !)

WebDeveloper 0.9.4 en français. Je ne comprends pas d'où peut venir ton problème

Justement bigornot, ça désigne cette interaction, qui n'est pas vraiment du vent... Mais je te l'accorde, ce n'est qu'une appelation un peu pompeuse pour faire du neuf avec du vieux, le vrai nom de l'Ajax, c'est XMLHttpRequest.

Si tu réinstalles FF, rien de tes options perso ne sera supprimé C'est pour ça que c'est inutile de faire cette manip. Et bêtement, si tu désinstalles WebDeveloper, ça donne quoi ?

Déjà, passe à Firefox 1.5 en le téléchargeant sur mozilla-europe.org. Si tu as malgré tout toujours ce problème, sauvegarde ton profil d'abord puis supprime les dossiers cache/, extensions/ (tu devras réinstaller tes extensions, étape facultative), chrome/ et tous les fichiers se trouvant dans le profil ; exceptés bookmarks.html, signons.txt, cookies.txt. Ça devrait être bon... Si non, alors supprime carrement tout ton profil et remet juste les fichiers utiles qui sont dans ta sauvegarde (bookmarks.html, éventuellement signons.txt). Là, obligé que ça marche

Salut, Effectivement, la maquette actuelle me choque et suffirait à me décourager. Car ce travail n'est comme tu le dis pas pro, et mon esprit farfelu irait penser que tu ne peux te payer un graphiste, ce qui me refroidirait instantanément Le choix des couleurs, les espèces d'icônes en haut, il y a effectivement des choses à revoir... Bon courage Loupilo.

Ça vient de toi, car dotclear.net et son forum fonctionnent très bien Loupilo.