Discussion :

[krunch]

Bonjour

C'est pour un problème de structure. Actuellement ça fonctionne, mais c'est plus pour comprendre et avancer dans le js 'objet' ...

J'ai une fonction d'initialisation qui fonctionne avec des callbacks, et qui est résumée ci-dessous...
Par exemple la fonction Run est appelée par un clic utilisateur, la fonction LoadScripts (url, callback) charge une BIBLIO dynamiquement et gère une jauge .. avant de fabriquer l'objet (theobject) à la fin.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
Layout  =
{
 
	Init: function (parameters)
	{
		parameters = parameters || {};
 
		var param = parameters.param;
		var callback  = parameters.callback;
 
		...
 
		Run = function ()
		{
			...
 
			Layout.LoadScripts
			(
				parameters.scripts,
 
				function ()
				{
					...
 
					var theobject = new BIBLIO.Construct (param)
 
					parameters.callback (theobject, truc, much);
				}
			);
 
		};
 
		...
	},
 
	...
},

Dans la page index je suis obligé de l'appelle de cette façon :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
var theobject;
Layout.Init 
({
	scripts:
	{
		main: 'https..BIBLIO.js', 
		...
	},
	param: 'param',
	callback: init
});
function init(back, truc, much)
{
	theobject = back;
	...
};

J'aimerais savoir si il y a un moyen pour que ma fonction Init soit un vrai constructeur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
var theobject = new Layout.Init 
({
	scripts:
	{
		main: 'https..BIBLIO.js', 
		...
	},
	param: 'param',
	callback: init
});
function init(truc, much)
{
	...
};

Actuellement ce n'est évidemment pas possible puisque je ne sais pas où mettre un return, et qu'il n'est pas possible de lancer un callback et un return en même temps ...
Y a t-il une autre structure possible pour ce genre de chose ?
Merci d'avance

[sekaijin]

soit je n'ai pas compris soit il y a quelque chose d'illogique dans ta demande.

un constructeur est une fonction qui avec l'aide de new fabrique un nouvel objet. un espèce d'initialisateur.

new crée la référence memoire necessaire et le constructeur y place tout le necessaire (héritage init de membre etc)

comment un constructeur peut-il être asynchrone ?
tu voudrais que js fasse le new et attende la réponse pour préparer l'objet.
Que devient la référence à cet objet avant qu'il soit initialisé. comment l'utiliser ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
var a = new myConstructor();
// utilisation de a alors que le constructeur attends le chargement de la lib pour executer la callback
console.log(a.getValue());
// losque le callback du constructeur arrive intialisation de a

c'est une façon étrange de raisonner.

A+JYT

[krunch]

tu voudrais que js fasse le new et attende la réponse pour préparer l'objet.

En fait je voudrais que js attende la réponse pour faire le new puis lancer le callback, c'est ce qui se passe dans ma version actuelle.

Que devient la référence à cet objet avant qu'il soit initialisé. comment l'utiliser ?

Il ne peut être utilisé qu'après le callback.


Le 2è appel que j'ai mis (var theobject = new Layout.Init ...) est illogique.
Ma question est effectivement : y a t-il une façon de faire un constructeur asynchrone ?

Ça ne me paraît pas aberrant en soi : avant que l'objet soit initialisé il n'existe pas, il n'existe qu'après le callback ..

[sekaijin]

je te conseille de regarder du coté de RequireJS

plutôt qu'un constructeur assynchrone il s'agit de mettre en place un systeme de chargement dynamique de js
cela te permet via un appel d'indiquer à js que tu veux qu'un script js soit chargé avant que l'appel du constructeur soit effectué.
du coup le constructeur est on ne peut plus normal.

c'est le même genre de fonctionnement qui est utilisé dans sencha.
A+JYT

[krunch]

