Copy Page

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.

Chat Log - 2006 01 03 
23:42 - souk 
ben deja, tout ce dont on avait parle:
<ul>
	<li>pas seulement installed/uninstalled, mais aussi deployed et undeployed pour le status des plugin
	<ul>
		<li>uninstalled et installed ne servent a rien comme status en fait, vu qu'un plugin uninstalled n'est ni dans le store ni dans la registry et un plugin installed est un plugin dans le store</li>
		<li>les events/callback en eux memes peuvent être interessants, mais pas le status, de fait</li>
		<li>en revanche, il faut un mechanisme pour stocker le status des plugins qui sont dans le store (deployed/undeployed)</li>
		<li>c'est tout à fait pour ça que j'avais parlé des events deploy/undeploy<img class="emoticon emoticon-wink" data-emoticon-name="wink" border="0" src="/s/en_GB/3278/15/_/images/icons/emoticons/wink.png" alt="(wink)" title="(wink)" /></li>
	</ul>
	</li>
</ul>

<ul>
	<li>il peut y avoir plusieurs type de plugins par registry pour eliminer la necessite d'avoir n registries pour n types de plugins</li>
	<li>gestion des dependances interplugin</li>
	<li>mechanisme d'injection de plugin dans d'autres plugins par annotations =&gt; j'essplique
<blockquote>genre un plugin a besoin d'un autre plugin au moment de son instanciation, on annote un setter de telle facon que la registry peut injecter le plugin voulu</blockquote>
genre: 
@InjectPlugin(family=&quot;truc&quot;,plugin=&quot;bidule&quot;) 
public void setBidule(Bidule bidule){ 
 ... 
}</li>
	<li>revoir toutes les exceptions, leurs constructeurs, voir si on peut pas en passer en unchecked
	<ul>
		<li>moi je dis qu'on peut <a class="confluence-link unresolved" data-content-title="dawa" data-linked-resource-default-alias="dawa" href="#">dawa</a></li>
	</ul>
	</li>
</ul>

23:47 - greg 
je vois pas à quoi va servir l'annotation, l'injection pourrait etre déjà gérée par spring ou pico ou autre

23:49 - souk
<ul>
	<li>l'autowiring a peu de chances de fonctionner s'il y a plein de plugin de meme type</li>
</ul>

23:50 - greg 
ben tu mets une dep sur le type concret

23:51 - souk 
2) je veux pas dependre de spring ou pico ou autre 
 j'essaierai de te trouver un exemple demain

<hr />
Types de plugins:
<ul>
	<li>On a besoin de &quot;metadata&quot; differents pour chaque type de plugin. La solution cra-cra adoptée par Tonic, c'est de passer un Element dom au builder/deployer/whatever. Solution plus propre: modéliser ça dans des beans. . Suis tenté de jeter un oeil à modello (cfr maven2 qui génère ses classes de model depuis un genre d'xsd, ce qui permet aussi de generer de la doc etc...). Ca n'implique pas necessairement une dépendence sur un format xml, mais ça pourrait etre une des possibilités les plus simples pour les users? On pourrait meme probablement générer un xsd qui supporterait tous les types de plugins qu'on fournirait - tout en laissant la possibilité aux users d'utiliser / implementer les types de plugins de leur choix.</li>
</ul>