Une fenetre permet de gérer les working sets

Un wizard permet de sélectionner les ressources du set.

Un wizard permet de sélectionner les ressources du set.

Ce set peut être utilisé dans différentes vues d’Eclipse : dans la recherche, dans l’environnement de synchronisation ou dans le navigateur.

Pour ma part, j’ai plusieurs working set, un pour les éléments que je souhaite avoir dans ma recherche (excluant donc les fichiers compilés, des projets sur lesquels je ne travaille pas, ou les fichiers de la maquette), un set pour ce que j’update chaque jour et un set pour ce que j’update plus rarement.

• request_locale (passé en get dans l’url)
• en session (WW_TRANS_I18N_LOCALE)
• dans les paramètres du navigateur (request.getLocale)

Ce comportement est celui de l’interceptor par defaut de Struts, mais il peut etre utile de le surcharger en rajoutant la recherche de la locale dans les paramètres de l’appli (accès en base ou dans des fichiers de conf).

Widget factory

Tout les widgets jQuery UI sont crées en passant par la méthode $.widget(‘ui.widgetname’, prototype); (jQuery UI Widget Factory).

Lorsque un widget est crée, la factory créée pour vous le namespace adéquat, ici $.ui (qui existe déjà, mais vous n’y êtes pas restreint), une nouvelle classe $.ui.widgetname, ainsi qu’un helper au niveau du namespace de jquery répondant au nom de votre widget. Ici, $.fn.widgetname permettant l’intialisation et la manipulation du widget par l’intermédiaire de $(selector).widgetname(options);

Je ne m’étendrais pas plus sur le sujet puisque cet article se borne à présenter la mise en place d’un héritage simple de widgets existants. Le lien sur le wiki linké plus haut est une très bonne source d’information.

Gimme your prototype

Comme expliqué un peu plus haut, les widgets crées via la widget factory fournissent ce qu’on appelle un prototype. C’est de ce prototype dont nous partirons pour créer notre custom Dialog widget.

$.widget("wt.myDialog", $.extend({}, $.ui.dialog.prototype, {
	_init: function(){
		console.log("I am a extended widget!");

		// Don't forget to call the super one
		return $.ui.dialog.prototype._init.apply(this, arguments);
	}
}));

Nous aurons aussi besoin de copier l’intégralité de la configuration par défaut du widget parent, habituellement disponible via $.namespace.widgetname.defaults:

// You also have to copy the whole defaults widget properties
// You may want to add your owns too
$.wt.myDialog.defaults = $.extend({}, $.ui.dialog.defaults, {
	foo: "foo",
	bar: function(){},
	whatever: true
});

Ce faisant, vous n’avez plus qu’à tester le code:

$("<div />").myDialog();

Et l’on peut voir notre tant attendu log lors de l’initialisation alors qu’une dialog apparaît à l’écran. Avec toutes les fonctionnalités du widget de base Pretty handy, right?

On peut trouver beaucoup à redire sur cette implémentation. On pourrait grandement l’améliorer en manipulant plus finement le prototype comme expliqué dans le post sur Hacking at 0300. J’aime beaucoup l’effort pour promouvoir une _super method, basé sur l’implémentation de jresig (elle même basé sur celle de Dean Edwards, enfin bref…).

Do my stuff!

Vous avez pu en voir un bref exemple plus haut sur la méthode init, surcharger une méthod du widget revient à redéfinir une méthode du widget parent dans votre propre ptototype en veillant à appeller la super method:

open: function(){
	console.info("show:", this, arguments);
        // Does the same thing than this._super but is more verbose.
	$.ui.dialog.prototype.open.apply(this, arguments);
}

Sources utilisés dans cet article: http://github.com/MkLabs/snippets/

Ressources

• http://jqueryui.com/docs/Developer_Guide
• http://jqueryui.pbworks.com/Widget-factory
• http://bililite.com/blog/extending-jquery-ui-widgets/

What Git is, why you would want to use it and where to get it and learn about it.

Un petit bout de temps déjà que j’en entends parler sans encore avoir pu prendre le temps de jouer avec l’outil. La plupart des projets open source les plus connus sont passés sur github (un googlecode pour git, avec une petite touche de social coding de plus en plus à la mode… Un googlecode puissance 10 quoi ).

Et bien sûr pour éviter de se taper les commandes git pour manipuler le versioning de nos projets, voici un plugin Eclipse trés bien fait: http://www.eclipse.org/egit/

Le User Guide disponible ici est également hyper bien foutu et vous permettra de vous mettre en selle en moins de temps qu’il n’en faut pour le dire.

Je pense faire un second post une fois un peu plus familiarisé avec l’outil, mais, à première vue, je suis tout à fait conquis ;

