Le choix de mon parser CSS (2)

Voila quelques semaines, j’avais décidé d’implémenter les CSS dans le framework Swinger. Je savais que je me lançais dans une tâche ardue. Je m’étais fixé comme objectif de livrer une version ce mois de juin.

Avec l’arrivée du mois de juillet, je dois dire que le choix du parser Batik est un échec, je ne serai pas en mesure de tenir les délais. La raison est que je me suis rendu compte à l’intégration que mon modèle ne collait pas avec celui de Batik. Je m’attendais à un parser plus facilement exploitable, en fait il a été développé dans une philosophie assez rigide et difficile à cerner car mal documentée.

Mais la vraie raison de cet échec est que je ne me suis pas donné suffisamment de temps pour étudier cette api. La conséquence est que je me retrouve confronté à une impasse. Je n’ai que deux options qui s’offrent à moi. Soit détricotter mon code pour me conformer aux attendus de Batik, soit abandonner cette api et développer mon propre parser.

C’est la deuxième option que je choisi. Pour plusieurs raisons. D’abord cela m’ennui de renoncer à plusieurs semaines de travail. Le code que j’ai produit est loin d’être parfait et devrait pêcher par manque de performance dans le cas de CSS très complexes. Mais il est bien à adapté à l’architecture de Swinger qui repose sur des Accessors qui attendent des chaînes de caractères pour l’initialisation des attributs.

L’autre raison qui me trotte dans la tête depuis deux ou trois semaines est que je souhaite que l’api Swinger puisse être intégrée comme bundle Osgi. Or dans ce cas, les librairies externes sont un handicap si elles ne sont pas elles-même livrées en tant que bundles.

Pour ces raisons, je n’ai pas de regret à me séparer de Batik. La conséquence est que cela va retarder sensiblement la livraison d’une version supportant les CSS. Du coup, je vais livrer dans les semaines qui viennent une version intermédiaire qui permettra de choisir son layout. C’était en effet le point de départ de ma réflexion sur la configuration des attributs apparents.

Je ne suis pas en mesure de fixer de date quand au support des CSS. Ce qui est certain est que ce support sera partiel et portera sur quelques attributs seulement. Les aspects les plus délicats, comme le positionnement relatif des composants, sera reporté à une version ultérieure. En tout état de cause, le support de CSS ne sera jamais complet car la philosophie de l’api swing ne permet pas par exemple de gérer le texte de la même manière qu’en html.

Sans fournir de date buttoir en raison des beaux jours dont je profite autant que possible, j’espère néanmoins finir mon parser avant la fin du mois de juillet.

Je vous tiendrai au courant de l’arrivée de la prochaine release dans les semaines à venir qui supportera la personnalisation des layouts.

Publicités

0 Responses to “Le choix de mon parser CSS (2)”



  1. Laisser un commentaire

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s





%d blogueurs aiment cette page :