Auriez-vous connaissance d'un script fait en JavaScript qui pourrait simuler
un éditeur de texte dans un textarea et ensuite on sélectionne des mots et
on clique sur un bouton (bold) qui intègre automatiquement les balises html?
Devx a déjà parlé de "gros lourds" à propos de FCK et TinyMCE et j'avais déjà demandé des précisions, je fais donc la même chose suite à votre message ? UN poil trop lourd, qu'est-ce que ça veut dire dans les détails ?
Tout ceci est relatif (mon jugement), mais par exemple si on compare les contenus des tarballs de FCKeditor et wymeditor, en supprimant seulement les exemples :
FCKeditor_2.6.3.tar.gz
$ du -hs fckeditor 5.0M fckeditor $ find fckeditor -type f | wc -l 477
wymeditor-0.5-beta-2.tar.gz
$ du -hs wymeditor 700K wymeditor $ find wymeditor -type f | wc -l 72
Je sais que pour FCKeditor on peut pousser le ménage bien plus loin, mais justement le faire à chaque release est pénible.
En ce qui concerne FCKeditor, il est souvent *plus gros* que les projets auxquels je le greffe. De plus à l'usage (côté navigateur), je le trouve assez long à se charger, je viens de faire un test qui vaut ce qu'il vaut j'ai visité l'URL http://www.fckeditor.net/demo, et l'éditeur prend bien 5 secondes à être utilisable, pour wymeditor cela m'a semblé prendre quelques centaines de millisecondes, en tout cas moins d'une seconde (pour info test réalisé sous firefox 3 en environnement *nix, sur une machine récente, au plus 5 ans).
Certains diront que FCKeditor a plus de fonctionnalités, ok, mais il en a aussi en moins et je parle juste de mon cas, et de certains projets où FCKeditor était un peu overkill et posait des contraintes que wymeditor m'a épargnées.
On 2008-12-16, Pierre Goiffon <pgoiffon@free.fr.invalid> wrote:
Devx a déjà parlé de "gros lourds" à propos de FCK et TinyMCE et j'avais
déjà demandé des précisions, je fais donc la même chose suite à votre
message ? UN poil trop lourd, qu'est-ce que ça veut dire dans les détails ?
Tout ceci est relatif (mon jugement), mais par exemple si on compare
les contenus des tarballs de FCKeditor et wymeditor, en supprimant
seulement les exemples :
FCKeditor_2.6.3.tar.gz
$ du -hs fckeditor
5.0M fckeditor
$ find fckeditor -type f | wc -l
477
wymeditor-0.5-beta-2.tar.gz
$ du -hs wymeditor
700K wymeditor
$ find wymeditor -type f | wc -l
72
Je sais que pour FCKeditor on peut pousser le ménage bien plus loin,
mais justement le faire à chaque release est pénible.
En ce qui concerne FCKeditor, il est souvent *plus gros* que les
projets auxquels je le greffe. De plus à l'usage (côté navigateur), je
le trouve assez long à se charger, je viens de faire un test qui vaut ce
qu'il vaut j'ai visité l'URL http://www.fckeditor.net/demo, et l'éditeur
prend bien 5 secondes à être utilisable, pour wymeditor cela m'a semblé
prendre quelques centaines de millisecondes, en tout cas moins d'une
seconde (pour info test réalisé sous firefox 3 en environnement *nix,
sur une machine récente, au plus 5 ans).
Certains diront que FCKeditor a plus de fonctionnalités, ok, mais il
en a aussi en moins et je parle juste de mon cas, et de certains projets
où FCKeditor était un peu overkill et posait des contraintes que
wymeditor m'a épargnées.
Devx a déjà parlé de "gros lourds" à propos de FCK et TinyMCE et j'avais déjà demandé des précisions, je fais donc la même chose suite à votre message ? UN poil trop lourd, qu'est-ce que ça veut dire dans les détails ?
Tout ceci est relatif (mon jugement), mais par exemple si on compare les contenus des tarballs de FCKeditor et wymeditor, en supprimant seulement les exemples :
FCKeditor_2.6.3.tar.gz
$ du -hs fckeditor 5.0M fckeditor $ find fckeditor -type f | wc -l 477
wymeditor-0.5-beta-2.tar.gz
$ du -hs wymeditor 700K wymeditor $ find wymeditor -type f | wc -l 72
Je sais que pour FCKeditor on peut pousser le ménage bien plus loin, mais justement le faire à chaque release est pénible.
En ce qui concerne FCKeditor, il est souvent *plus gros* que les projets auxquels je le greffe. De plus à l'usage (côté navigateur), je le trouve assez long à se charger, je viens de faire un test qui vaut ce qu'il vaut j'ai visité l'URL http://www.fckeditor.net/demo, et l'éditeur prend bien 5 secondes à être utilisable, pour wymeditor cela m'a semblé prendre quelques centaines de millisecondes, en tout cas moins d'une seconde (pour info test réalisé sous firefox 3 en environnement *nix, sur une machine récente, au plus 5 ans).
Certains diront que FCKeditor a plus de fonctionnalités, ok, mais il en a aussi en moins et je parle juste de mon cas, et de certains projets où FCKeditor était un peu overkill et posait des contraintes que wymeditor m'a épargnées.
Laurent vilday
TJ :
Pierre Goiffon :
Devx a déjà parlé de "gros lourds" à propos de FCK et TinyMCE et j'avais déjà demandé des précisions, je fais donc la même chose suite à votre message ? UN poil trop lourd, qu'est-ce que ça veut dire dans les détails ?
Tout ceci est relatif (mon jugement), mais par exemple si on compare les contenus des tarballs de FCKeditor et wymeditor, en supprimant seulement les exemples :
FCKeditor est un standalone (tout comme Xhina par exemple que je connais un peu plus), ce que n'est pas wymeditor puisqu'il est *dépendant* de jQuery.
<http://trac.wymeditor.org/trac/wiki/0.5/Integration> "The 'wymeditor' folder and jQuery JS file must be accessible from your web page"
Pas évident de les comparer, et sur quoi ? - facilité/difficulté d'intégration ? - poids ? - qualité du code ? - dépendances ? - documentations ? - features ? - configurations ? - temps de chargement ? - temps d'initialisation sur le client ? - qualité du résultat HTML/XHTML/BBCode/etc. demandé - accessibilité ? - respect des standards ? - besoin cross-browser ? Jusqu'à quel point ? - etc.
Comme toujours quoi tout est dépendant des choix effectués, du besoin, du contexte, etc.
Je sais que pour FCKeditor on peut pousser le ménage bien plus loin, mais justement le faire à chaque release est pénible.
Que ce soit l'un, l'autre ou n'importe quel cousin, faut toujours passer par du nettoyage de toute façon. Non pas que je recommande ou déconseille FCKeditor, je ne m'y intéresse pas, mais bon quel que ce soit celui choisi au final l'étape d'intégration est obligatoirement assortie d'un nettoyage intégral. Je ne pense pas qu'il faille baser son choix uniquement sur le travail de nettoyage à effectuer.
le trouve assez long à se charger, je viens de faire un test qui vaut ce qu'il vaut j'ai visité l'URL http://www.fckeditor.net/demo, et l'éditeur prend bien 5 secondes à être utilisable,
Hors cache mais surout "Full Featured".
Dès que ça passe dans le cache, c'est plus du tout 5 secondes.
Un éditeur WYSIWYG est, IMO of course, rarement utilisé sur un front office, c'est plutôt orienté back et CMS. Par conséquent c'est la plupart du temps dans le cache.
pour wymeditor
Quel exemple ?
Le "Basic Integration" ? <http://files.wymeditor.org/wymeditor/trunk/src/examples/01-basic.html>
OOps, pas de "full" pour wymeditor et pas de "basic" pour FCKeditor, pas facile de comparer.
De toute façon, ça se résume en 2 mots : "Besoin" et "Contexte" !
-- laurent
TJ :
Pierre Goiffon :
Devx a déjà parlé de "gros lourds" à propos de FCK et TinyMCE et j'avais
déjà demandé des précisions, je fais donc la même chose suite à votre
message ? UN poil trop lourd, qu'est-ce que ça veut dire dans les détails ?
Tout ceci est relatif (mon jugement), mais par exemple si on compare
les contenus des tarballs de FCKeditor et wymeditor, en supprimant
seulement les exemples :
FCKeditor est un standalone (tout comme Xhina par exemple que je connais
un peu plus), ce que n'est pas wymeditor puisqu'il est *dépendant* de
jQuery.
<http://trac.wymeditor.org/trac/wiki/0.5/Integration>
"The 'wymeditor' folder and jQuery JS file must be accessible from your
web page"
Pas évident de les comparer, et sur quoi ?
- facilité/difficulté d'intégration ?
- poids ?
- qualité du code ?
- dépendances ?
- documentations ?
- features ?
- configurations ?
- temps de chargement ?
- temps d'initialisation sur le client ?
- qualité du résultat HTML/XHTML/BBCode/etc. demandé
- accessibilité ?
- respect des standards ?
- besoin cross-browser ? Jusqu'à quel point ?
- etc.
Comme toujours quoi tout est dépendant des choix effectués, du besoin,
du contexte, etc.
Je sais que pour FCKeditor on peut pousser le ménage bien plus loin,
mais justement le faire à chaque release est pénible.
Que ce soit l'un, l'autre ou n'importe quel cousin, faut toujours passer
par du nettoyage de toute façon. Non pas que je recommande ou
déconseille FCKeditor, je ne m'y intéresse pas, mais bon quel que ce
soit celui choisi au final l'étape d'intégration est obligatoirement
assortie d'un nettoyage intégral. Je ne pense pas qu'il faille baser son
choix uniquement sur le travail de nettoyage à effectuer.
le trouve assez long à se charger, je viens de faire un test qui vaut ce
qu'il vaut j'ai visité l'URL http://www.fckeditor.net/demo, et l'éditeur
prend bien 5 secondes à être utilisable,
Hors cache mais surout "Full Featured".
Dès que ça passe dans le cache, c'est plus du tout 5 secondes.
Un éditeur WYSIWYG est, IMO of course, rarement utilisé sur un front
office, c'est plutôt orienté back et CMS. Par conséquent c'est la
plupart du temps dans le cache.
pour wymeditor
Quel exemple ?
Le "Basic Integration" ?
<http://files.wymeditor.org/wymeditor/trunk/src/examples/01-basic.html>
OOps, pas de "full" pour wymeditor et pas de "basic" pour FCKeditor, pas
facile de comparer.
De toute façon, ça se résume en 2 mots : "Besoin" et "Contexte" !
Devx a déjà parlé de "gros lourds" à propos de FCK et TinyMCE et j'avais déjà demandé des précisions, je fais donc la même chose suite à votre message ? UN poil trop lourd, qu'est-ce que ça veut dire dans les détails ?
Tout ceci est relatif (mon jugement), mais par exemple si on compare les contenus des tarballs de FCKeditor et wymeditor, en supprimant seulement les exemples :
FCKeditor est un standalone (tout comme Xhina par exemple que je connais un peu plus), ce que n'est pas wymeditor puisqu'il est *dépendant* de jQuery.
<http://trac.wymeditor.org/trac/wiki/0.5/Integration> "The 'wymeditor' folder and jQuery JS file must be accessible from your web page"
Pas évident de les comparer, et sur quoi ? - facilité/difficulté d'intégration ? - poids ? - qualité du code ? - dépendances ? - documentations ? - features ? - configurations ? - temps de chargement ? - temps d'initialisation sur le client ? - qualité du résultat HTML/XHTML/BBCode/etc. demandé - accessibilité ? - respect des standards ? - besoin cross-browser ? Jusqu'à quel point ? - etc.
Comme toujours quoi tout est dépendant des choix effectués, du besoin, du contexte, etc.
Je sais que pour FCKeditor on peut pousser le ménage bien plus loin, mais justement le faire à chaque release est pénible.
Que ce soit l'un, l'autre ou n'importe quel cousin, faut toujours passer par du nettoyage de toute façon. Non pas que je recommande ou déconseille FCKeditor, je ne m'y intéresse pas, mais bon quel que ce soit celui choisi au final l'étape d'intégration est obligatoirement assortie d'un nettoyage intégral. Je ne pense pas qu'il faille baser son choix uniquement sur le travail de nettoyage à effectuer.
le trouve assez long à se charger, je viens de faire un test qui vaut ce qu'il vaut j'ai visité l'URL http://www.fckeditor.net/demo, et l'éditeur prend bien 5 secondes à être utilisable,
Hors cache mais surout "Full Featured".
Dès que ça passe dans le cache, c'est plus du tout 5 secondes.
Un éditeur WYSIWYG est, IMO of course, rarement utilisé sur un front office, c'est plutôt orienté back et CMS. Par conséquent c'est la plupart du temps dans le cache.
pour wymeditor
Quel exemple ?
Le "Basic Integration" ? <http://files.wymeditor.org/wymeditor/trunk/src/examples/01-basic.html>
OOps, pas de "full" pour wymeditor et pas de "basic" pour FCKeditor, pas facile de comparer.
De toute façon, ça se résume en 2 mots : "Besoin" et "Contexte" !
-- laurent
davel_x
Pierre Goiffon a écrit :
davel_x wrote:
Pour les gros lourds (mais alors vraiment lourds !) tu as ça : http://www.fckeditor.net/ http://tinymce.moxiecode.com/
J'allais répondre par ces deux : ce sont les 2 produits les plus universellement utilisés à mon sens aujourd'hui. Pourriez-vous préciser le "vraiment très lourds" ?
(note: je parle surtout de TinyMce que je connais le mieux) Je parlais notamment du point de vue chargement pour l'utilisateur, même relativement bien configuré, d'ailleurs SAM l'a aussi fait remarquer dans un des message de la discussion. Mais comme je les utilise souvent (non, réflexion faite, tout le temps !) pour des back-offices de sociétés qui sont en haut débit ce n'est pas grave. Ensuite au niveau poids de la somme des fichiers, pour peu qu'on ait pas fait le ménage ou bien qu'on utilise tous les plugins, ça monte assez vite (avec les fichiers de traduction :)) ça ne pose pas de problèmes dans la majorité des cas mais parfois, lorsqu'il faut livrer par FTP tout le site à chaque mise à jour du moindre fichier (ça ne m'est pas arrivé souvent mais c'est arrivé une fois) c'est un petit peu lourd. De la même manière pour effacer le répertoire TinyMce d'un serveur FTP il faut compter un bon moment devant la profusion de fichiers. Enfin ces scripts sont hyper complets donc pour les configurer il faut y passer du temps et découvrir comment lui faire faire exactement ce qu'on veut ni plus, ni plus.
Si je me souviens bien de la demande initiale c'était surtout un script pour mettre du gras, ou un style bien spécifique sur tout ou partie d'un texte, dans ce cas ces scripts sont peut-être un peu comme les fameux chars d'assaut pour tuer des mouches. :) voilà ce que j'entendais par très lourds. Ce qui ne m'empêche pas d'utiliser TinyMce très régulièrement.
-- **davel** http://www.davel.fr/blog/
Pierre Goiffon a écrit :
davel_x wrote:
Pour les gros lourds (mais alors vraiment lourds !) tu as ça :
http://www.fckeditor.net/
http://tinymce.moxiecode.com/
J'allais répondre par ces deux : ce sont les 2 produits les plus
universellement utilisés à mon sens aujourd'hui.
Pourriez-vous préciser le "vraiment très lourds" ?
(note: je parle surtout de TinyMce que je connais le mieux)
Je parlais notamment du point de vue chargement pour l'utilisateur, même
relativement bien configuré, d'ailleurs SAM l'a aussi fait remarquer
dans un des message de la discussion. Mais comme je les utilise souvent
(non, réflexion faite, tout le temps !) pour des back-offices de
sociétés qui sont en haut débit ce n'est pas grave.
Ensuite au niveau poids de la somme des fichiers, pour peu qu'on ait pas
fait le ménage ou bien qu'on utilise tous les plugins, ça monte assez
vite (avec les fichiers de traduction :)) ça ne pose pas de problèmes
dans la majorité des cas mais parfois, lorsqu'il faut livrer par FTP
tout le site à chaque mise à jour du moindre fichier (ça ne m'est pas
arrivé souvent mais c'est arrivé une fois) c'est un petit peu lourd. De
la même manière pour effacer le répertoire TinyMce d'un serveur FTP il
faut compter un bon moment devant la profusion de fichiers.
Enfin ces scripts sont hyper complets donc pour les configurer il faut y
passer du temps et découvrir comment lui faire faire exactement ce qu'on
veut ni plus, ni plus.
Si je me souviens bien de la demande initiale c'était surtout un script
pour mettre du gras, ou un style bien spécifique sur tout ou partie d'un
texte, dans ce cas ces scripts sont peut-être un peu comme les fameux
chars d'assaut pour tuer des mouches. :) voilà ce que j'entendais par
très lourds.
Ce qui ne m'empêche pas d'utiliser TinyMce très régulièrement.
Pour les gros lourds (mais alors vraiment lourds !) tu as ça : http://www.fckeditor.net/ http://tinymce.moxiecode.com/
J'allais répondre par ces deux : ce sont les 2 produits les plus universellement utilisés à mon sens aujourd'hui. Pourriez-vous préciser le "vraiment très lourds" ?
(note: je parle surtout de TinyMce que je connais le mieux) Je parlais notamment du point de vue chargement pour l'utilisateur, même relativement bien configuré, d'ailleurs SAM l'a aussi fait remarquer dans un des message de la discussion. Mais comme je les utilise souvent (non, réflexion faite, tout le temps !) pour des back-offices de sociétés qui sont en haut débit ce n'est pas grave. Ensuite au niveau poids de la somme des fichiers, pour peu qu'on ait pas fait le ménage ou bien qu'on utilise tous les plugins, ça monte assez vite (avec les fichiers de traduction :)) ça ne pose pas de problèmes dans la majorité des cas mais parfois, lorsqu'il faut livrer par FTP tout le site à chaque mise à jour du moindre fichier (ça ne m'est pas arrivé souvent mais c'est arrivé une fois) c'est un petit peu lourd. De la même manière pour effacer le répertoire TinyMce d'un serveur FTP il faut compter un bon moment devant la profusion de fichiers. Enfin ces scripts sont hyper complets donc pour les configurer il faut y passer du temps et découvrir comment lui faire faire exactement ce qu'on veut ni plus, ni plus.
Si je me souviens bien de la demande initiale c'était surtout un script pour mettre du gras, ou un style bien spécifique sur tout ou partie d'un texte, dans ce cas ces scripts sont peut-être un peu comme les fameux chars d'assaut pour tuer des mouches. :) voilà ce que j'entendais par très lourds. Ce qui ne m'empêche pas d'utiliser TinyMce très régulièrement.
-- **davel** http://www.davel.fr/blog/
TJ
On 2008-12-16, Laurent vilday wrote:
TJ :
Tout ceci est relatif (mon jugement), mais par exemple si on compare les contenus des tarballs de FCKeditor et wymeditor, en supprimant seulement les exemples :
FCKeditor est un standalone (tout comme Xhina par exemple que je connais un peu plus), ce que n'est pas wymeditor puisqu'il est *dépendant* de jQuery.
Dans mon cas (et je parle uniquement du miens !) j'utilisais déjà jQuery, je ne l'ai pas précisé mais comme bien d'autres aspects que j'ai évité pour ne pas rallonger le post. Mais je suis d'accord qu'en cas de non-utilisation de jQuery c'est un aspect supplémentaire qui pèse dans la balance.
<http://trac.wymeditor.org/trac/wiki/0.5/Integration> "The 'wymeditor' folder and jQuery JS file must be accessible from your web page"
Pas évident de les comparer, et sur quoi ? - facilité/difficulté d'intégration ?
[...]
- etc.
Comme toujours quoi tout est dépendant des choix effectués, du besoin, du contexte, etc.
De toute façon, ça se résume en 2 mots : "Besoin" et "Contexte" !
Nous sommes tout à fait d'accord, j'ai juste exposé (très succinctement) les raisons principales qui m'ont poussées à ce switch. De toute façon, selon moi, wymeditor et FCKeditor sont à la base des projets avec une approche différente du besoin, voire répondent à des besoins différents.
On 2008-12-16, Laurent vilday <mokhet@mokhet.com> wrote:
TJ :
Tout ceci est relatif (mon jugement), mais par exemple si on compare
les contenus des tarballs de FCKeditor et wymeditor, en supprimant
seulement les exemples :
FCKeditor est un standalone (tout comme Xhina par exemple que je connais
un peu plus), ce que n'est pas wymeditor puisqu'il est *dépendant* de
jQuery.
Dans mon cas (et je parle uniquement du miens !) j'utilisais déjà
jQuery, je ne l'ai pas précisé mais comme bien d'autres aspects que j'ai
évité pour ne pas rallonger le post. Mais je suis d'accord qu'en cas de
non-utilisation de jQuery c'est un aspect supplémentaire qui pèse dans
la balance.
<http://trac.wymeditor.org/trac/wiki/0.5/Integration>
"The 'wymeditor' folder and jQuery JS file must be accessible from your
web page"
Pas évident de les comparer, et sur quoi ?
- facilité/difficulté d'intégration ?
[...]
- etc.
Comme toujours quoi tout est dépendant des choix effectués, du besoin,
du contexte, etc.
De toute façon, ça se résume en 2 mots : "Besoin" et "Contexte" !
Nous sommes tout à fait d'accord, j'ai juste exposé (très
succinctement) les raisons principales qui m'ont poussées à ce switch.
De toute façon, selon moi, wymeditor et FCKeditor sont à la base des
projets avec une approche différente du besoin, voire répondent à des
besoins différents.
Tout ceci est relatif (mon jugement), mais par exemple si on compare les contenus des tarballs de FCKeditor et wymeditor, en supprimant seulement les exemples :
FCKeditor est un standalone (tout comme Xhina par exemple que je connais un peu plus), ce que n'est pas wymeditor puisqu'il est *dépendant* de jQuery.
Dans mon cas (et je parle uniquement du miens !) j'utilisais déjà jQuery, je ne l'ai pas précisé mais comme bien d'autres aspects que j'ai évité pour ne pas rallonger le post. Mais je suis d'accord qu'en cas de non-utilisation de jQuery c'est un aspect supplémentaire qui pèse dans la balance.
<http://trac.wymeditor.org/trac/wiki/0.5/Integration> "The 'wymeditor' folder and jQuery JS file must be accessible from your web page"
Pas évident de les comparer, et sur quoi ? - facilité/difficulté d'intégration ?
[...]
- etc.
Comme toujours quoi tout est dépendant des choix effectués, du besoin, du contexte, etc.
De toute façon, ça se résume en 2 mots : "Besoin" et "Contexte" !
Nous sommes tout à fait d'accord, j'ai juste exposé (très succinctement) les raisons principales qui m'ont poussées à ce switch. De toute façon, selon moi, wymeditor et FCKeditor sont à la base des projets avec une approche différente du besoin, voire répondent à des besoins différents.
Laurent vilday
TJ :
De toute façon, selon moi, wymeditor et FCKeditor sont à la base des projets avec une approche différente du besoin, voire répondent à des besoins différents.
Oui, exactement ce que j'essayais maladroitement de dire :)
-- laurent
TJ :
De toute façon, selon moi, wymeditor et FCKeditor sont à la base des
projets avec une approche différente du besoin, voire répondent à des
besoins différents.
Oui, exactement ce que j'essayais maladroitement de dire :)
De toute façon, selon moi, wymeditor et FCKeditor sont à la base des projets avec une approche différente du besoin, voire répondent à des besoins différents.
Oui, exactement ce que j'essayais maladroitement de dire :)
-- laurent
Pierre Goiffon
Laurent vilday wrote:
Tout ceci est relatif (mon jugement), mais par exemple si on compare les contenus des tarballs de FCKeditor et wymeditor, en supprimant seulement les exemples :
FCKeditor est un standalone (tout comme Xhina par exemple que je connais un peu plus), ce que n'est pas wymeditor puisqu'il est *dépendant* de jQuery.
Ha oui tout de suite :)
Je viens de regarder un peu, j'ai un peu plus de 160Ko appelés sur un FCK 2.3 intégré à une application (où le "ménage" avait été poussé en avant...). Mais toutes ces ressources sont cachables et gzipables... Je ne sais pas ce que ça donne sur les dernières versions ?
le trouve assez long à se charger, je viens de faire un test qui vaut ce qu'il vaut j'ai visité l'URL http://www.fckeditor.net/demo, et l'éditeur prend bien 5 secondes à être utilisable,
Hors cache mais surout "Full Featured".
Dès que ça passe dans le cache, c'est plus du tout 5 secondes.
Mhh... Sur la vieille version dont je parlais plus haut, c'était un vrai problème ! Même avec toutes les ressources disponibles, sur une machine "standard" on avait un certain temps avant que l'éditeur n'apparaisse ! Mais c'est vrai que le rendu de la page n'était pas vraiment optimisé à cet endroit... peut être lié !
Cependant un dev chez nous a fait un essai d'intégration d'une version plus récente de fck dans cette appli et les temps de chargement étaient considérablement réduis visiblement...
Laurent vilday wrote:
Tout ceci est relatif (mon jugement), mais par exemple si on compare
les contenus des tarballs de FCKeditor et wymeditor, en supprimant
seulement les exemples :
FCKeditor est un standalone (tout comme Xhina par exemple que je connais
un peu plus), ce que n'est pas wymeditor puisqu'il est *dépendant* de
jQuery.
Ha oui tout de suite :)
Je viens de regarder un peu, j'ai un peu plus de 160Ko appelés sur un
FCK 2.3 intégré à une application (où le "ménage" avait été poussé en
avant...). Mais toutes ces ressources sont cachables et gzipables...
Je ne sais pas ce que ça donne sur les dernières versions ?
le trouve assez long à se charger, je viens de faire un test qui vaut ce
qu'il vaut j'ai visité l'URL http://www.fckeditor.net/demo, et l'éditeur
prend bien 5 secondes à être utilisable,
Hors cache mais surout "Full Featured".
Dès que ça passe dans le cache, c'est plus du tout 5 secondes.
Mhh... Sur la vieille version dont je parlais plus haut, c'était un vrai
problème ! Même avec toutes les ressources disponibles, sur une machine
"standard" on avait un certain temps avant que l'éditeur n'apparaisse !
Mais c'est vrai que le rendu de la page n'était pas vraiment optimisé à
cet endroit... peut être lié !
Cependant un dev chez nous a fait un essai d'intégration d'une version
plus récente de fck dans cette appli et les temps de chargement étaient
considérablement réduis visiblement...
Tout ceci est relatif (mon jugement), mais par exemple si on compare les contenus des tarballs de FCKeditor et wymeditor, en supprimant seulement les exemples :
FCKeditor est un standalone (tout comme Xhina par exemple que je connais un peu plus), ce que n'est pas wymeditor puisqu'il est *dépendant* de jQuery.
Ha oui tout de suite :)
Je viens de regarder un peu, j'ai un peu plus de 160Ko appelés sur un FCK 2.3 intégré à une application (où le "ménage" avait été poussé en avant...). Mais toutes ces ressources sont cachables et gzipables... Je ne sais pas ce que ça donne sur les dernières versions ?
le trouve assez long à se charger, je viens de faire un test qui vaut ce qu'il vaut j'ai visité l'URL http://www.fckeditor.net/demo, et l'éditeur prend bien 5 secondes à être utilisable,
Hors cache mais surout "Full Featured".
Dès que ça passe dans le cache, c'est plus du tout 5 secondes.
Mhh... Sur la vieille version dont je parlais plus haut, c'était un vrai problème ! Même avec toutes les ressources disponibles, sur une machine "standard" on avait un certain temps avant que l'éditeur n'apparaisse ! Mais c'est vrai que le rendu de la page n'était pas vraiment optimisé à cet endroit... peut être lié !
Cependant un dev chez nous a fait un essai d'intégration d'une version plus récente de fck dans cette appli et les temps de chargement étaient considérablement réduis visiblement...