<package name="default" extends="struts-default">
   <interceptors>
       <interceptor name="timer" class=".."/>
       <interceptor name="logger" class=".."/>
   </interceptors>

   <action name="login"
      class="tutorial.Login">
        <interceptor-ref name="timer"/>
        <interceptor-ref name="logger"/>
         <result name="input">login.jsp</result>
         <result name="success"
            type="redirect-action">/secure/home</result>
   </action>
</package>

Mais le plus intéressant est d’appliquer une pile d’interceptor à toutes les actions de l’application. Pour cela, on va définir un interceptor stack, toujours dans struts.xml puis appeler cette référence dans toutes les actions :

<package name="default" extends="struts-default">
   <interceptors>
        <interceptor name="timer" class=".."/>
        <interceptor name="logger" class=".."/>
        <interceptor-stack name="myStack">
           <interceptor-ref name="timer"/>
           <interceptor-ref name="logger"/>
        </interceptor-stack>
    </interceptors>

<action name="login"
     class="tutorial.Login">
         <interceptor-ref name="myStack"/>
         <result name="input">login.jsp</result>
         <result name="success"
             type="redirect-action">/secure/home</result>
</action>
</package>

Voila pour le moment, j’envisage de présenter les interceptors les plus utiles, de présenter le développement d’un interceptor maison et la configuration plus fine des interceptors (lancement pendant ou après une action).

Sitographie :

• http://struts.apache.org/2.x/docs/interceptors.html

Tout d’abord, qu’est ce que le proxy pattern? Basiquement, un proxy est une ‘étape’ (comprenez composant logiciel) supplémentaire auquel on se plug pour accéder à une autre fonctionnalité. En JS, cela se traduit par la possibilité d’ajouter du code avant ou aprés l’exécution d’une méthode / fonction donnée.

Particulièrement utile par exemple quand vous voulez logguer l’appel à une méthode automatiquement. Imaginons que vous utilisiez jQuery et le binding d’évenement fourni par cette fabuleuse librairie. Tous les helpers d’évènements fournis par jQuery utilisent en interne la methode $.fn.bind ($.fn est un shortcut du prototype de jQuery, $.fn = $.prototype = jQuery.fn = jQuery.prototype).

En utilisant ce petit bout de code, vous serez capable d’ajouter du code avant ou aprés l’execution d’une méthode donnée:

// Hold a reference to the regular bind method.
var p = $.fn.bind;

// Override it
$.fn.bind = function(){
	console.log("$.fn.bind before: ", this, arguments);

        // Make sure to call our proxy with correct context / arguments
	return p.apply(this, arguments);
};

Outre le besoin de log, cette technique est trés utile pour customiser la logique d’une méthode sans en toucher le code. Dans mon projet actuel, nous avons appliqué ce pattern au besoin de feedback utilisateur dans le contexte de requete AJAX. Le problème est bien connu: quand un utilisateur entreprend une action qui déclenche une requête asynchrone, nativement, rien n’indique à l’utilisteur que quelque chose se passe.

Nous ne voulions définitivement pas que chaque développeur qui fasse l’usage d’une requête AJAX (que ce soit rechargement partiel d’une page, lancement d’une recherche, loading d’une boîte de dialogue) ait à gérer l’affichage à l’utilisateur d’un gif de type loading ou un texte du genre « En chargement ».  Pour ce faire, nous avons appliqué ce pattern au méthodes $.fn.ajax, $.fn.ajaxSubmit (relatif au pulgin ajaxForm, nous n’utilisons malheuresement que cette méthode, jamais la méthode native $.fn.ajaxFom).

Exemple pour $.fn.ajax: Typiquement, pour gérer l’affichage d’un « loading » au déclenchement d’une reqûete AJAX qui rechargera une partie de la page, le plus simple reste d’ajouter un gif ou texte « Chargement » à l’endroit du DOM modifié au retour de notre requête. Le feedback chargement sera automatiquement remplacé par la response du serveur:

// Get $.ajax proxied to perform our specific stuff (loading)
Proxies.ajax = $.ajax;
$.ajax = function(options){
	console.log("$.ajax: ", this, arguments);
	var target = null;
	if(options.target){
		target = $(options.target)
			.empty()
			.append(loadingIcon);
	}
	return Proxies.ajax.apply(this, arguments);
};

<action name="NomDeMonAction" class="ActionClass" method="doPrepareDisplay">
<result name="success" type="tiles">page.tilesDef</result>
</action>

Pour avoir vécu cette situation, ca peut poser un probleme si cette méthode existe pour une action et effectue un traitement qui n’a rien à voir avec notre action concernée.

Morale de l’histoire : pensez toujours à préciser une méthode dans une action Struts, même si elle ne fait rien.

Je suis consultant ingénieur développement Java/J2EE et au fur et à mesure de mes missions, j’engrange des infos et trucs utiles à propos du dev et des outils qu’on utilise.

Ce blog va me permettre de conserver ces trucs et éventuellement de les partager.

Si ca vous est utile aussi, tant mieux …