Oui effectivement j'avais vu ça, j'avais même fait ma fonction 'LoadScripts' pour remplacer Require.js par qq chose de plus light (elle fait la même chose et jusqu'à présent elle a toujours marché), mais je vais regarder Require de plus près.

J'ai pensé qu'il y avait des astuces js que je ne connaissais pas pour ça, mais peut être pas...

Merci

[sekaijin]

à partir du moment ou tu comment à introduire de l'assynchrone il te faut maitriser le moment ou les scripts sont exécuté.

le moyen le plus simple est d'utiliser les événements.
Dans requirejs tu fourni une callback à exécuter lorsque le script est chargé.

mais on peu facilement amméliorer le principe. à la place d'une callback tu crée un nouvel événement. ainsi plus besoin de passer une callback au riquire il suffit d'avoir défini au préalable zero, un ou plusieurs handlers.

en fait extjs et YUI fonctionnent ainsi.
par exemple lorsque tu utilise un panel le require lance le chargement de Ext.panel.Panel.js lorsque le fichier est chargé l'événement "loaded"avec le nom du fichier est crée. le componant manager possède un handler sur cet événement il s'active et garde l'info comme quoi le fichier est chargé. le contenu du fichier est interprété et une "classe" (un prototype en réalité) est défini l'événement indiquant que la classe est crée est activé le componant manager sait alors qu'il peut créer pour toi l'instance. une succéssion d'événement seront ainsi créé tout au long de la vie du composant libre à toi de les utiliser ou pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
activate
add
added
afterlayout
afterrender
beforeactivate
beforeadd
beforeclose
beforecollapse
beforedeactivate
beforedestroy
beforeexpand
beforehide
beforeremove
beforerender
beforeshow
beforestaterestore
beforestatesave
blur
boxready
close
collapse
deactivate
destroy
disable
dockedadd
dockedremove
enable
expand
float
focus
glyphchange
hide
iconchange
iconclschange
move
remove
removed
render
resize
show
staterestore
statesave
titlechange
unfloat

ce cette façon il n'est plus nécéssaire de fournir des callbaks lors de la définition de l'instance mais d'avoir prévu des handlers sur les élement qui t'intéresses.

tu peux toi même expérimenter le principe en utilisant var event = new Event('myEventType'); et en utilisant vaddEventListener et dispachEventA+JYT

[krunch]

Plusieurs choses :

- par rapport à ma question de base il semble que le seul moyen soit tout de même de placer le new dans le 'callback' final, puis de rendre l'objet plus ou moins global en le changeant de variable, comme dans mon exemple (le 1er appel, pas celui qui est illogique..).

- ce que j'appelle 'callback' n'est jamais qu'une fonction passée à un événement, en l'occurrence onload (ma fonction 'LoadScripts' utilise ça), donc il me semble qu'on parle un peu de la même chose.

Mais peut-être pas ... tu me parles de custom events (en prenant exemple sur le pannel d'une biblio de Sencha d'après ce que je comprends), et là j'ai passé un moment à chercher des choses sur la pertinence et la façon de les utiliser (à quel moment et comment les utiliser) mais je n'ai pas vraiment compris. Il me semble qu'il y a un manque de doc/tutos sur les custom events, des cas concrets et simples.

Bref en d'autres termes je comprends pas en quoi un custom event pourrait plus m'aider que le bon vieux onload que j'utilise...

[sekaijin]

lorsque tu utilise requirejs tu appelle une focntion avec en paramètre un nome de fichier js et une fonction à appeler lorsque le fichier sera chargé
tu as passé là une callback

dans YUI ou sencha et d'autre lorsque tu appelle la fonction require tu lui donne un nom de fichier js à charger. lorsque le fichier est chargé un custom event est généré.
tu n'as pas à passer de callback mais tu peux ajouter plusieurs (et non un seul) handler sur l'événement. c'esy donc beaucoup plus souple.

imagine que tu definisse un prototype que tu veux donner la possibilité au developpeur de réagir après qu'une instance ait été construite. si tu passe par un événement le developpeur pourras activer les handler de sont choix s'il y a un événement alors que si tu a prévu de fournir une callback au constructeur le developpeur devra faire une fonction complexe qui fait tout ce que les handlers feraient individuellement.

un autre exemple tu défini un objet menu déroulant et tu veux qu'un div s'affiche lorsque le menu sera affiché mais aussi qu'un arbre soit inactivé au même moment. a la fin de la méthode display de ton menu tu créé un custom event et c'est fini

en agisant ainsi tu peux facilement définir des composant génériques et réutilisable qui seront facile à intégrer.


la programmation événementielle a eu une heure de gloire. à l'époque ou les OS n'était pas multitâche (une seul programme à la fois un seul thread) on utilisait les événement le plus possible.
par exemple dans MacOS 6 lorsque tu cliquais sur un menu on n'éxécutais pas la méthode associé on lançais un événement par exemple "Edit_Undo_Activated" du coup le système passait dans la boucle des événements. si un tâche de fond était défini le gestionaire d'événement lui donnait la main et une foit qu'elle la rendait passait à l'événement suivant et l'événement Undo arrivait à son tour.

plus besoin de réflechir à des enchainement de procédure complexe mais faire une action simple et signaler au systeme de passer à la suite.

entre cette approche et la prog habituelle des applications beaucoup plus réactives.

c'est facile à mettre en oeuvre avec JS pour chaque type d'objet que tu utilise réflechi au cycle de vie de l'objet et partout ou cela semble opportun crée un événement (avec des infos de conexte)

par la suite lorsque tu utilise tes objets tu n'a plus qu'à te poser comme question qu'ais-je comme événement à ma disposition ?

ainsi pour créer des type d'objet tu n'a pas à penser à tous les usages possibles tu te concentre sur le type lui-même.

A+JYT

[krunch]

Ok, je crois comprendre, du moins en partie ...
En gros tu fragmentes les taches à lancer dès la source du déclenchement en autant de 'handler' au lieu de déclencher un seul 'callback' qui serait truffé de tests conditionnels, et avec en plus la possibilité de passer des custom-datas relatives au contexte.
Mais on dirait que ce qui justifie la différence de dénomination handler/callback c'est juste qu'il y a plusieurs handlers possibles alors qu'il n'y aurait qu'un seul callback (je veux dire les deux restent une ou des fonction(s) déclenchée(s) par un réacteur non, c'est quand même le même principe ?).

En dehors de ça oui je pense entrevoir que c'est sans doute plus commode à gérer dans le cadre d'une appli complexe...

Tes explications sont largement au delà de mon niveau. Je potasse aussi les questions d'architecture à mes heures, pour le moment tout ça est encore trop largement dans le brouillard mais je me doute bien qu'une appli où on peut cliquer partout, déclencher des taches nécessairement synchrones, gérer le Undo .. tout ça pose des problèmes de ouf.

Bref merci bien pour tes explications j'y reviendrai en temps voulu