Julien Carnelos Blog – Archives

Les spammeurs sont plus fort que moi. Pourtant je pensais pouvoir tenir bon grâce à mon spamplemousse pressé. Malheureusement, j’ai beau rajouter des mots interdits, l’imagination sans frontière des spammeurs m’obligent à trouver une autre solution…

J’ai donc cherché un nouveau plugin pour DotClear. Et bien, il faut avouer qu’il n’en existe pas énormement comme filtre anti-spam mais comme il était hors de question d’entamer un développement (apparté : non je rien contre le PHP, d’ailleurs, si vous faites du PHP, vous pouvez suivre ce blog très intéressant Oh My Blog! ), j’ai fini par trouver sur google une solution prête à l’emploi.

Le plugin est donc maintenant mis en place, obligatoire et vous demandera de répondre à une question selon de turing. Le niveau intellectuel demandé pour répondre demandant au moins le QI d’une moule, je fais amplement confiance à mes lecteurs pour résoudre même la plus dure des équations !

Adios Spamos (Pourtant le pauvre il avait l’air souriant…)

Deux mois après la version 1.0 finale, une update majeure est sortie avec la 1.1. La liste des nouveautés est assez impressionnante mais voici les principales compréhensibles pour les non railistes (j’invente ce mot) :

• RJS : Javascript écrit en Ruby. On peut écrire maintenant un code comme :

# Highlight all the DOM elements of class "product"  page.select(".product").each do |element|    element.visual_effect :highlight  end

 # 4 seconds after rendering, set the font-style of all company  # spans inside tds to normal  page.delay(4) do    page.select("td span.company").each do |column|      column.set_style :fontStyle => "normal"    end  end

Ce qui générera le code Javascript correspondant. L’intérêt est de ne pas forcer sur l’apprentissage du Javascript et de continuer à programmer en Ruby même sur le poste client avec une étape intermédiaire d’interprétation du Ruby en JS…

Techniquement assez impressionnant quand même !

• Active Record : C’etait déjà le gros pavé de Rails avec l’intégration du mapping objet-relationnel dans le framework. La couche a donc été amélioré avec des possibilités accrues dans l’association des objets. Je ne rentrerais pas plus dans les détails, n’ayant pas suivi de près.

• Integration Test : Des outils sympathiques ont été ajouté qui permettent d’exécuter des tests d’IHM sur l’application codés en Ruby. Exemple de code :

   def test_signup_new_person      get "/login"      assert_response :success      assert_template "login/index"

     get "/signup"      assert_response :success      assert_template "signup/index"    end

Au passage, si vous suivez un peu le framework Rails, je vous conseille de suivre l’excellent blog Ruby’s Cube qui donne pas mal d’astuces sur Ruby/Rails et en francais pour ne rien gacher !

Via l’article original posté sur le blog Rails qui donne les nouveautés de façon bien plus exhaustive.

Vu sur TechCrunch, le calendrier google pointe le bout de son nez.

Evidemment il brille tellement il est frotté à l’ajax 🙂 .

Vivement l’ouverture d’une open béta. Pour l’instant c’est limité à 200 personnes.

J’inaugure cette catégorie avec ce concept qui parait assez sympathique :

Ce principe de portable transverse n’est pas nouveau mais on peut espérer qu’avec un Windows installé dessus, on pourra plus facilemement bidouiller que sur les autres consoles/PDA portables du marché.

Benjamin, ta PSP peut aller se cacher je crois 😉

Passons maintenant à ce qui nous intéresse le plus, les Framework AJAX pour Java :

• DWR – 1.1 RC1
• AjaxTags – 1.2
• AJAX Toolkit Framework (ATF) Project

DWR (Direct Web Remoting) est donc un framework Ajax spécialisé pour J2EE. Son utilisation coté serveur est donc simplifiée et se traduit par une « installation facile » :

0. Ajouter le dwr.jar dans le projet web dans WEB-INF/lib.

1. Ajouter DWR comme servlet au projet dans le web.xml :

