systeme de plugins

[f-r-y]

une idée pour les plugins, qui pourrait faciliter les scenarii: avoir au moins deux classes (je pense a deux types, mais il y en a probablement d'autres intéressants) dont un plug-in pourrait hériter et qui permettrait de gérer des interactions entre les différents plugins de manière transparente:

• "actionneur" ou autre titre du genre: effectue une action (on/off par exemple, ou un setValue de 0 a 1, bref a définir)
• "détecteur" qui renvois une valeur absolue (une température par ex) ou relative (de 0 a 1) comme ça un plug-in tier pourrait jouer un rôle de gestion en interrogeant un "détecteur" et en fonction du résultat assigner une valeur a un "actionneur", en choisissant les "détecteurs" et "actionneurs" parmi une liste générée automatiquement en fonction des plugins actifs, pas besoin de savoir quel sont les méthodes internes des différents plugins, etc

si ça peut aider c'est cool, si ça peut pas tant pis ;)

[ldleman]

Je pense qu'on a a peu près le même objectif, cependant je l'imaginais plutôt sous la forme de listeners que de classe dont on hériterais.

En gros tel que je le vois le concepteur d'un plugin pour une sonde de température pourrait, lorsqu'il recupère la valeur de la sonde, la diffuser dans yana-server en créer un évènement :

Event::emit('receiving_temperature',array('id'=>'2','value'=>'23'))

N'importe quel plugin pourrait alors récupérer cet événement avec une fonction du genre : Event::on('plugin_temp','receiving_temperature','check_stores');

function check_stores($data){ if($data['id']==2 && $data['value']>10){ //ouverture des stores pour réchauffer la piece } }

Évidemment le concept est à creuser, on ne peux pas faire de la vrai gestion d’événement commet sur nodejs ou autres puisqu'elle ne sera pas instantanée mais checkée toutes les minutes via le cron d'event.

Mais ça me parait plus adaptable non?

[f-r-y]

ça marche aussi effectivement, je n'ai aucun argument plus en faveur d'une solution ou de l'autre (même si je visualise mieux "la mienne" gniark gniark :D )

dans ton cas j'imagine qu'il faut donc rajouter une méthode dans les classes de plugins listant les events qu'ils envoient et ceux qu'ils peuvent recevoir (histoire que le plugin de gestion puisse avoir un select des évènements disponibles et des actions, sans avoir a chercher dans les plugins le nom des events a catcher et des méthodes a appeler ensuite) (et prévoir des conventions de nommage des events?)