Hola Gallego
Sin hacer mucho laburo yo sacaria de los accessors a i.v. la llamada al
componente.
Este es el principal problema a mi entender.
Los objetos se modifican por medio de un browser similar a lo que es el
PublishedAspectInspector.
Si saco de los accessors la llamada al componente, se me complica la
actualización del componente.
El objeto quedaría actualizado, pero no la interfase.
Como manejarias la actualizacion en este caso ?
Tendría que tener algo del estilo:
>>color: aColor
color:= aColor.
self update.
En este caso debería actualizar todas la propiedades, de manera innecesaria, a
menos que le pase algo al #update tipo un símbolo y haga un #perform de la
propiedad adecuada.
Estaba viendo algo en Dolphin:
AXControlSite>>isDesignMode: aBoolean
"Set whether the control is in design mode or not."
hostFlags := hostFlags mask: UserModeMask set: aBoolean not.
self ambientDispatch userMode: aBoolean not
IAxWinAmbientDispatch>>userMode: pbUserMode
"Set the 'UserMode' property of the receiver to the <varbool> value of the
argument.
Helpstring: Set the ambient user mode"
self put_UserMode: pbUserMode
Es basicamente lo que hago yo.
Por otra parte, esto es algo en C# que encontré por casualidad
namespace CMEngine
{
public class Actor
{
private TVActor mActor;
private TVPath mPath;
private float mPathSpeed;
private int mAnimationID;
private CONST_TV_ACTORMODE mActorMode;
private CONST_TV_LIGHTINGMODE mLightingMode;
private CONST_TV_CULLING mCullMode;
private bool mCollisionEnable;
private bool mAnimationLoop;
private string mAnimationByName;
private bool mAlphaTest;
private TVShader mShader;
private CONST_TV_BLENDINGMODE mBlendingMode;
private int mColor;
private int mBlendedAnimationID;
private string mBlendedAnimationByName;
private float mBlendedAnimationWeight;
private bool mBlendedAnimationLoop;
public TVPath Path
{
get
{
return mPath;
}
set
{
mPath = value;
mActor.SetPath(value);
}
}
.........
El initialize lo dejaria que setee las propiedades basicas sin hacer el
render o creacion efectiva en la interfaz hasta que yo se lo diga.
Imaginate que esto es util al momento de recrear todo el modelo, por
ejemplo podrias grabar el image con el modelo instanciado, salir volver a
entrar y que todo se encuentre como antes sin mucho esfuerzo.
Acá no me queda claro.
Estarías haciendo algo así:
|aLight|
aLight:=Light new
aLight create.
Las interfases no son serializables y supone un problema adicional.
Yo grabe en formato binario y luego implemente un #reinitialize, donde se crea
la interfase usando los valores que tenía el objeto..
Todos los defaultXxxx, si te gusta dejalos. Yo prefiero no poner tanta
cosa si no hace falta, es decir, cuando la probabilidad de redefinir
esos metodos en subclases es infima, entonces tener un #defaultXxx para
cada default me parece que no es necesario. Fijate. Hay otra opcion que
es tener una coleccion de decorators, fijate el pattern Decorator.
Eso de los default lo saque de Smalltalk Best prectice.
La opción del pattern no me queda clara, estuve viendo y no le encuentro la
aplicación.
Los metodos que hacen contacto con la interfaz los pondria en otra familia, por
ejemplo #setAttenuation: o como mas te guste.A estos QUIZAS los llamaria desde
un metodo #create o #render o algo asi.
Entiendo para la instanciación, pero no para la actualización como te comentaba
arriba
Saludos y gracias kiko
--- El jue 30-sep-10, GallegO <[email protected]> escribió:
De: GallegO <[email protected]>
Asunto: Re: [clubSmalltalk] Consulta sobre modelo
Para: [email protected]
Fecha: jueves, 30 de septiembre de 2010, 9:32
Hola:
Sin hacer mucho laburo yo sacaria de los accessors a i.v. la llamada al
componente. Tambien removeria todas las sucesivas llamadas a las globales por
un metodo implementado en la superclase que devuelva la interfaz. Incluso eso
puede hacer un lookup dinamico de la interfaz mas apropiada partiendo del
nombre de la clase donde es solicitada.
El initialize lo dejaria que setee las propiedades basicas sin hacer el render
o creacion efectiva en la interfaz hasta que yo se lo diga. Imaginate que esto
es util al momento de recrear todo el modelo, por ejemplo podrias grabar el
image con el modelo instanciado, salir volver a entrar y que todo se encuentre
como antes sin mucho esfuerzo.
Todos los defaultXxxx, si te gusta dejalos. Yo prefiero no poner tanta cosa si
no hace falta, es decir, cuando la probabilidad de redefinir esos metodos en
subclases es infima, entonces tener un #defaultXxx para cada default me parece
que no es necesario. Fijate. Hay otra opcion que es tener una coleccion de
decorators, fijate el pattern Decorator.
Los metodos que hacen contacto con la interfaz los pondria en otra familia, por
ejemplo #setAttenuation: o como mas te guste.A estos QUIZAS los llamaria desde
un metodo #create o #render o algo asi.
Tambien podria usarse un pattern visitor. Para mi el visitor es más elegante y
la verdad en distintos usos siempre nos dio buenos resultados, pero, a veces
siento que me aleja un poco de lo que quiero hacer realmente en ese
momento.Quizas es la opcion a implementar para refinar la cosa una vez que
tenes claro como debería andar.
De todas formas no estoy seguro si para tu problema aplica ese pattern o
conviene otra cosa.
Espero que alguien ayude si sabe más.
Saludos GAllegO
El 29 de septiembre de 2010 15:51, Jose Gregoris <[email protected]>
escribió:
Hola Gallego
Gracias, si, así lo tengo implementado y anda ok.
Otra cosa relacionada a esto.
Cuando creo un objeto Light este debe tener algunos valores por default. Lo que
hago es implementar un #default que retorne una instancia con dichos valores.
Algo como:
Light(class)>> default
^self new initialize
Y tengo mensajes que retornan valores por default, algo como:
Light>>defaultColor
^Color red
Ahora el #initialize es
así:
Light>>initialize
"Initialize the receiver"
super initialize.
index := TV3DEnvironment current lightManager
createDirectionalLightOfColor: self defaultColor
direction: self defaultDirection.
self
attenuation: self defaultAttenuation;
specularLevel: self defaultSpecularLevel;
ambient: self defaultAmbient;
diffuse: self defaultDiffuse;
name: self defaultName;
position: self defaultPosition;
range: self defaultRange;
enable: true;
isCastShadows: true;
isManagedLight: true;
isForLightmapping: false
Donde por ejemplo #attenuation: hace esto:
Light>>attenuation: aPoint3D
"Private - Set the receiver attenuation color."
attenuation := aPoint3D.
TV3DEnvironment current lightManager setLight: self index attenuation:
aPoint3D
Me queda la sensación de que el #initialize es medio raro.
El sobre todo como seteo las propiedades, es decir llamando a cada mesaje como
#attenuation.
Por lo regular uno setea los colaboradores sin hacer uso de los accessors
dentro del #initialize. Pero en este caso, sino lo hago así me quedaría un
#initialize más grande y más feo.
Algo como:
Light>>initialize
"Initialize the receiver"
super initialize.
index := TV3DEnvironment current lightManager
createDirectionalLightOfColor: self defaultColor
direction: self defaultDirection.
attenuation:= self defaultAttenuation.
TV3DEnvironment current lightManager setLight: self index attenuation:
attenuation
................
Que opinas ?
saludos
--- El mié 29-sep-10, GallegO <[email protected]> escribió:
De: GallegO <[email protected]>
Asunto: Re: [clubSmalltalk] Consulta sobre modelo
Para: [email protected]
Fecha: miércoles, 29 de septiembre de 2010, 14:49
Hola:
Podrias usar algun
objeto tipo TVEngineManager con una coleccion o variables o dict con cada uno
de los engines instanciados. Incluslo a mismo implementas la finalizacion para
que finalice los demas engines.
De esa forma, si implementas un registro podes tener mas control sobre las
interfaces instanciadas y de que manera vas haciendo los "release" ya que a
veces no da buenos resultados (o no es posible) dejarlo librado a la logica de
la finalizacion transparente por GC que proponen los frameworks COM.
Saludos
El 28 de septiembre de 2010 22:41, Jose Gregoris <[email protected]>
escribió:
Hola
Tengo una duda sobre como modelar lo siguente.
Tengo un COM llamado ITVLightEngine , que se encarga de crear luces y modificar
todas las propiedades de las mismas.
La interfase solo retorna un index a una luz y sobre eso quiero modelar un
objeto Light.
El tema es que ITVLightEngine es un singleton y todo lo que modifique sobre
mi objeto Light debo hacerlo por medio de la interface.
Si fuera una DLL no tendría dudas, ya que podría hacer algo así:
Light>>color: aColor
"Set the receiver color"
color:= aColor.
XXXDLL default setColor: aColor
Aquí tengo un COM y hay que tenerlo instanciado. Podría tener una global y
usarlo de la misma forma que una DLL.
El tema es que esto se repite con unas cuantas interfases COM y no me gusta
como queda con
globales.
Hay alguna forma estandar de modelar esto ? Tipo pattern
Sugerencia ?
saludos kiko
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
http://www.clubSmalltalk.org
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
http://www.clubSmalltalk.org
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
http://www.clubSmalltalk.org
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
http://www.clubSmalltalk.org
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
http://www.clubSmalltalk.org
