SSAS - Object.registerClass et nameSpace ?
ekameleon
Bon alors je viens vers vous pour une question au sujet de la méthode
registerClass :)
J'ai eu envie tout à l'heure de tester cette méthode coté serveur
via la fonction application.registerClass qui est normalement fontionne
normalement comme pour la classe Object ActionScript :)
Elle fonctionne bien en utilisant une fonction nommée mais elle refuse
totalement les fonctions anonymes et là d'un coup j'en viens à me
demander comment je peux enregistrer une fonction constructeur défini
sur un namespace avec cette méthode ?
Exemple :
function MyConstructor() {
trace("my constructor") ;
}
MyConstructor.prototype.myMethod = function () {} ;
application.registerClass( "MyConstructor" , MyConstructor) ; // ici
tout fonctionne !!
Si je tape au contraire :
MyConstructor = function () {
trace("my constructor") ;
}
application.registerClass( "MyConstructor" , MyConstructor) ;
J'obtiens alors comme erreur :
Sending error message: Error registering class: name mismatch
(MyConstructor, anonymous).
Donc en gros pas de fonction anonyme ... maintenant si j'ai une classe
qui possède un namespace style : vegas.events.BasicEvent ... Je fais
comment ? Impossible d'enregistrer les fonctions constructeurs
définies en dehors du "_global" du serveur ? Etrange ??
J'ai pas trouvé grand chose à ce sujet sur le net... donc si
quelqu'un a une idée ?
Pour ceux qui n'ont pas encore testé cette méthode, voilà le lien
vers la doc :
http://livedocs.macromedia.com/fms/2/docs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000660.html
EKA+ :)
zwetan
serialisation de données avec les trucs Macormedia :)
bon c'est pas entierement leur faute
mais ils ont qd meme fait trop simple
au lieu de tout prendre en compte
pour les differences et tous les petites nuances
dans les declarations de fonction
voir ici
ekameleon
objet par ce moyen là !
Du coup bah je suis en train de finir tout ce qu'il faut sur Vegas pour
que le toSource() passe comme il faut dans tous mes objets qui vont
être transmis entre le serveur et le client.
Par contre parfois au niveau AS2 au niveau de l'héritage... avec le
super() qui est lancé tout seul et l'impossibilité de faire un truc
du style super.apply(this, arguments) ... bah franchement c'est un peu
du jonglage à certains moments... surtout quand il faut passer
beaucoup de paramètres pour configurer l'initialisation d'un objet que
l'on veut désérialiser ! Le super lance le super constructeur dans
tous les cas à blanc et aprés il faut tenter de relancer la fonction
constructeur de la superClasse avec les bons paramètres..
Bref :) je réfléchi à la façon la plus propre de gérer ce genre
d'initialisation sur des classes qui nécessite pas mal d'héritage
derrière.
Exemple :
class vegas.events.BasicEvent extends CoreObject implements Event,
ISerializable {
// ----o Constructor
public function BasicEvent(
type:String
, target
, context
, p_bubbles:Boolean
, p_eventPhase:Number
, p_time:Number
, p_stop:Number
) {
Ensuite la classe DynamicEvent qui hérite de la première :
import vegas.events.BasicEvent;
dynamic class vegas.events.DynamicEvent extends BasicEvent {
// ----o Constructor
public function DynamicEvent(
type:String
, target
, context
, p_bubbles:Boolean
, p_eventPhase:Number
, p_time:Number
, p_stop:Number
) {
Function(BasicEvent).apply(this, arguments) ;
}
On peut arriver parfois à des trucs encore plus compliqué, exemple
avec la classe ModelChangedEvent :
class vegas.events.ModelChangedEvent extends BasicEvent {
// ----o Constructor
public function ModelChangedEvent(
name:String , target
, p_context
, p_bubbles:Boolean
, p_eventPhase:Number
, p_time:Number
, p_stop:Number
, p_data
, p_fieldName:String
, p_firstItem:Number
, p_index:Number
, p_lastItem:Number
, p_removedIDs:Array
, p_removedItems:Array
) {
if (arguments[0] == null) arguments[0] =
ModelChangedEventType.MODEL_CHANGED ;
Function(BasicEvent).apply( this, [].concat(arguments.slice(0, 7)) )
; // super
data = p_data || null ;
fieldName = p_fieldName || null ;
firstItem = isNaN(p_firstItem) ? null : p_firstItem ;
index = isNaN(p_index) ? null : p_index ;
lastItem = isNaN(p_lastItem) ? null : p_lastItem ;
removedIDs = p_removedIDs || null ;
removedItems = p_removedItems || null ;
}
Donc j'utilise directement la fonction constructeur avec un apply() ..
le problème c'est qu'en AS2 cela me lance 2 fois le constructeur de la
superClass... et quand je vais + loin dans l'héritage cela devient
vite un gros sac de noeud :)
Si quelqu'un à des idées pour optimiser tout cela.. j'attends vos
réactions là dessus... :)
EKA+ :)
funkC
> Par contre parfois au niveau AS2 au niveau de l'héritage... avec le
> super() qui est lancé tout seul et l'impossibilité de faire un truc
> du style super.apply(this, arguments) ...
euh si tu fais
class SuperClass
{
function SuperClass( arg:String )
{ trace ("SuperClass::constructor" + arg); }
}
class Child extends SuperClass
{
function Child( arg:String )
{
super(arg);
}
}
ça passe l'argument au constructeur et ça ne trace qu'une fois ;
moralité : le super est lancé implicitement si non spécifié, sinon
tu peux passer manuellement les éventuels arguments au constructeur
parent ; Dans ce cas la le constructeur n'est pas appelé deux fois.
ekameleon
apply par exemple (surtout si tu sais pas à l'avance le nombre de
paramètres qui vont être passés dans la fonction...). C'est ce
problème que je trouve dommage, car sinon il est évidant qu'en
utilisant simplement le super() tout fonctionne :)
EKA+ :)
funkC
le comment de prayone la :
http://blog.lalex.com/comments/200605/307-constructeur-arguments.html#comments
ça ne me serait pas venu à l'esprit que super puisse être carrément
une référence au constructeur parent (type Function) mais dans ce cas
ça tombe sous le sens. J'étais persuadé que c'était juste un mot
clé du language.
on en apprend tout les jours :)