>Tout ça pour d'éventuels contributeurs anglais qui n'existent pas à ce jour.
C'est sûr que tu n'a pas de contributeurs anglais (et tu auras peu de chances d'en avoir), vu que c'est en français. C'est un peu comme faire un site qui a un script qui check le navigateur et n'accepte que IE, et dire ensuite que ce n'est pas la peine de faire un site compatible avec les autres navigateurs vu que dans les stats, ils sont totalement insignifiants. (c'est du vecu :-) )
Ensuite, en parlant de "contributeurs anglais": Le monde est vaste, les contributeurs peuvent venir de tout pays, pas seulement des états unis ou Angleterre. Et l'anglais est probablement la langue la plus "universelle" (surtout en informatique). Donc c'est pas seulement des contributeurs "anglais" que tu pourrais avoir ;-)
Bonne continuation dans ce projet tout de même :-)
ouai bon, on peut appeler XUL un langage, mais pour moi ce n'est pas un langage au sens que l'on entend en parlant de python, C ou autre. Ce n'est pas avec XUL que tu va pouvoir implémenter le moindre algorithme. C'est pour ça que pour moi, le XUL est plus un format qu'un langage (même si y a "langage" dans le nom)
Bref, la comparaison entre Python et XUL n'a pas lieu d'être.
>qu'est-ce-qui te ferait préférer XML-based_User_interface_Language au hasard ?
Euh, c'est quoi le rapport avec un langage de programmation comme python ? Le XUL n'est qu'un format descriptif d'une interface utilisateur. Tu compares dont un format avec un langage. Très fort :-)
C'est certainement pas avec ça que je vais développer le moteur de rendu d'un browser (j'ai bien dit : moteur de rendu). à coup sûr, si je n'avais qu'à choisir entre XUL et python, je choisirais bien évidement python pour un projet comme ça, parce qu'avec XUL, je ne vais pas aller loin...
> certainement pas le fait que c'est interprété,
"interpreter" un fichier XML, c'est pas pertinent... Surtout que dans Gecko, le XUL n'est pas interprété, mais analysé et ensuite on travaille avec un DOM...
>qu'il n'y a pas d'éditeur dédié,
y a des plugins pour eclipse, y a Komodo...
> ni de tests unitaires normalisés,
Je ne vois pas ce que tu appelles "normalisés", mais il existe des outils pour faire des tests unitaires dans Mozilla.
>ni de compilation pour la vérification des types
hors sujet vis à vis de XUL
> encore d'équivalent de valgrind pour les fuites mémoires ?
Valgrind est utilisé dans le developpement de Gecko (même si il n'y a toujours aucun rapport avec XUL).
>parce que c'est la meilleure façon de produire agréablement des logiciels maintenables de qualité, et vous ?
Ouaouuu... Rien que ça. C'est totalement subjectif ça. C'est peut être la meilleur façon pour TOI. Mais sûrement pas pour tout le monde. Chacun a ses préférences, ses goûts en matière de langage. Personnellement, ce n'est certainement pas avec Python que je vais produire des logiciels maintenables et de qualité. Tout simplement parce que je n'aime pas trop Python. Et ça veut pas dire qu'avec un autre langage, je ne vais pas produire des logiciels maintenables et de qualité.
Et puis, en dehors des gouts et des couleurs, il y a aussi le fait que chaque langage a ses spécificités, qui lui permet d'être plus efficace que d'autres pour la réalisation d'un type de logiciel particulier. Ce n'est par exemple certainement pas avec Python que je vais m'amuser à faire le moteur de rendu d'un browser HTML...
>Mozilla décide à la place des utilisateurs ce qui est bon pour eux, et pour cela utilise exclusivement les services de Google. Ce qui donne à Google un contrôle sur le web. La preuve hier.
C'est pas du tout exclusif. Faut arreter la parano.
Pour le moteur de recherche, je te rappel que tu as le choix. Firefox est livré avec un certain nombre de moteur de recherche, et tu peux les supprimer, en installer d'autres. bref. Aucune exclusivité si ce n'est que Mozilla met en avant Google parce qu'ils ont un plus gros contrat avec eux qu'avec les autres (et que la cantine google est à deux pas et est très bonne :-))
Pour le service anti "sites pourris", c'est totalement paramètrable : about:config -> browser.safebrowsing.
Il t'embete ? tu le désactives (à partir de la boite des préférences ou dans le about:config). Tu veux en choisir un autre, tu renseignes les bons paramètres dans le about:config. Et si ça se trouve, il y a des extensions qui te permettent de configurer facilement vers d'autres fournisseurs.
Quant à ta liste de "Mozilla aurait pu", c'est facile à dire, il y en a qui ont refait le monde avec des "si". Et si pour chaque fonctionnalité qu'il y a dans Firefox, il fallait proposer un choix à l'installation, je doute que Firefox aurait eu le succés qu'il a. Et à mon avis, proposer le choix d'activer au premier démarrage n'aurait servi à rien, car pour 90% des gens, ils ne sauraient pas quoi répondre et activerait sans se poser de question (surtout si on leur dit que ça rend la navigation plus sûre).
>Le jour ou Mozilla voudra dire merde à google, google pourra envoyer des listes gonflées aux navigateurs utilisant ce service (majoritairement mozilla) pour planter la réputation de la fondation.
Mouai bof. Mozilla push une nouvelle version mineure de Firefox, avec des nouveaux paramètres de confs, et la majorité des installations n'utiliseront plus le service de Google. Et très franchement, je doute que Google fasse se genre de bêtise, sous peine de se prendre un procés aux fesses et une très mauvaise image (et contredire leur moto, "don't be evil").
Mozilla ne s'est pas livré pieds et poings lié à google. Il y a juste un contrat entre les deux parties. Point barre. Si demain Mozilla veut casser le contrat, ou ne pas le renouveler, elle peut le faire. Tout comme arrêter d'utiliser StopBadware. Alors certes, les revenus de Mozilla seront moindre (mais ils ont maintenant suffisamment de sous en banque pour survivre plusieurs mois..), et leur système anti-site-malveillant moins performant, voir inefficace. Car quelle réèlle alternative y a-t-il à StopBadware, qui soit la plus exhaustive possible et fiable ? (vraie question, je ne connais pas ce domaine).
>Sauf que les roues ovales, si un concurent les propose je peut aller les acheter chez lui, et si je veux de roues ovales je vais pas aller acheter une voiture qui a des roues rondes ou carrée.
je serais curieux de savoir quel constructeur automobile accepterai de vendre des roues ovales. Très franchement ;-)
> Le problème c'est si tu dis au mec je peut pas faire un design au pixel près et que ton concurent le fais, eh bien il va aller chez le concurent.
Non, parce que je lui aurais fait (ou tenter) comprendre le pourquoi de la chose. Et si après ça, il comprend toujours pas, ben alors tant pis. C'est signe que de toute façon, lui et moi on va pas s'entendre, et donc vaut mieux arrêter là et répondre à d'autres demandes de client certainement plus intéressantes.
Et puis si je fonde mon activité sous le signe de la qualité, je n'ai pas intérêt à continuer avec ce genre de client, puisqu'alors je trahi mon engagement vis à vis ce que je propose comme prestation.
Et puis, peut être que le client va aller chez la concurrence, mais peut être aussi se rendra-t-il compte que son site n'est pas si top que ça, quand il verra le site de son pote ou de son concurrent s'afficher sans problème dans son iphone au contraire du sien, et pour peut-être pour un montant moindre...
>- tu refuse en disant que non c'est pas comme ça qu'il faut faire, et tu as un ou deux client par ans seulement. Résultats tu prend un autre job à côter pour bouffer.
Pour les mauvais professionnels, oui, c'est comme ça. Pour les bons, non, car ils ont compris ce qu'est le web, et arrive à faire comprendre à leur client ce qu'est le web.
>C'est chiant à faire : oui, mais c'est possible.
Non, c'est de la poudre au yeux. Je te ruine un design soit disant au pixel près quand tu veux.
>Et si tu pense qu'un professionel qui le fait est un mauvais professionel, et bien il doit pas y avoir beaucoup de bons professionels.
Bah oui, c'est ce que j'ai dit. Il n'y a pas beaucoup de bon professionnels en france, parce que peu veulent faire de la qualité, peu arrivent à faire comprendre (ou à faire vouloir comprendre) à leur client ce qu'est un site web de qualité, ce qu'est un vrai site web etc...
Si il n'y avait peu de mauvais professionnel, on serait pas à expliquer aux clients sans arret que le" pixel pret", c'est de l'utopie.
>Faut pas croire que le créateur de site aime faire ce genre de merdes, mais il n'a pas le choix.
On a toujours le choix. Faire de la merde. Ou pas.
> Si tu compare le Web de maintenant à celui d'il y a quelques année, au niveau du respect des standards ça à quand même évolué.
Ça je le reconnais. Et je me bats depuis plusieurs années pour que ça evolue justement. Ce ciombat porte ses fruits, mais manifestement, à la lecture de tes commentaires et d'autres, il faut continuer...
>Mais le marcher des petits écran par exemple est encore trop faible.
Ouai enfin, ça explose quand même hein. Tu es resté bloqué en 2003 ? :-)
> De même les gens qui changent la taille des polices représentent un très faible pourcentage du public.
Tu as des statistiques ? des vraies ? qu'en sais tu ?
Je dirais plutôt le contraire. Quand dans firefox on a changé la manière de zoomer, on a eu des plaintes (ou des remerciements) de toutes part. Preuve que le zoom est bien plus utilisé que tu le crois, mais alors bien plus.
Je ne suis pas handicapé visuellement (quoiqu'une legère myopie), mais ça m'arrive souvent de zoomer, parce que par exemple y a des webdesigners qui trouvent qu'une police de 6pt ça fait super top, que le design est à chier et qu'on voit mal le texte, ou parce que je veux voir les details sur une photo minuscule etc..
>Pour l'instant les client voient pas trop l'intéret de changer leur mode de fonctionement pour un public aussi marginal,
parce qu'ils sont justement mal renseigné, par des (mauvais) professionnels mal renseignés. Ce public dont tu parles est loin d'être marginal. Tout le monde est différent. Tout le monde ont des modes de consultations differents, des écrans differents, des navigateurs différents etc..
> Tu ne lui dit pas comment fabriquer la voiture car c'est son metier (enfin pas le siens mais celui de lamarque) mais tu lui dit à quoi tu veux qu'elle ressemble et ce que tu veux exactement qu'il y ait dedans.
Bah, oui comme pour un site web. Ton client te demande comment il veux que son site ressemble, et ce qu'il veut dedans. Mais c'est comme pour les bagnoles, y a des limites à tes désirs.
Va essayer de demander à avoir des roues ovales parce que tu trouves ça super chouette, ou plus realiste, d'avoir un pare-brise super foncé parce que tu veux pas qu'on te voit, le constructeur/concessionnaire va gentillement t'expliquer que c'est pas possible, à cause de contraintes techniques ou légales. Si il accepte, c'est que c'est un constructeur/concessionnaire verreux et tot ou tard tu te fera avoir (problème mécaniques pour les roues ovales ou accident/amendes à cause du pare brise foncé)
C'est pareil pour un site web HTML/CSS. Y a des contraintes techniques. L'une d'elle est que le design au pixel près est IMPOSSIBLE, parce que c'est pas fait pour. Si tu lui dit "oui oui je le fais", au mieux, tu es un mauvais professionnel parce que tu sais très bien qu'au fond de toi ça va être dur et que ça va de toute façon pas passer dans pas mal de cas. Et au pire, tu es un professionnel malhonnete parce que tu fais croire à ton client que c'est possible et qu'il n'y aura pas de problème, alors que c'est faux. Et du coup, il va croire que ceux qui lui disent que ce n'est pas possible sont des menteurs etc..
bref, des attitudes comme celle que tu décris pourri le milieu professionnel du web, et entretien la mauvaise qualité générale des sites web.
>Quand ton client gagne beaucoup d'argent sur Internet, il serait présomptueux de vouloir lui apprendre son travail.
Gni ?
Si il te demande de faire son site web, c'est que ce n'est pas son travail. Lui son travail, c'est de faire vivre le site (ou pas), point barre.
Et si il prétend savoir que le pixel pres c'est bien, ba désolé, c'est toujours pas son boulot, même si il prétend que ça l'est, parce que dans ce cas cela montre qu'il n'a absolument rien compris à internet.
Et toi, si tu continue à penser que c'est à ton client de te dicter les details techniques, de comment il faut faire son site web : change de metier.
Toi, quand tu va faire reviser ta bagnole, tu vas dire à ton garagiste ce qu'il faut qu'il fasse, et comment il faut qu'il le fasse ? Non hein. Au pire, tu lui indiques qu'il se pourrait qu'il y ait un problème ici ou là parce que tu entend un bruit bizarre, ou des conneries comme ça.
Ben là c'est pareil. C'est pas à ton client de t'expliquer de comment il faut faire ton métier. C'est à toi de lui expliquer les choses, de lui faire comprendre pourquoi tu fais comme ci et comme ça, point. Et ça, c'est vraiment faire preuve de professionnalisme.
Très honnetement, si tu ne sais pas te faire entendre/comprendre, encore une fois, change de métier.
>Et ouais, mais des fois, ya pas grand chose a lire, c'est juste une plaquette publicitaire.
Et ? une plaquette publicitaire peut très bien s'adapter à un contexte de consultation précis. Inutile de vouloir du pixel près sur chaque type de navigateur.
> Mais comment fait pdf pour garder un rendu identique sur toutes les machines du monde si c'est impossible?
Le format PDF impose des dimensions à la page, a des rêgles strictes de présentation. Et pour cause, il est destiné à l'impression !
Le web n'est pas destiné à l'impression. Le web est déstiné à pouvoir être lu dans n'importe quelle circonstance, quel que soit le type de navigateur, le type de périphérique de sortie etc. Bref, une page web a la faculté (si elle n'est pas faite comme on fait du print) de s'adapter à la majorité des circonstances.
Tu parles de pixel. Le pixel n'est qu'une unité. Une indication. Qui est vite convertie par le navigateur. Il suffit que l'utilisateur zoom d'un cran, et ton pixel, tu peux aller l'oublier. Ton pixel n'est plus un pixel. Tout simplement parce que c'est ça le web : pouvoir adapter et transformer une page web en fonction des conditions de lecture et des besoins.
Et c'est d'autant plus vrai que la diversité des modes de consultations explosent, à cause de la diversité des mobiles entre autre.
>Va expliquer ca a ceux qui font des applis web style webmail ou autre, que leurs boutons ne vont pas etre alignes comme ils le veulent et autres joyeusetes.
Si ça ne s'aligne pas comme ils veulent, c'est qu'ils utilisent mal les technos du web. Je n'ai personnellement aucun mal à faire un design, fluide, liquide, qui s'adapte à bon nombre de circonstance, sans avoir à faire des hacks dans tout les sens pour tel ou tel navigateur. Et l'une des raisons du pourquoi je n'ai aucun mal : c'est parce que j'ai accepté l'idée de ne pas avoir un design identique au pixel près dans tous les contextes. (je te jure, une fois qu'on accepte cette idée, tout devient plus simple, puisqu'on s'enlève des tonnes de contraintes inutiles)
Et si tu expliques bien à un client le pourquoi du comment (en gros, les arguments donnés dans le lien que j'ai donné plus haut), il acceptera certainement ce fait, et sera même probablement très content que son site passe sur un maximum de navigateur même si il n'est pas identique au pixel près.
Au passage, ne pas avoir un design identique au pixel près, ça ne veux pas forcément dire un design moche dans telle ou telle situation. Faut juste oublier les habitudes du "print" sur le web.
Et pour finir : très franchement, je n'ai jamais vu d'internaute ouvrir un site sur plusieurs navigateurs en même temps pour vérifier qu'il est identique au pixel prés dans chacun d'eux. L'internaute il en a rien à battre. L'internaute il veut juste que ce soit lisible.
> Donc non il n'y a pas de gain de debit, taille ou qualité a attendre de la part de theora. Theora est un codec somme toute médiocre dont le seul avantage est d'être totalement libre.
c'est probablement le cas aujourd'hui.
Mais il me semble, d'après la news, que le financement de Mozilla est déstiné justement à améliorer tout ça ;-)
> Attends, le monsieur dit qu'il veut que la page rende comme elle doit etre rendre sur tout les navigateurs, ca me semble etre LE precepte de base du web
Absolument pas ! Le web n'est pas un media figé. Donc le "pixel près" est absolument incompatible.
Le principal pour un site web c'est qu'il reste lisible et agréable à lire. Qu'il soit équivalent au pixel près d'un navigateur à un autre, est absolument inutile, et impossible.
Ton discours est digne des soit-disant "web designer" du siècle dernier.
La transition est toute faite : utiliser un element object comme on fait d'habitude, à l'interieur d'un element video. Le navigateur qui ne connait pas video "executera" l'element object, et celui qui connait la balise video, est censé ignoré le contenu de cet element.
<video src="mavideo.ogg">
<p class="avertissement">Pour profiter au maximum de la vidéo et des possibilités de cette page web, vous devriez installer un navigateur récent : Firefox 3.1, Safari, ou Opera.</p>
<object>
<param name="movie" value="flvplayer.swf?file=mavideo.flv"></param>
<embed src="flvplayer.swf?file=mavideo.flv" type="application/x-shockwave-flash"></embed>
</object>
</video>
Pour en savoir plus http://ljouanneau.com/blog/post/2008/10/16/L-element-video
>ou de réaffecter une partie du personnel à la R&D.
hum... Dans le cas d'une entreprise automobile, j'aurai personnellement du mal à réaffecter tout ces ouvriers de la chaine de fabrication (actuellement les plus touchés par le chomage technique chez Renault) vers de la R&D...
C'est pas que je prend les ouvriers pour des abrutis. Mais pour la majorité d'entre eux, je ne pense pas qu'ils aient les bagages qu'il faut (connaissances, compétences...).
Et puis la R&D, ça coute. Et surtout ça ne rapporte rien directement et à court terme. Donc au niveau financement, c'est très très lourd.
M'enfin c'est toi qui voit. Y en a qui ont essayé. Ils ont eu des problèmes !
> <?=$variable?> marche bien en php, avec l'option "short_open_tag = On".
short_open_tag est deprecié il me semble. Ensuite, personnellement, je trouve que l'usage du <?(php) et ?> apporte de la confusion dans la lecture du source, avec les balises html.
Et globalement, tu tapes sur 3 touches de plus (ouai je chipote :-).
> Avec une coloration syntaxique c'est clair comme de l'eau de roche.
{$personnes|count} listée(s) :
{foreach $personnes as $p}
Nom : {$p->nom}, Age : {$p->age} ans
{/foreach}
avec ou SANS coloration syntaxique, ça reste clair comme de l'eau de roche.
;-)
enfin bon, là on en arrive à des question de gouts et de couleurs...
>Car au final, le mainteneur devra se familiariser avec tout un nouveau jargon, des nouveaux concepts et j'en passe,
Sauf si il connait déjà lesdits frameworks, moteur de templates et cie. Ce qui a de forte chance d'arriver si c'est un framework connu et pas mal utilisé dans l'industrie.
Alors que pour du "simple" code php (qui n'est jamais vraiment simple dès que le site devient conséquent), même clair, structuré et uniforme, bah c'est structuré différement à chaque projet, donc le développeur doit d'abord à chaque fois apprendre comment le site s'articule avant de pouvoir modifier le code metier à maintenir.
Donc, non, un développeur ne se "contente" jamais de maintenir un simple code PHP (sauf pour les sites de 3 pages).
Et le meilleur moyen d'avoir un code maintenable, c'est d'écrire du code selon des normes et des structures reconnus, c'est à dire, utiliser des frameworks, puisque tel est le but des framework: offrir une structuration (troll: ZF mise à part, puisque ZF n'impose pas de structure, et est plus une grosse lib dans laquelle on pioche qu'autre chose).
CQFD.
fais un tour en SSII, en demandant à bosser sur des missions courtes, de manière à travailler sur un maximum de projet, et là tu te rendra compte de l'intérêt des frameworks, et à coup sûr, tu pesteras sur les projets développé sans framework connu. Projets qui sont, forcément, vu que le boulot est toujours pour il y a deux jours, développé à l'arrache, donc souvent difficilement maintenable, alors que pour ceux avec un framework, les développeurs n'ont pas eu à passer du temps à réinventer la roue, et ont pu se concentrer rapidement sur le code métier, et ont donc un code naturellement plus structuré
bon, je dis pas non plus qu'il n'est pas possible de faire du super crad avec un framework, mais c'est déjà moins facile de faire du code crad avec un framework qui impose une structure que dans un projet sans framework.
Pour compléter à propos de jTpl (dont je suis l'auteur :-), j'ai essayé d'avoir les avantages à la fois des templates pur php, et d'un langage de template spécifique, à savoir :
* faciliter l'écriture. par exemple, remplacer les "<?php echo $variable?>" par une syntaxe plus simple comme {$variable}
* sans toutefois ne pas avoir à reinventer totalement un langage, c'est pourquoi les expressions utilisées sont en php. ex: {$variable.$objet->propriete} qui est équivalent à...<?php echo $variable.$objet->propriete?> tout simplement :-)
* mais en posant des restrictions, pour éviter d'avoir du code métier dans les templates, c'est pourquoi les expressions sont parsées (en utilisant le tokenizer de php ;-) et "filtrées".
il y a des tags typiques comme {foreach}, {for}, {if} et cie, fonctionnant comme en php.
Alors, ubitux trouve que c'est une abération que d'avoir des if/while dans un template, à ceci je lui repondrais :
1) il est lui même en contradiction avec ce qu'il dit, puisqu'il semble être pour utiliser PHP pour les templates, et donc ces templates peuvent contenir des if/while...
2) il y a des moteurs de templates qui obligent à faire les boucles en dehors du template, c'est à dire que dans le template lui même, on définit les "blocs" qui seront itérés, et en dehors du template, en php, on fait les boucles, et on appele des méthodes du moteur de template pour générer les blocs à chaque itération. Je trouve cela complètement ridicule, car dès lors que l'on veuille faire des modifications dans le template, il faut alors modifier en même temps le template ET le code php externe au template. Ce qui limite grandement les modifications, donc la personnalisation des templates
ex, dans le template original, on affiche une liste dans une seule colonne, donc une boucle, et dans notre nouveau theme, on veux que ce soit sur deux colonnes, donc deux boucles, ou alors une seule mais faudrait pouvoir ajouter un test à l'interieur pour savoir si on est arrivé au milieu de la liste pour créer la deuxieme colonne etc..
Avec ce genre de moteur de template, on est donc obligé de modifier le code PHP externe, donc le code de l'appli. Et puis cela veut dire aussi que la couche "vue" est scindée en deux "sous-couche", la logique de construction d'un coté (qui n'empèche pas de mélanger allègrement avec du code métier, ce qui est dommage), le code purement html de l'autre, ce qui n'est vraiment pas terrible, du point de vue de la maintenance et l'évolution.
Je préfère donc de loin, les moteurs de templates qui autorisent les instructions de contrôles if/foreach et cie.
Enfin, avoir une syntaxe un peu spécifique et controllée comme celle de jtpl permet d'une part, de faciliter l'écriture des templates par des webdesigners, mais aussi de permettre à l'application par exemple de proposer à un utilisateur d'uploader un template ou un thème sans compromettre la sécurité de l'application (jTpl a d'ailleurs un mode de fonctionnement avancé pour ce genre de template, apportant encore plus de sécurité)
J'oubliais aussi: comme Smarty, jTpl génère des fichiers PHP à partir des templates et les mets en cache, ce qui évite le parsing du template à chaque utilisation. Donc point de vue performance, la différence est vraiment insignifiante par rapport à un template pure php (il y a en gros un file_exists pour vérifier l'existance du cache, et un simple include du cache).
Autre avantage de jTpl par rapport à smarty : 320 lignes de codes pour le moteur + 520 pour le "compilateur" (non chargée si le cache est ok), commentaires compris, contre plus de 1900+2800 pour smarty ... Les caches d'opcodes apprecieront... (pour un nombre de fonctionnalité à peu près équivalent, quelques features bloatware en moins dans jtpl)
Je connais un site vraiment sympa, qui permet de traduire les extensions XUL (pour firefox ou d'autres logiciels en XUL) : http://babelzilla.org/
Pour traduire, c'est très simple, suffit de s'inscrire et il y a une interface très simple pour traduire toutes les chaînes d'une extension. En gros, un simple formulaire avec un champs pour chaque chaîne. Bref, ça requiert des connaissances techniques peu poussées.
[^] # Re: Bad design
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Bélier 0.6 : Outil d'automatisation de connexions ssh complexes. Évalué à 1.
C'est sûr que tu n'a pas de contributeurs anglais (et tu auras peu de chances d'en avoir), vu que c'est en français. C'est un peu comme faire un site qui a un script qui check le navigateur et n'accepte que IE, et dire ensuite que ce n'est pas la peine de faire un site compatible avec les autres navigateurs vu que dans les stats, ils sont totalement insignifiants. (c'est du vecu :-) )
Ensuite, en parlant de "contributeurs anglais": Le monde est vaste, les contributeurs peuvent venir de tout pays, pas seulement des états unis ou Angleterre. Et l'anglais est probablement la langue la plus "universelle" (surtout en informatique). Donc c'est pas seulement des contributeurs "anglais" que tu pourrais avoir ;-)
Bonne continuation dans ce projet tout de même :-)
[^] # Re: On n'est pas vendredi
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Python, langage de l'année pour la seconde année consécutive. Évalué à 2.
Bref, la comparaison entre Python et XUL n'a pas lieu d'être.
[^] # Re: On n'est pas vendredi
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Python, langage de l'année pour la seconde année consécutive. Évalué à 6.
Euh, c'est quoi le rapport avec un langage de programmation comme python ? Le XUL n'est qu'un format descriptif d'une interface utilisateur. Tu compares dont un format avec un langage. Très fort :-)
C'est certainement pas avec ça que je vais développer le moteur de rendu d'un browser (j'ai bien dit : moteur de rendu). à coup sûr, si je n'avais qu'à choisir entre XUL et python, je choisirais bien évidement python pour un projet comme ça, parce qu'avec XUL, je ne vais pas aller loin...
> certainement pas le fait que c'est interprété,
"interpreter" un fichier XML, c'est pas pertinent... Surtout que dans Gecko, le XUL n'est pas interprété, mais analysé et ensuite on travaille avec un DOM...
>qu'il n'y a pas d'éditeur dédié,
y a des plugins pour eclipse, y a Komodo...
> ni de tests unitaires normalisés,
Je ne vois pas ce que tu appelles "normalisés", mais il existe des outils pour faire des tests unitaires dans Mozilla.
>ni de compilation pour la vérification des types
hors sujet vis à vis de XUL
> encore d'équivalent de valgrind pour les fuites mémoires ?
Valgrind est utilisé dans le developpement de Gecko (même si il n'y a toujours aucun rapport avec XUL).
# On n'est pas vendredi
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Python, langage de l'année pour la seconde année consécutive. Évalué à 4.
Ouaouuu... Rien que ça. C'est totalement subjectif ça. C'est peut être la meilleur façon pour TOI. Mais sûrement pas pour tout le monde. Chacun a ses préférences, ses goûts en matière de langage. Personnellement, ce n'est certainement pas avec Python que je vais produire des logiciels maintenables et de qualité. Tout simplement parce que je n'aime pas trop Python. Et ça veut pas dire qu'avec un autre langage, je ne vais pas produire des logiciels maintenables et de qualité.
Et puis, en dehors des gouts et des couleurs, il y a aussi le fait que chaque langage a ses spécificités, qui lui permet d'être plus efficace que d'autres pour la réalisation d'un type de logiciel particulier. Ce n'est par exemple certainement pas avec Python que je vais m'amuser à faire le moteur de rendu d'un browser HTML...
[^] # Re: Editeur svg
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sortie d'Amaya 11. Évalué à 2.
Euh, ça fait des lustres qu'il sait faire. Au moins depuis sa version 2. Et bien avant pour le XHTML+MathML.
[^] # Re: Google sabote Internet... avec la complicité de Mozilla
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [HS] Attention, internet peut endomager votre ordinateur. Évalué à 3.
C'est pas du tout exclusif. Faut arreter la parano.
Pour le moteur de recherche, je te rappel que tu as le choix. Firefox est livré avec un certain nombre de moteur de recherche, et tu peux les supprimer, en installer d'autres. bref. Aucune exclusivité si ce n'est que Mozilla met en avant Google parce qu'ils ont un plus gros contrat avec eux qu'avec les autres (et que la cantine google est à deux pas et est très bonne :-))
Pour le service anti "sites pourris", c'est totalement paramètrable : about:config -> browser.safebrowsing.
Il t'embete ? tu le désactives (à partir de la boite des préférences ou dans le about:config). Tu veux en choisir un autre, tu renseignes les bons paramètres dans le about:config. Et si ça se trouve, il y a des extensions qui te permettent de configurer facilement vers d'autres fournisseurs.
Quant à ta liste de "Mozilla aurait pu", c'est facile à dire, il y en a qui ont refait le monde avec des "si". Et si pour chaque fonctionnalité qu'il y a dans Firefox, il fallait proposer un choix à l'installation, je doute que Firefox aurait eu le succés qu'il a. Et à mon avis, proposer le choix d'activer au premier démarrage n'aurait servi à rien, car pour 90% des gens, ils ne sauraient pas quoi répondre et activerait sans se poser de question (surtout si on leur dit que ça rend la navigation plus sûre).
>Le jour ou Mozilla voudra dire merde à google, google pourra envoyer des listes gonflées aux navigateurs utilisant ce service (majoritairement mozilla) pour planter la réputation de la fondation.
Mouai bof. Mozilla push une nouvelle version mineure de Firefox, avec des nouveaux paramètres de confs, et la majorité des installations n'utiliseront plus le service de Google. Et très franchement, je doute que Google fasse se genre de bêtise, sous peine de se prendre un procés aux fesses et une très mauvaise image (et contredire leur moto, "don't be evil").
[^] # Re: Google sabote Internet... avec la complicité de Mozilla
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [HS] Attention, internet peut endomager votre ordinateur. Évalué à 5.
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 1.
>Sauf que les roues ovales, si un concurent les propose je peut aller les acheter chez lui, et si je veux de roues ovales je vais pas aller acheter une voiture qui a des roues rondes ou carrée.
je serais curieux de savoir quel constructeur automobile accepterai de vendre des roues ovales. Très franchement ;-)
> Le problème c'est si tu dis au mec je peut pas faire un design au pixel près et que ton concurent le fais, eh bien il va aller chez le concurent.
Non, parce que je lui aurais fait (ou tenter) comprendre le pourquoi de la chose. Et si après ça, il comprend toujours pas, ben alors tant pis. C'est signe que de toute façon, lui et moi on va pas s'entendre, et donc vaut mieux arrêter là et répondre à d'autres demandes de client certainement plus intéressantes.
Et puis si je fonde mon activité sous le signe de la qualité, je n'ai pas intérêt à continuer avec ce genre de client, puisqu'alors je trahi mon engagement vis à vis ce que je propose comme prestation.
Et puis, peut être que le client va aller chez la concurrence, mais peut être aussi se rendra-t-il compte que son site n'est pas si top que ça, quand il verra le site de son pote ou de son concurrent s'afficher sans problème dans son iphone au contraire du sien, et pour peut-être pour un montant moindre...
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 2.
Pour les mauvais professionnels, oui, c'est comme ça. Pour les bons, non, car ils ont compris ce qu'est le web, et arrive à faire comprendre à leur client ce qu'est le web.
>C'est chiant à faire : oui, mais c'est possible.
Non, c'est de la poudre au yeux. Je te ruine un design soit disant au pixel près quand tu veux.
>Et si tu pense qu'un professionel qui le fait est un mauvais professionel, et bien il doit pas y avoir beaucoup de bons professionels.
Bah oui, c'est ce que j'ai dit. Il n'y a pas beaucoup de bon professionnels en france, parce que peu veulent faire de la qualité, peu arrivent à faire comprendre (ou à faire vouloir comprendre) à leur client ce qu'est un site web de qualité, ce qu'est un vrai site web etc...
Si il n'y avait peu de mauvais professionnel, on serait pas à expliquer aux clients sans arret que le" pixel pret", c'est de l'utopie.
>Faut pas croire que le créateur de site aime faire ce genre de merdes, mais il n'a pas le choix.
On a toujours le choix. Faire de la merde. Ou pas.
> Si tu compare le Web de maintenant à celui d'il y a quelques année, au niveau du respect des standards ça à quand même évolué.
Ça je le reconnais. Et je me bats depuis plusieurs années pour que ça evolue justement. Ce ciombat porte ses fruits, mais manifestement, à la lecture de tes commentaires et d'autres, il faut continuer...
>Mais le marcher des petits écran par exemple est encore trop faible.
Ouai enfin, ça explose quand même hein. Tu es resté bloqué en 2003 ? :-)
> De même les gens qui changent la taille des polices représentent un très faible pourcentage du public.
Tu as des statistiques ? des vraies ? qu'en sais tu ?
Je dirais plutôt le contraire. Quand dans firefox on a changé la manière de zoomer, on a eu des plaintes (ou des remerciements) de toutes part. Preuve que le zoom est bien plus utilisé que tu le crois, mais alors bien plus.
Je ne suis pas handicapé visuellement (quoiqu'une legère myopie), mais ça m'arrive souvent de zoomer, parce que par exemple y a des webdesigners qui trouvent qu'une police de 6pt ça fait super top, que le design est à chier et qu'on voit mal le texte, ou parce que je veux voir les details sur une photo minuscule etc..
>Pour l'instant les client voient pas trop l'intéret de changer leur mode de fonctionement pour un public aussi marginal,
parce qu'ils sont justement mal renseigné, par des (mauvais) professionnels mal renseignés. Ce public dont tu parles est loin d'être marginal. Tout le monde est différent. Tout le monde ont des modes de consultations differents, des écrans differents, des navigateurs différents etc..
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 1.
Bah, oui comme pour un site web. Ton client te demande comment il veux que son site ressemble, et ce qu'il veut dedans. Mais c'est comme pour les bagnoles, y a des limites à tes désirs.
Va essayer de demander à avoir des roues ovales parce que tu trouves ça super chouette, ou plus realiste, d'avoir un pare-brise super foncé parce que tu veux pas qu'on te voit, le constructeur/concessionnaire va gentillement t'expliquer que c'est pas possible, à cause de contraintes techniques ou légales. Si il accepte, c'est que c'est un constructeur/concessionnaire verreux et tot ou tard tu te fera avoir (problème mécaniques pour les roues ovales ou accident/amendes à cause du pare brise foncé)
C'est pareil pour un site web HTML/CSS. Y a des contraintes techniques. L'une d'elle est que le design au pixel près est IMPOSSIBLE, parce que c'est pas fait pour. Si tu lui dit "oui oui je le fais", au mieux, tu es un mauvais professionnel parce que tu sais très bien qu'au fond de toi ça va être dur et que ça va de toute façon pas passer dans pas mal de cas. Et au pire, tu es un professionnel malhonnete parce que tu fais croire à ton client que c'est possible et qu'il n'y aura pas de problème, alors que c'est faux. Et du coup, il va croire que ceux qui lui disent que ce n'est pas possible sont des menteurs etc..
bref, des attitudes comme celle que tu décris pourri le milieu professionnel du web, et entretien la mauvaise qualité générale des sites web.
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 4.
Gni ?
Si il te demande de faire son site web, c'est que ce n'est pas son travail. Lui son travail, c'est de faire vivre le site (ou pas), point barre.
Et si il prétend savoir que le pixel pres c'est bien, ba désolé, c'est toujours pas son boulot, même si il prétend que ça l'est, parce que dans ce cas cela montre qu'il n'a absolument rien compris à internet.
Et toi, si tu continue à penser que c'est à ton client de te dicter les details techniques, de comment il faut faire son site web : change de metier.
Toi, quand tu va faire reviser ta bagnole, tu vas dire à ton garagiste ce qu'il faut qu'il fasse, et comment il faut qu'il le fasse ? Non hein. Au pire, tu lui indiques qu'il se pourrait qu'il y ait un problème ici ou là parce que tu entend un bruit bizarre, ou des conneries comme ça.
Ben là c'est pareil. C'est pas à ton client de t'expliquer de comment il faut faire ton métier. C'est à toi de lui expliquer les choses, de lui faire comprendre pourquoi tu fais comme ci et comme ça, point. Et ça, c'est vraiment faire preuve de professionnalisme.
Très honnetement, si tu ne sais pas te faire entendre/comprendre, encore une fois, change de métier.
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 10.
Et ? une plaquette publicitaire peut très bien s'adapter à un contexte de consultation précis. Inutile de vouloir du pixel près sur chaque type de navigateur.
> Mais comment fait pdf pour garder un rendu identique sur toutes les machines du monde si c'est impossible?
Le format PDF impose des dimensions à la page, a des rêgles strictes de présentation. Et pour cause, il est destiné à l'impression !
Le web n'est pas destiné à l'impression. Le web est déstiné à pouvoir être lu dans n'importe quelle circonstance, quel que soit le type de navigateur, le type de périphérique de sortie etc. Bref, une page web a la faculté (si elle n'est pas faite comme on fait du print) de s'adapter à la majorité des circonstances.
Tu parles de pixel. Le pixel n'est qu'une unité. Une indication. Qui est vite convertie par le navigateur. Il suffit que l'utilisateur zoom d'un cran, et ton pixel, tu peux aller l'oublier. Ton pixel n'est plus un pixel. Tout simplement parce que c'est ça le web : pouvoir adapter et transformer une page web en fonction des conditions de lecture et des besoins.
Et c'est d'autant plus vrai que la diversité des modes de consultations explosent, à cause de la diversité des mobiles entre autre.
>Va expliquer ca a ceux qui font des applis web style webmail ou autre, que leurs boutons ne vont pas etre alignes comme ils le veulent et autres joyeusetes.
Si ça ne s'aligne pas comme ils veulent, c'est qu'ils utilisent mal les technos du web. Je n'ai personnellement aucun mal à faire un design, fluide, liquide, qui s'adapte à bon nombre de circonstance, sans avoir à faire des hacks dans tout les sens pour tel ou tel navigateur. Et l'une des raisons du pourquoi je n'ai aucun mal : c'est parce que j'ai accepté l'idée de ne pas avoir un design identique au pixel près dans tous les contextes. (je te jure, une fois qu'on accepte cette idée, tout devient plus simple, puisqu'on s'enlève des tonnes de contraintes inutiles)
Et si tu expliques bien à un client le pourquoi du comment (en gros, les arguments donnés dans le lien que j'ai donné plus haut), il acceptera certainement ce fait, et sera même probablement très content que son site passe sur un maximum de navigateur même si il n'est pas identique au pixel près.
Au passage, ne pas avoir un design identique au pixel près, ça ne veux pas forcément dire un design moche dans telle ou telle situation. Faut juste oublier les habitudes du "print" sur le web.
Et pour finir : très franchement, je n'ai jamais vu d'internaute ouvrir un site sur plusieurs navigateurs en même temps pour vérifier qu'il est identique au pixel prés dans chacun d'eux. L'internaute il en a rien à battre. L'internaute il veut juste que ce soit lisible.
[^] # Re: Youtube
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 1.
c'est probablement le cas aujourd'hui.
Mais il me semble, d'après la news, que le financement de Mozilla est déstiné justement à améliorer tout ça ;-)
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 4.
Absolument pas ! Le web n'est pas un media figé. Donc le "pixel près" est absolument incompatible.
Le principal pour un site web c'est qu'il reste lisible et agréable à lire. Qu'il soit équivalent au pixel près d'un navigateur à un autre, est absolument inutile, et impossible.
Ton discours est digne des soit-disant "web designer" du siècle dernier.
Aller, hop, une petite lecture pour que tu ais une autre vision, plus réèlle, du web : http://www.pompage.net/pompe/tao/
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 1.
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 9.
<video src="mavideo.ogg">
<p class="avertissement">Pour profiter au maximum de la vidéo et des possibilités de cette page web, vous devriez installer un navigateur récent : Firefox 3.1, Safari, ou Opera.</p>
<object>
<param name="movie" value="flvplayer.swf?file=mavideo.flv"></param>
<embed src="flvplayer.swf?file=mavideo.flv" type="application/x-shockwave-flash"></embed>
</object>
</video>
Pour en savoir plus http://ljouanneau.com/blog/post/2008/10/16/L-element-video
[^] # Re: c'est beau le capitalisme
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal MS va supprimer 5000 postes. Évalué à 1.
hum... Dans le cas d'une entreprise automobile, j'aurai personnellement du mal à réaffecter tout ces ouvriers de la chaine de fabrication (actuellement les plus touchés par le chomage technique chez Renault) vers de la R&D...
C'est pas que je prend les ouvriers pour des abrutis. Mais pour la majorité d'entre eux, je ne pense pas qu'ils aient les bagages qu'il faut (connaissances, compétences...).
Et puis la R&D, ça coute. Et surtout ça ne rapporte rien directement et à court terme. Donc au niveau financement, c'est très très lourd.
M'enfin c'est toi qui voit. Y en a qui ont essayé. Ils ont eu des problèmes !
# le titre
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Carrefour et les licences liées. Évalué à 6.
"vente liée" par contre, ça correspond plus au sujet de ton journal ;-)
[^] # Re: Un moteur de templates est très utile
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De l'utilité des moteurs de templates en PHP. Évalué à 1.
short_open_tag est deprecié il me semble. Ensuite, personnellement, je trouve que l'usage du <?(php) et ?> apporte de la confusion dans la lecture du source, avec les balises html.
Et globalement, tu tapes sur 3 touches de plus (ouai je chipote :-).
> Avec une coloration syntaxique c'est clair comme de l'eau de roche.
{$personnes|count} listée(s) :
{foreach $personnes as $p}
Nom : {$p->nom}, Age : {$p->age} ans
{/foreach}
avec ou SANS coloration syntaxique, ça reste clair comme de l'eau de roche.
;-)
enfin bon, là on en arrive à des question de gouts et de couleurs...
[^] # Re: Keep It Simple, Stupid
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De l'utilité des moteurs de templates en PHP. Évalué à 1.
Sauf si il connait déjà lesdits frameworks, moteur de templates et cie. Ce qui a de forte chance d'arriver si c'est un framework connu et pas mal utilisé dans l'industrie.
Alors que pour du "simple" code php (qui n'est jamais vraiment simple dès que le site devient conséquent), même clair, structuré et uniforme, bah c'est structuré différement à chaque projet, donc le développeur doit d'abord à chaque fois apprendre comment le site s'articule avant de pouvoir modifier le code metier à maintenir.
Donc, non, un développeur ne se "contente" jamais de maintenir un simple code PHP (sauf pour les sites de 3 pages).
Et le meilleur moyen d'avoir un code maintenable, c'est d'écrire du code selon des normes et des structures reconnus, c'est à dire, utiliser des frameworks, puisque tel est le but des framework: offrir une structuration (troll: ZF mise à part, puisque ZF n'impose pas de structure, et est plus une grosse lib dans laquelle on pioche qu'autre chose).
CQFD.
fais un tour en SSII, en demandant à bosser sur des missions courtes, de manière à travailler sur un maximum de projet, et là tu te rendra compte de l'intérêt des frameworks, et à coup sûr, tu pesteras sur les projets développé sans framework connu. Projets qui sont, forcément, vu que le boulot est toujours pour il y a deux jours, développé à l'arrache, donc souvent difficilement maintenable, alors que pour ceux avec un framework, les développeurs n'ont pas eu à passer du temps à réinventer la roue, et ont pu se concentrer rapidement sur le code métier, et ont donc un code naturellement plus structuré
bon, je dis pas non plus qu'il n'est pas possible de faire du super crad avec un framework, mais c'est déjà moins facile de faire du code crad avec un framework qui impose une structure que dans un projet sans framework.
# Note
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal LinuxFR en rails ?. Évalué à 10.
- vote pour l'achat de 2 serveurs supplémentaires afin de répondre aux exigences du nouveau site en matière de tenu en charge.
(Hein ? comment ça on n'est pas vendredi ? ->[])
[^] # Re: Un moteur de templates est très utile
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De l'utilité des moteurs de templates en PHP. Évalué à 2.
* faciliter l'écriture. par exemple, remplacer les "<?php echo $variable?>" par une syntaxe plus simple comme {$variable}
* sans toutefois ne pas avoir à reinventer totalement un langage, c'est pourquoi les expressions utilisées sont en php. ex: {$variable.$objet->propriete} qui est équivalent à...<?php echo $variable.$objet->propriete?> tout simplement :-)
* mais en posant des restrictions, pour éviter d'avoir du code métier dans les templates, c'est pourquoi les expressions sont parsées (en utilisant le tokenizer de php ;-) et "filtrées".
il y a des tags typiques comme {foreach}, {for}, {if} et cie, fonctionnant comme en php.
Alors, ubitux trouve que c'est une abération que d'avoir des if/while dans un template, à ceci je lui repondrais :
1) il est lui même en contradiction avec ce qu'il dit, puisqu'il semble être pour utiliser PHP pour les templates, et donc ces templates peuvent contenir des if/while...
2) il y a des moteurs de templates qui obligent à faire les boucles en dehors du template, c'est à dire que dans le template lui même, on définit les "blocs" qui seront itérés, et en dehors du template, en php, on fait les boucles, et on appele des méthodes du moteur de template pour générer les blocs à chaque itération. Je trouve cela complètement ridicule, car dès lors que l'on veuille faire des modifications dans le template, il faut alors modifier en même temps le template ET le code php externe au template. Ce qui limite grandement les modifications, donc la personnalisation des templates
ex, dans le template original, on affiche une liste dans une seule colonne, donc une boucle, et dans notre nouveau theme, on veux que ce soit sur deux colonnes, donc deux boucles, ou alors une seule mais faudrait pouvoir ajouter un test à l'interieur pour savoir si on est arrivé au milieu de la liste pour créer la deuxieme colonne etc..
Avec ce genre de moteur de template, on est donc obligé de modifier le code PHP externe, donc le code de l'appli. Et puis cela veut dire aussi que la couche "vue" est scindée en deux "sous-couche", la logique de construction d'un coté (qui n'empèche pas de mélanger allègrement avec du code métier, ce qui est dommage), le code purement html de l'autre, ce qui n'est vraiment pas terrible, du point de vue de la maintenance et l'évolution.
Je préfère donc de loin, les moteurs de templates qui autorisent les instructions de contrôles if/foreach et cie.
Enfin, avoir une syntaxe un peu spécifique et controllée comme celle de jtpl permet d'une part, de faciliter l'écriture des templates par des webdesigners, mais aussi de permettre à l'application par exemple de proposer à un utilisateur d'uploader un template ou un thème sans compromettre la sécurité de l'application (jTpl a d'ailleurs un mode de fonctionnement avancé pour ce genre de template, apportant encore plus de sécurité)
J'oubliais aussi: comme Smarty, jTpl génère des fichiers PHP à partir des templates et les mets en cache, ce qui évite le parsing du template à chaque utilisation. Donc point de vue performance, la différence est vraiment insignifiante par rapport à un template pure php (il y a en gros un file_exists pour vérifier l'existance du cache, et un simple include du cache).
Autre avantage de jTpl par rapport à smarty : 320 lignes de codes pour le moteur + 520 pour le "compilateur" (non chargée si le cache est ok), commentaires compris, contre plus de 1900+2800 pour smarty ... Les caches d'opcodes apprecieront... (pour un nombre de fonctionnalité à peu près équivalent, quelques features bloatware en moins dans jtpl)
http://jelix.org/articles/fr/manuel-1.1/templates
Teasing: la version 1.0 de jTpl standalone sort très bientôt
# BabelZilla
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Méthodo localisation / Actu Mandriva. Évalué à 2.
Pour traduire, c'est très simple, suffit de s'inscrire et il y a une interface très simple pour traduire toutes les chaînes d'une extension. En gros, un simple formulaire avec un champs pour chaque chaîne. Bref, ça requiert des connaissances techniques peu poussées.
http://www.babelzilla.org/content/view/1/1/
[^] # Re: Gasp ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal N'installez pas PHP 5.2.7 !. Évalué à 5.
[^] # Re: Perso
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal EyeOS 1.7.0. Évalué à 4.
Hein ? ah oui mince, cette génèse n'est pas de Dieu... Désolé...