Menu
▾
▴
objectbase-devel — Lista de desarrolladores / Developer's list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(14) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(9) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ben...@id...> - 2004-05-25 08:40:18
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Hernan L. <her...@de...> - 2004-02-12 16:51:00
|
Les parece utilizar RDF (http://www.w3.org/RDF) para almacenar la información del engine? La gente de mozilla lo usa como base de datos default en sus aplicaciones XUL. saludos |
|
From: Hernan L. <her...@de...> - 2004-01-16 17:14:09
|
Nuevamente no tengo nada para hacer en ObjectBase asi que me voy a ir al engine. que features incluimos? propuestas: engine remoto? persistencia a xml? engine being application server like? persistent object method calling? soy todo oidos |
|
From: Hernan L. <her...@de...> - 2004-01-15 18:57:44
|
Javi (y quien quiera hacerlo con el), te paso lo que habria que hacer: La tarea consiste un tener un proceso el cual recibe el nombre de un paquete que contiene las clases del proyecto y un conjunto de clases que son determinadas como "persistibles". Lo que debe hacer es recorrer todas las clases del proyecto indicado y buscar por accesos a las variables de instancia (públicas o privadas) de las clases marcadas como persistibles. Sobre cada acceso encontrado, debe verificar si es de escritura y solo en ese caso cambiar el bytecode. El cambio del bytecode implica dejar que se haga lo que se queria hacer pero tambien construir un objeto ChangeAction y agregándolo en la unitOfWork tal cual como lo teníamos hecho en los proxied del fin de semana. El código javassist para poder hacer eso está en los samples y en los mails que envié en estos dias. Lo importante es que implementes el proceso sin importarte mucho como van a llegarte los datos. Es posible que tengamos una tarea ant, xdoclets o un xml de configuración pero todavia no lo tenemos definido. El proceso deberia loguear lo que está haciendo y ser amigable con respecto al modo de mostrar los errores. Para evitar la manipulacion de bytecode a clases que ya fueron manipuladas, deberias ponerle alguna marca a dichas clases en donde especificas la version del cambio. saludos |
|
From: Hernan L. <her...@de...> - 2004-01-15 15:00:49
|
Hay alguien insteresado en trabajar en el arte de ob? miren estos muchachos lo locos que estan: http://www.netbsd.org/images/NetBSD.jpg |
|
From: Hernan L. <her...@de...> - 2004-01-14 16:23:34
|
1) hoy en la quinta vamos a dejar una version tendiendo a final de los que hoy son proxy de objetos de negocios con javaassist. 2) vamos a retocar la interface de unitOfWork y ObjectBase para lograr un uso mas simple basados en la idea de UnitOfWork automaticos. es posible que manana subamos algo al repositorio para que vean como va quedando. saludOBs |
|
From: Hernan L. <her...@de...> - 2004-01-14 14:42:02
|
Siguiendo con las profesias de cosas que no se podian hacer aca tengo el
código para hacer algo antes de que una variable de instancia
cambie su valor.
En este caso tengo un bean, digo bean aunque podria ser cualquier
objeto. Cuando alguien cambia el valor de la variable privada
de instancia nombre, yo imprimo un saludo.
public class Persona {
private String nombreString;
public String getNombre() { return nombreString; }
public void setNombre(String _nombreString) { nombreString =
_nombreString; }
public static void main(String[] args) {
try {
String _classNameString = "ar.com.dypsa.test.Persona";
// getting the pool, loader and class
ClassPool _classPool =
ClassPool.getDefault(); // tomo el default classloader de
javaassist
Loader _loader = new
Loader(_classPool);
CtClass _class =
_classPool.get(_classNameString); // tomo una referencia
javaassist a la clase Persona
// getting the methods
CtMethod[] _aMethods = _class.getDeclaredMethods();
// busco todos los metodos de la clase
for ( int _iIndex = 0 ; _iIndex < _aMethods.length ;
_iIndex++ ) {
CtMethod _ctMethod = _aMethods[_iIndex];
_ctMethod.instrument(new ExprEditor()
{ // a cada metodo lo
digo que si toca el campo nombre..
public void edit(FieldAccess _fieldAccess)
throws CannotCompileException {
if (
_fieldAccess.getFieldName().equals("nombre") ) {
if ( _fieldAccess.isWriter() )
{ // si lo
quiere cambiar....
_fieldAccess.replace("{ "
+ // lo que
va a hacer es cambiarlo, pero antes imprime
"System.err.println(\"salut!" +
"$0.nombre = $1; " +
" }");
}
}
}
});
}
}
// tomo una nueva referencia a la clase dinamicamente
cambiada
Class _theNewClass =
_loader.loadClass(_classNameString);
// instancio mi nuevo amiguito
Object _converter = _theNewClass.newInstance();
// llamo a setNombre y luego a getNombre
Method[] _aNewMethods =
_converter.getClass().getMethods();
for ( int _iIndex = 0 ; _iIndex < _aNewMethods.length ;
_iIndex++ ) {
Method _method = _aNewMethods[_iIndex];
if ( _method.getName().equals("setNombre") ) {
_method.invoke(_converter, new Object[] {
"nuevo_nombre" });
}
}
for ( int _iIndex = 0 ; _iIndex < _aNewMethods.length ;
_iIndex++ ) {
Method _method = _aNewMethods[_iIndex];
if ( _method.getName().equals("getNombre") ) {
String _nuevoNombreString = (String )
_method.invoke(_converter, null);
// en este punto podemos ver que el nombre si
cambio, pero que tambien se imprimio salut!
System.err.println("nuevoNombreString: [" +
_nuevoNombreString + "]");
}
}
System.err.println("done");
}
catch (Exception _exception) {
_exception.printStackTrace();
}
}
}
|
|
From: Hernan L. <her...@de...> - 2004-01-14 12:25:43
|
Bueno, nuevamente Bienvenido!
Para estar todos en la misma sintonia, seria bueno que comiences por
actualizarte: que leas
todo lo que está en el sitio y todos mails de la lista (que no son
tantos).
En base a eso, necesitaria que formules un mail con las dudas que tenés
de OB, como sentís
que podrias colaborar, que le ves de bueno al proyecto y que de malo, tu
experiencia, y todo
lo que tengas ganas de escribir. También bajate los fuentes y miralos un
poco, te recomiendo
empezar los por unit tests ya que muestran claramente como queremos que
sea la interface
de búsqueda.
Durante este mes, estamos trabajando fuerte para terminar la interface
de llamemosle escritura
y es posible que lleguemos a tener una implementación que persista. En
el proceso, surgen
muchas tareas que necesitamos asignar. Ponete al día, hacenos saber como
sos y de ahi
vamos a poder comenzar.
Saludos,
Hernán.
On Wed, 2004-01-14 at 12:08, Luciano Rey wrote:
> Hernan:
> yo quiero participar en el subproyecto de front-end, asi que espero tus
> indicaciones para ver que tengo que hacer y como estan en este momento.
>
> _________________________________________________________________
> MSN Amor: busca tu ½ naranja http://latam.msn.com/amor/
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Objectbase-devel mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbase-devel
>
|
|
From: Luciano R. <rey...@ho...> - 2004-01-14 12:08:11
|
Hernan: yo quiero participar en el subproyecto de front-end, asi que espero tus indicaciones para ver que tengo que hacer y como estan en este momento. _________________________________________________________________ MSN Amor: busca tu ½ naranja http://latam.msn.com/amor/ |
|
From: Hernan L. <her...@de...> - 2004-01-13 19:58:44
|
Usando javaassist logré convertir un objeto no serializable en
serializable.
No es que hiciera nada groso, solo usé el API. Lo bueno es que SI
FUNCIONA!
Object o = new TestObject();
System.err.println("-> [" + ( o instanceof Serializable ) +
"]"); // da false
ClassPool pool = ClassPool.getDefault();
Loader cl = new Loader(pool);
CtClass cc = pool.get("ar.com.dypsa.test.TestObject");
CtClass _serializable = pool.get("java.io.Serializable");
CtClass[] _interfaces = { _serializable };
cc.setInterfaces(_interfaces);
Class c = cl.loadClass("ar.com.dypsa.test.TestObject");
Object oo = c.newInstance();
System.err.println("-> [" + ( oo instanceof Serializable ) +
"]"); // da true
System.err.println("done");
|
|
From: Hernan L. <her...@de...> - 2003-12-29 15:52:34
|
Bien, coincido. El punto es encontrar un lenguaje simple para localizar un objeto en una jerarquia de objetos. siendo un espacio de nodos, cada transicion puede ser un atributo o un metodo (publicos) que lenguajes tenemos para determinar un nodo de manera inequivoca en un espacio? paths? paths incompletos? "getDocumento.*.#tipo.getId" donde # indica que es un atributo y * indica cualquier cosa en el medio? vamos a algun lado con esto? no es que este de acuerdo, solo lo tiro para revolver un poco sus ideas. |
|
From: Juan P. P. <jua...@es...> - 2003-12-29 15:13:18
|
Coincido totalmente, eso mismo dec=EDa yo cuando discut=EDamos en la =FAl=
tima=20
clase de persistencia en tadp. Si realmente buscar por esos campos es=20
necesarios, pero no son visibles, hay algo mal en el modelo.
Jorge Campos wrote:
>No me convence mucho la idea de permitir realizar
>queries por atributos privados (o protected... lease
>no p=FAblicos).
>
>De hecho todo deber=EDa hacerse utilizando m=E9todos y no
>los atributos.
>
>Violar la encapsulaci=F3n para persistir el objeto es
>algo que "no afecta" el modelo y en cierto sentido no
>viola la encapsulaci=F3n de una manera "visible" al
>usuario. En cambio realizar un query
>objeto.atributo_privado =3D=3D dodo es claramente una
>violacion de la encapsulaci=F3n! y peor a=FAn es realizada
>por el usuario (el mismo dice eso).
>
>Si existe el caso donde se quiera buscar por algo
>privado es muy probable que ese algo no sea privado o
>haya alg=FAn error en el modelo.
>
>Jorge
>
>
>--- Nicolas Passerini <npa...@cu...> wrote:
> =20
>
>>En funci=F3n de esto, yo dec=EDa que el lenguaje no
>>necesitar=EDa en principio diferenciar entre getters y
>>
>>atributos, ejemplo: si yo pido documento.pais busca
>>primero un getPais() y si no lo encuentra busca el=20
>>atributo pais.
>>
>>El lenguaje se podr=EDa extender un poquito para
>>bypasear ese comportamiento que ser=EDa el default,
>>ahora no se=20
>>me ocurre nada mejor que agregarle un chirimbolo
>>(algo como documento.#pais) que indicar=EDa que aunque
>>exista=20
>>getPais() yo quiero al atributo. No me preocupa
>>demasiado que quede muy lindo porque ser=EDa algo muy
>>raro de=20
>>usar. De hecho creo que habr=EDa que discutir si est=E1
>>bueno ponerle ese feature.
>>
>>Tambi=E9n podr=EDa haber opciones para pedir un m=E9todo
>>s=ED o s=ED, una simple es documento.getPais(). (No s=E9
>>si me=20
>>gusta mucho).=20
>>
>>Otra que habr=EDa que pensar es si siempre se accede a
>>los m=E9todos/atributos aunque sean privados o en
>>alg=FAn=20
>>caso me interesa asegurarme de que le estoy pegando
>>a la parte p=FAblica del objeto (=BFy protected?). Si es
>>as=ED=20
>>habr=EDa que pensar extensiones para eso.
>>
>>Igual creo que lo importante es mantener la
>>simplicidad del caso m=E1s com=FAn, que creo que es
>>-pegarle a cualquier elemento sea p=FAblico o privado.
>>-buscar primero el m=E9todo y si no est=E1 el atributo.
>>Para ese caso usar=EDa 'documento.pais', si los dem=E1s
>>son un poco m=E1s complicados no me joder=EDa.
>>
>>-----Original Message-----
>>From: Hernan Liendo <her...@de...>
>>To: ObjectBase SF
>><obj...@li...>
>>Date: Sat, 27 Dec 2003 23:05:56 -0300
>>Subject: [Objectbase-devel] Voluntario: Codificaci=F3n
>>de funcionalidad de reflection
>>
>> =20
>>
>>>Necesito que alguien evalue, dise=F1e y desarrolle
>>> =20
>>>
>>un m=F3dulo que me
>> =20
>>
>>>permita acceder a cierta propiedad de un objeto
>>> =20
>>>
>>dentro de una jerarquia
>> =20
>>
>>>de objetos sin que estos sean necesariamente
>>> =20
>>>
>>beans.
>> =20
>>
>>>Ejemplo:
>>>
>>>tengo este dominio de objetos
>>>
>>>Class: Cliente
>>>+getDocumento:Document
>>>+setDocument(Documento)
>>>...
>>>
>>>Class: Documento
>>>+getPais:Pais
>>>+setPais(Pais)
>>>...
>>>
>>>Class: Pais
>>>+getNombre:String
>>>+setNombre(String)
>>>...
>>>
>>>Si yo tuviera una instancia de cliente y quisiera
>>> =20
>>>
>>conocer el nombre del
>> =20
>>
>>>pais al que corresponde su documento utilizando
>>>common-beanutils yo podria tirar:
>>>
>>>String _nombrePais =3D
>>> =20
>>>
>>BeanUtils.getProperty("documento.pais.nombre",
>> =20
>>
>>>_cliente);
>>>
>>>Eso funciona perfecto si las clases son beans y es
>>> =20
>>>
>>lo que estoy usando
>> =20
>>
>>>con composite queries.=20
>>>Lo que se necesita que es esto funcione tambien en
>>> =20
>>>
>>objetos no-beans.=20
>> =20
>>
>>>Deberiamos pensar en un lenguaje similar al
>>> =20
>>>
>>"documento.pais.nombre" que
>> =20
>>
>>>sea sencillo
>>>de usar y que pueda expresar como llegar a una
>>> =20
>>>
>>propiedad de un objeto
>> =20
>>
>>>interno.
>>>
>>>La propiedad puede ser un atributo o un metodo.=20
>>>
>>>Como regla general: todo lo que pueda inferir es
>>> =20
>>>
>>mejor, si no se puede
>> =20
>>
>>>inferir o toma un matiz "dificil de que
>>>alguien entienda como funciona" mejor que no
>>> =20
>>>
>>infiera. Por ejemplo, se
>> =20
>>
>>>puede inferir si algo es metodo o atributo.
>>>
>>>Creo que esto esta bueno para desarrollar entre
>>> =20
>>>
>>una o dos personas.=20
>> =20
>>
>>>El mecanismo seria ir tirando las ideas ANTES de
>>> =20
>>>
>>codificar.
>> =20
>>
>>>SaludOBs
>>>
>>> =20
>>>
>>
>>
>> =20
>>
>-------------------------------------------------------
> =20
>
>>This SF.net email is sponsored by: IBM Linux
>>Tutorials.
>>Become an expert in LINUX or just sharpen your
>>skills. Sign up for IBM's
>>Free Linux Tutorials. Learn everything from the
>>bash shell to sys admin.
>>Click now!
>>
>> =20
>>
>http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> =20
>
>>_______________________________________________
>>Objectbase-devel mailing list
>>Obj...@li...
>>
>> =20
>>
>https://lists.sourceforge.net/lists/listinfo/objectbase-devel
>
>
>__________________________________
>Do you Yahoo!?
>New Yahoo! Photos - easier uploading and sharing.
>http://photos.yahoo.com/
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IBM Linux Tutorials.
>Become an expert in LINUX or just sharpen your skills. Sign up for IBM'=
s
>Free Linux Tutorials. Learn everything from the bash shell to sys admin.
>Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
>_______________________________________________
>Objectbase-devel mailing list
>Obj...@li...
>https://lists.sourceforge.net/lists/listinfo/objectbase-devel
>
> =20
>
|
|
From: Jorge C. <jor...@ya...> - 2003-12-29 14:51:50
|
No me convence mucho la idea de permitir realizar
queries por atributos privados (o protected... lease
no públicos).
De hecho todo debería hacerse utilizando métodos y no
los atributos.
Violar la encapsulación para persistir el objeto es
algo que "no afecta" el modelo y en cierto sentido no
viola la encapsulación de una manera "visible" al
usuario. En cambio realizar un query
objeto.atributo_privado == dodo es claramente una
violacion de la encapsulación! y peor aún es realizada
por el usuario (el mismo dice eso).
Si existe el caso donde se quiera buscar por algo
privado es muy probable que ese algo no sea privado o
haya algún error en el modelo.
Jorge
--- Nicolas Passerini <npa...@cu...> wrote:
> En función de esto, yo decía que el lenguaje no
> necesitaría en principio diferenciar entre getters y
>
> atributos, ejemplo: si yo pido documento.pais busca
> primero un getPais() y si no lo encuentra busca el
> atributo pais.
>
> El lenguaje se podría extender un poquito para
> bypasear ese comportamiento que sería el default,
> ahora no se
> me ocurre nada mejor que agregarle un chirimbolo
> (algo como documento.#pais) que indicaría que aunque
> exista
> getPais() yo quiero al atributo. No me preocupa
> demasiado que quede muy lindo porque sería algo muy
> raro de
> usar. De hecho creo que habría que discutir si está
> bueno ponerle ese feature.
>
> También podría haber opciones para pedir un método
> sí o sí, una simple es documento.getPais(). (No sé
> si me
> gusta mucho).
>
> Otra que habría que pensar es si siempre se accede a
> los métodos/atributos aunque sean privados o en
> algún
> caso me interesa asegurarme de que le estoy pegando
> a la parte pública del objeto (¿y protected?). Si es
> así
> habría que pensar extensiones para eso.
>
> Igual creo que lo importante es mantener la
> simplicidad del caso más común, que creo que es
> -pegarle a cualquier elemento sea público o privado.
> -buscar primero el método y si no está el atributo.
> Para ese caso usaría 'documento.pais', si los demás
> son un poco más complicados no me jodería.
>
> -----Original Message-----
> From: Hernan Liendo <her...@de...>
> To: ObjectBase SF
> <obj...@li...>
> Date: Sat, 27 Dec 2003 23:05:56 -0300
> Subject: [Objectbase-devel] Voluntario: Codificación
> de funcionalidad de reflection
>
> >
> > Necesito que alguien evalue, diseñe y desarrolle
> un módulo que me
> > permita acceder a cierta propiedad de un objeto
> dentro de una jerarquia
> > de objetos sin que estos sean necesariamente
> beans.
> >
> > Ejemplo:
> >
> > tengo este dominio de objetos
> >
> > Class: Cliente
> > +getDocumento:Document
> > +setDocument(Documento)
> > ...
> >
> > Class: Documento
> > +getPais:Pais
> > +setPais(Pais)
> > ...
> >
> > Class: Pais
> > +getNombre:String
> > +setNombre(String)
> > ...
> >
> > Si yo tuviera una instancia de cliente y quisiera
> conocer el nombre del
> > pais al que corresponde su documento utilizando
> > common-beanutils yo podria tirar:
> >
> > String _nombrePais =
> BeanUtils.getProperty("documento.pais.nombre",
> > _cliente);
> >
> > Eso funciona perfecto si las clases son beans y es
> lo que estoy usando
> > con composite queries.
> > Lo que se necesita que es esto funcione tambien en
> objetos no-beans.
> >
> > Deberiamos pensar en un lenguaje similar al
> "documento.pais.nombre" que
> > sea sencillo
> > de usar y que pueda expresar como llegar a una
> propiedad de un objeto
> > interno.
> >
> > La propiedad puede ser un atributo o un metodo.
> >
> > Como regla general: todo lo que pueda inferir es
> mejor, si no se puede
> > inferir o toma un matiz "dificil de que
> > alguien entienda como funciona" mejor que no
> infiera. Por ejemplo, se
> > puede inferir si algo es metodo o atributo.
> >
> > Creo que esto esta bueno para desarrollar entre
> una o dos personas.
> > El mecanismo seria ir tirando las ideas ANTES de
> codificar.
> >
> > SaludOBs
> >
>
>
>
>
-------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux
> Tutorials.
> Become an expert in LINUX or just sharpen your
> skills. Sign up for IBM's
> Free Linux Tutorials. Learn everything from the
> bash shell to sys admin.
> Click now!
>
http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Objectbase-devel mailing list
> Obj...@li...
>
https://lists.sourceforge.net/lists/listinfo/objectbase-devel
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
|
|
From: Nicolas P. <npa...@cu...> - 2003-12-29 13:45:32
|
En función de esto, yo decía que el lenguaje no necesitaría en principio diferenciar entre getters y
atributos, ejemplo: si yo pido documento.pais busca primero un getPais() y si no lo encuentra busca el
atributo pais.
El lenguaje se podría extender un poquito para bypasear ese comportamiento que sería el default, ahora no se
me ocurre nada mejor que agregarle un chirimbolo (algo como documento.#pais) que indicaría que aunque exista
getPais() yo quiero al atributo. No me preocupa demasiado que quede muy lindo porque sería algo muy raro de
usar. De hecho creo que habría que discutir si está bueno ponerle ese feature.
También podría haber opciones para pedir un método sí o sí, una simple es documento.getPais(). (No sé si me
gusta mucho).
Otra que habría que pensar es si siempre se accede a los métodos/atributos aunque sean privados o en algún
caso me interesa asegurarme de que le estoy pegando a la parte pública del objeto (¿y protected?). Si es así
habría que pensar extensiones para eso.
Igual creo que lo importante es mantener la simplicidad del caso más común, que creo que es
-pegarle a cualquier elemento sea público o privado.
-buscar primero el método y si no está el atributo.
Para ese caso usaría 'documento.pais', si los demás son un poco más complicados no me jodería.
-----Original Message-----
From: Hernan Liendo <her...@de...>
To: ObjectBase SF <obj...@li...>
Date: Sat, 27 Dec 2003 23:05:56 -0300
Subject: [Objectbase-devel] Voluntario: Codificación de funcionalidad de reflection
>
> Necesito que alguien evalue, diseñe y desarrolle un módulo que me
> permita acceder a cierta propiedad de un objeto dentro de una jerarquia
> de objetos sin que estos sean necesariamente beans.
>
> Ejemplo:
>
> tengo este dominio de objetos
>
> Class: Cliente
> +getDocumento:Document
> +setDocument(Documento)
> ...
>
> Class: Documento
> +getPais:Pais
> +setPais(Pais)
> ...
>
> Class: Pais
> +getNombre:String
> +setNombre(String)
> ...
>
> Si yo tuviera una instancia de cliente y quisiera conocer el nombre del
> pais al que corresponde su documento utilizando
> common-beanutils yo podria tirar:
>
> String _nombrePais = BeanUtils.getProperty("documento.pais.nombre",
> _cliente);
>
> Eso funciona perfecto si las clases son beans y es lo que estoy usando
> con composite queries.
> Lo que se necesita que es esto funcione tambien en objetos no-beans.
>
> Deberiamos pensar en un lenguaje similar al "documento.pais.nombre" que
> sea sencillo
> de usar y que pueda expresar como llegar a una propiedad de un objeto
> interno.
>
> La propiedad puede ser un atributo o un metodo.
>
> Como regla general: todo lo que pueda inferir es mejor, si no se puede
> inferir o toma un matiz "dificil de que
> alguien entienda como funciona" mejor que no infiera. Por ejemplo, se
> puede inferir si algo es metodo o atributo.
>
> Creo que esto esta bueno para desarrollar entre una o dos personas.
> El mecanismo seria ir tirando las ideas ANTES de codificar.
>
> SaludOBs
>
|
|
From: Hernan L. <her...@de...> - 2003-12-28 15:36:07
|
Necesito que alguien evalue, diseñe y desarrolle un módulo que me
permita acceder a cierta propiedad de un objeto dentro de una jerarquia
de objetos sin que estos sean necesariamente beans.
Ejemplo:
tengo este dominio de objetos
Class: Cliente
+getDocumento:Document
+setDocument(Documento)
...
Class: Documento
+getPais:Pais
+setPais(Pais)
...
Class: Pais
+getNombre:String
+setNombre(String)
...
Si yo tuviera una instancia de cliente y quisiera conocer el nombre del
pais al que corresponde su documento utilizando
common-beanutils yo podria tirar:
String _nombrePais = BeanUtils.getProperty("documento.pais.nombre",
_cliente);
Eso funciona perfecto si las clases son beans y es lo que estoy usando
con composite queries.
Lo que se necesita que es esto funcione tambien en objetos no-beans.
Deberiamos pensar en un lenguaje similar al "documento.pais.nombre" que
sea sencillo
de usar y que pueda expresar como llegar a una propiedad de un objeto
interno.
La propiedad puede ser un atributo o un metodo.
Como regla general: todo lo que pueda inferir es mejor, si no se puede
inferir o toma un matiz "dificil de que
alguien entienda como funciona" mejor que no infiera. Por ejemplo, se
puede inferir si algo es metodo o atributo.
Creo que esto esta bueno para desarrollar entre una o dos personas.
El mecanismo seria ir tirando las ideas ANTES de codificar.
SaludOBs
|
|
From: Hernan L. <her...@de...> - 2003-12-17 16:31:33
|
Recomiendo que lean este paper para cuando tengamos que pensar como deberia ser el protocolo de comunicacion y el formato de archivos de datos en ob. http://www.faqs.org/docs/artu/ch05s02.html#id2902164 (The Art of Unix Programming). y otra cosa, en que estado estamos? saludOBs |
|
From: Juan P. P. <jua...@es...> - 2003-12-10 11:55:13
|
>1) y 2) est=E1n ampliamente relacionados a lo que yo > estoy haciendo (y hay algo funcionando), me vendria > bien una mano cuente conmigo, que puedo hacer para ayudarte? (ya se que lo primero es "leer todo", pero teniendo alguna especie de objetivo es m=E1s facil pone= rse las pilas). ----- Original Message -----=20 From: "Jorge Campos" <jor...@ya...> To: "ObjectBase SF" <obj...@li...> Sent: Tuesday, December 09, 2003 9:22 PM Subject: Re: [Objectbase-devel] clonando lo inclonable > Wait! > > Not having decided if the list should be in english, > spanish, french, elvish (or elven) or Klingon I will > write this response in spanish. > > 1) y 2) est=E1n ampliamente relacionados a lo que yo > estoy haciendo (y hay algo funcionando), me vendria > bien una mano porque hay que definir un par de cosas y > luego laburar bastante (hay muchos casos particulares > que deben ser tratados individualmente) > > 3) hay que bien primero la necesidad de esto... me > parece que hacerlo ahora es adelantarse. > > > Jorge > > --- Juan Pablo Picasso > <jua...@es...> wrote: > > ok, de aspectos algo (alguito mejor dicho) charl=E9 > > con nico una vez, de BCEL todo lo que se es que son > > 4 letras. pero, investigar=E9, evaluar=E9, comentar=E9, y > > con un poco de suerte lo har=E9! > > > > che, esta lista cuando pones reply, manda mail al > > remitente posta, y no a la lista :-/ > > de alguna manera me llego tres veces el mail, por > > qu=E9 lo mandaste a mi mail, a tadp y ac=E1? > > > > saludos, > > JP > > ----- Original Message -----=20 > > From: Hernan Liendo > > To: Juan Pablo Picasso ; tadp ; ObjectBase SF > > Sent: Monday, December 08, 2003 9:03 PM > > Subject: Re: [Objectbase-devel] clonando lo > > inclonable > > > > > > > > Perd=F3n por la demora. Mi nueva distro est=E1 > > finalmente instalada. (aprovecho para maxirecomendar > > gentoo, junto con Joe, the cow) > > > > Las tareas se manejan desde SF. > > Lo que requiere voluntarios actualmente es lo > > relacionado con manipulacion de bytecode: BCEL o > > aspectos. > > > > En estos dias no hay nadie que pueda decir cual de > > los dos es mas util para nosotros asi que es parte > > de tu trabajo evaluarlos. > > > > Por ahora hay 3 cosas (aunque se vienen muchas > > mas) que tenemos que hacer con bytecode: > > > > 1) clonar lo inclonable > > 2) serializar no inserializable > > 3) atrapar llamadas a metodos de objetos > > no-nuestros > > > > que comience la funcion! > > > > On Sat, 2003-12-06 at 13:25, Juan Pablo Picasso > > wrote: > > Como habl=E9 con Hern=E1n, me parece interesante lo > > de clonar objetos que no sean clonables, asi que si > > les parece me prendo con eso. Como es el tema de las > > tasks, como/donde figurar=EDa/me anoto? > > > > saludos, > > JP > > > __________________________________ > Do you Yahoo!? > New Yahoo! Photos - easier uploading and sharing. > http://photos.yahoo.com/ > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Objectbase-devel mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbase-devel |
|
From: Jorge C. <jor...@ya...> - 2003-12-10 00:22:33
|
Wait! Not having decided if the list should be in english, spanish, french, elvish (or elven) or Klingon I will write this response in spanish. 1) y 2) están ampliamente relacionados a lo que yo estoy haciendo (y hay algo funcionando), me vendria bien una mano porque hay que definir un par de cosas y luego laburar bastante (hay muchos casos particulares que deben ser tratados individualmente) 3) hay que bien primero la necesidad de esto... me parece que hacerlo ahora es adelantarse. Jorge --- Juan Pablo Picasso <jua...@es...> wrote: > ok, de aspectos algo (alguito mejor dicho) charlé > con nico una vez, de BCEL todo lo que se es que son > 4 letras. pero, investigaré, evaluaré, comentaré, y > con un poco de suerte lo haré! > > che, esta lista cuando pones reply, manda mail al > remitente posta, y no a la lista :-/ > de alguna manera me llego tres veces el mail, por > qué lo mandaste a mi mail, a tadp y acá? > > saludos, > JP > ----- Original Message ----- > From: Hernan Liendo > To: Juan Pablo Picasso ; tadp ; ObjectBase SF > Sent: Monday, December 08, 2003 9:03 PM > Subject: Re: [Objectbase-devel] clonando lo > inclonable > > > > Perdón por la demora. Mi nueva distro está > finalmente instalada. (aprovecho para maxirecomendar > gentoo, junto con Joe, the cow) > > Las tareas se manejan desde SF. > Lo que requiere voluntarios actualmente es lo > relacionado con manipulacion de bytecode: BCEL o > aspectos. > > En estos dias no hay nadie que pueda decir cual de > los dos es mas util para nosotros asi que es parte > de tu trabajo evaluarlos. > > Por ahora hay 3 cosas (aunque se vienen muchas > mas) que tenemos que hacer con bytecode: > > 1) clonar lo inclonable > 2) serializar no inserializable > 3) atrapar llamadas a metodos de objetos > no-nuestros > > que comience la funcion! > > On Sat, 2003-12-06 at 13:25, Juan Pablo Picasso > wrote: > Como hablé con Hernán, me parece interesante lo > de clonar objetos que no sean clonables, asi que si > les parece me prendo con eso. Como es el tema de las > tasks, como/donde figuraría/me anoto? > > saludos, > JP __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ |
|
From: Juan P. P. <jua...@es...> - 2003-12-09 11:44:11
|
ok, de aspectos algo (alguito mejor dicho) charl=E9 con nico una vez, de =
BCEL todo lo que se es que son 4 letras. pero, investigar=E9, =
evaluar=E9, comentar=E9, y con un poco de suerte lo har=E9!=20
che, esta lista cuando pones reply, manda mail al remitente posta, y no =
a la lista :-/
de alguna manera me llego tres veces el mail, por qu=E9 lo mandaste a mi =
mail, a tadp y ac=E1?
saludos,
JP
----- Original Message -----=20
From: Hernan Liendo=20
To: Juan Pablo Picasso ; tadp ; ObjectBase SF=20
Sent: Monday, December 08, 2003 9:03 PM
Subject: Re: [Objectbase-devel] clonando lo inclonable
Perd=F3n por la demora. Mi nueva distro est=E1 finalmente instalada. =
(aprovecho para maxirecomendar gentoo, junto con Joe, the cow)
Las tareas se manejan desde SF.
Lo que requiere voluntarios actualmente es lo relacionado con =
manipulacion de bytecode: BCEL o aspectos.
En estos dias no hay nadie que pueda decir cual de los dos es mas util =
para nosotros asi que es parte de tu trabajo evaluarlos.
Por ahora hay 3 cosas (aunque se vienen muchas mas) que tenemos que =
hacer con bytecode:
1) clonar lo inclonable
2) serializar no inserializable
3) atrapar llamadas a metodos de objetos no-nuestros
que comience la funcion!
On Sat, 2003-12-06 at 13:25, Juan Pablo Picasso wrote:=20
Como habl=E9 con Hern=E1n, me parece interesante lo de clonar =
objetos que no sean clonables, asi que si les parece me prendo con eso. =
Como es el tema de las tasks, como/donde figurar=EDa/me anoto?
=20
saludos,
JP |
|
From: Hernan L. <her...@de...> - 2003-12-09 03:03:14
|
Perdón por la demora. Mi nueva distro está finalmente instalada. (aprovecho para maxirecomendar gentoo, junto con Joe, the cow) Las tareas se manejan desde SF. Lo que requiere voluntarios actualmente es lo relacionado con manipulacion de bytecode: BCEL o aspectos. En estos dias no hay nadie que pueda decir cual de los dos es mas util para nosotros asi que es parte de tu trabajo evaluarlos. Por ahora hay 3 cosas (aunque se vienen muchas mas) que tenemos que hacer con bytecode: 1) clonar lo inclonable 2) serializar no inserializable 3) atrapar llamadas a metodos de objetos no-nuestros que comience la funcion! On Sat, 2003-12-06 at 13:25, Juan Pablo Picasso wrote: > Como hablé con Hernán, me parece interesante lo de clonar objetos que > no sean clonables, asi que si les parece me prendo con eso. Como es el > tema de las tasks, como/donde figuraría/me anoto? > > saludos, > JP |
|
From: Juan P. P. <jua...@es...> - 2003-12-06 16:25:53
|
Como habl=E9 con Hern=E1n, me parece interesante lo de clonar objetos = que no sean clonables, asi que si les parece me prendo con eso. Como es = el tema de las tasks, como/donde figurar=EDa/me anoto? saludos, JP |
|
From: Juan P. P. <jua...@es...> - 2003-12-06 16:20:45
|
Bueno, aqu=ED estoy, let the fun begin. saludos! JP |
|
From: Hernan L. <her...@de...> - 2003-11-27 00:24:20
|
En base a esto, que ya está algo charlado, vamos a continuar la
discusión esta noche para determinar como implementar la interface de
persistencia.
Actualmente tenemos dos implementaciones dummy pero con interface final
de queries.
Como para empezar tengo lo siguiente:
1) Necesitamos proxies dinamicos.
Cuando se consigue un collection de objetos, estos deben ser proxies
locales (en la misma maquina virtual cliente) a objetos clonados de la
base.
Necesitamos ver que vamos a utilizar para implementar estos
dyna-proxies. BCEL, aspectos? - lo importante, no y no esperar que los
objetos sean beans.
2) En principio un proxy tiene estos atributos privados:
Object cloneObject; // referencia a una copia del objeto al que se
proxea
int iVersion; // la version del server del objeto que
se clono. cuando se persista, se verificara que la version es la misma,
luego se la incrementara. Si la version no es la misma, Exception por la
cabeza
UUID remoteReferenceID; //una referencia que identifica univocamente
al objeto para comunicacion con el server.
3) En estos dias me estoy empezando a hartar del pattern decorator
(chan!). Que PersistentCollection implemente Collection me parece un
error grave. Porque tengo que implementar metodos como add, containsAll,
retainAll, contains cuando no aplican.
4) A PersistentCollection le agregaria los metodos:
void destroy(Object);
Object publish(Object);
Collection publish(Collection);
Nos vemos
|
|
From: Jorge C. <jor...@ya...> - 2003-11-24 17:48:52
|
http://objectkitchen.narcissisme.dk/ __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ |
|
From: Hernan L. <her...@de...> - 2003-11-24 12:06:01
|
Ja, usemos este mail mejor. Me alegra que estes calentito por empezar. Te voy contestando abajo. Liendo, la cuenta regresiva a comenzado... se acerca el dia en que empiece a meter mano en objectbase. Ya firme dos materias, el martes rindo la ultima, despues un final, y listo. Vamos, necesitamos mas ingenieros barderos. Por lo pronto, ayer me baje el proyecto del cvs, con usuario anonimo, porque no estoy autorizado, asi que anda incluyendome, mi usuario es jfernandes. Listo. Estuve mirando un poco lo que hicieron, igual tendriamos que hablar despues, para estar bien en tema. Vi que hay unos cuantos TODO asi que decime si queres que haga algo, y estuve mirando que hay una notacion (puede ser??) al viejo estilo de librerias de c con el "_", podrias documentar eso ;-) asi no hay que andar cambiando todo despues. Si, yo tengo una estandar bien definido que viene heredado en su mayoria de Campos. Igualmente no se hasta donde le gusta a todos, este es uno de los temas a resolver. Si se te ocurre algo avisame. Yo tengo basicamente 3 ideas para codificar: 1) El codigo se tiene que poder leer mas facil que un documento. Si hay algo que lleva mas de 30 segundos entender, esta mal programado 2) las variables siempre describen su tipo. 3) los _ indican variables de scope method. Me llamo la atencion el TODO de "resolvAttribute" de la clase ReflectionUtils, que idea tenes para ese metodo?? me interesa ;-P En realidad ya esta resuelto con un metodo de common-beans que utiliza struts para resolver la notacion "persona.document.tipo" haciendo reflection. Si queres desarrollar, tenemos que ver por donde. En principio de mi parte no tengo mucho como para delegar porque no es tan grande y esta en pleno refactoring. ya cambie a 4 versiones desde que empece. Sin embargo, tenemos muchisimo trabajo que hacer. Si queres desarrollar te pasamos las opciones. Igualmente para empezar, leete todo el wiki y mira todo el codigo. Seguramente vas a encontrar cosas para cambiar. Avisanos antes de tocar porque por ahora estos modulos son de una persona. Cuando estes listo te tiramos algunos modulos para que elijas que hacer.\ Abrazo. On Sun, 2003-11-23 at 22:19, CJ F wrote: > No me di cuenta y te mande un mail a la cuenta pepino, asi que fijate (por > las dudas si no la usas a esa cuenta) > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus > |
11 messages has been excluded from this view by a project administrator.