<servlet>    <servlet-name>dwr-invoker</servlet-name>    <display-name>DWR Servlet</display-name>    <description>Direct Web Remoter Servlet</description>    <servlet-class>uk.ltd.getahead.dwr.DWRServlet</servlet-class>    <init-param>      <param-name>debug</param-name>      <param-value>true</param-value>    </init-param>    <init-param>      <param-name>scriptCompressed</param-name>      <param-value>false</param-value>    </init-param>    <load-on-startup>1</load-on-startup>  </servlet>  <servlet-mapping>    <servlet-name>dwr-invoker</servlet-name>    <url-pattern>/dwr/*</url-pattern>  </servlet-mapping>

2. On déclare nos objets Java dans le dwr.xml (qui se situe à coté du web.xml) On peut marquer ces objets avec des propriétés comme par exemple des droits limités d’accès sur les méthodes ou d’autorisation.

Par exemple ici, je déclare un objet JDate qui est une instance de java.util.date :

  <create creator="new" javascript="JDate">      <param name="class" value="java.util.Date"/>      <exclude method="getHours"/>      <auth method="getMinutes" role="admin"/>    </create>

Pour cet objet, j’exclus l’appel à la méthode getHours() et je demande une autorisation pour le getMinutes() .

3. On ajoute dwr sur nos pages web.

 <script src='dwr/engine.js'></script>  <script type='text/javascript' src='/dwr/dwr/interface/JDate.js'></script>

Et c’est tout !

DWR va alors générer dynamiquement du code javascript en fonction de son parametrage et créer des objets javacript reprenant les objets et méthodes Java déclarés. On appele alors de manière transparente un objet distant Java dans notre code Javascript…

De plus, on peut également consulter directement un objet « partagé » sur le client par une url http du style : http://localhost:8080/dwr/dwr/test/JDate

exemple de résultat :

Ce qui est très agréable avec DWR, c’est qu’on écrit pas de javascript supplémentaire technique pour accéder à nos objets. Tout le cablage est réalisé de façon transparente par le framework.

AjaxTags

Il s’agit d’une ancienne librairie qui ne fonctionnait que sous Struts mais qui fonctionne maintenant avec tout container JSP.

L’installation est également aisée :

0. Installation du ajaxtags-1.2.jar et dépendances dans WEB-INF/lib

1. Mise en place du TLD des tags dans le web.xml si la version des JSP est inférieure à 2.0

2. C’est parti ! Par exemple, pour coder un auto-completer, dans notre jsp on va utiliser le tag autocomplete :

<ajax:autocomplete  source="model"  target="make"  baseUrl="${contextPath}/autocomplete.view"  className="autocomplete"  indicator="indicator"  minimumCharacters="1"  parser="new ResponseXmlToHtmlListParser()" />

En paramètre, les champs les plus importants sont le champ source d’auto complétion et l’url / classe Java de la servlet qui pourra être remplacé par une action struts si on souhaite.

Le résultat est une auto complétion qui fonctionne sans soucis 😉

ATF (AJAX Toolkit Framework)

Projet incubateur sur eclipse.org, il possède l’appui d’éditeurs majeurs comme BEA, IBM, Oracle… Ce framework vise à standardiser la syntaxe Ajax et à réaliser un toolkit Ajax sous Eclipse. Projet donc très intéressant. Pour le moment ce projet est disponible sur le site d’IBM. Je le testerai quand il sera téléchargeable sur eclipse.org.

Bilan

Si le besoin est d’ajouter quelques effets graphiques sur un site, Rico ou scriptaculous sont à peu près équivalent et restent simple d’utilisation.

Pour Dojo, je le vois plutôt comme un composant de haut niveau. C’est à dire qu’il soit directement intégré par un framework web et que le développeur l’utilise par ce framework. Cela permettra de simplifier le travail du développeur pour les cas déjà implémentés par le framework tout en lui fournissant une librairie complète si besoin.

Concernant un développement Java, DWR est tout indiqué dans le cas ou il s’agit d’appeler des composants métier directement depuis le navigateur et AjaxTags permet d’accélerer l’intégration de composants prêt à l’emploi. Les deux approches ne sont pas concurrentes mais gare au mélange de trop de frameworks Ajax, donc bien choisir en fonction du besoin…

Pour ATF, je ne me prononce pas, ne l’ayant pas encore testé.