Encapsulamiento en Forms

[[AgustinOrtu]]

Me extraña un poco no leer en estos mensajes tan interesante nada acerca de las Acciones

Cierto, pero tienen un problema.

La aplicacion esta constantemente realizando los chequeos (esta todo el tiempo recorriendo los ActionList y ejecutando los eventos OnUpdate), lo cual puede terminar siendo un gasto innecesario

Saludos

[roman]

No me parece un argumento sólido. En cualquier aplicación siempre hay algo recorriendo los controles y verificando cosas (ya seamos nosotros mismos o el sistema operativo). Desde luego, si las validaciones son muy complejas (como, por ejemplo, incluir consultas a base de datos) se puede ver afectado el rendimiento de la aplicación, pero bien utilizadas no tiene por qué dar problemas. Y, al final de cuentas, las acciones resumen mucho de lo que uno termina programando en aras de evitar lo que comentas desde un principio.

LineComment Saludos

[[AgustinOrtu]]

Sigo pensando que exponer un metodo es mejor

Como ejecutas una accion desde afuera del form en cuestion?

[roman]

Ah, pero es que yo no estoy peleado con lo que propones. Su usamos el manejador de una acción para todo, terminamos simplemente traslandando el problema a otro lugar.

De todas formas, habría que ver las justificaciones en cada caso particular para llamar desde el exterior un determinado método. Por ejemplo, ¿por qué llamar al método GuardarArchivo? No digo que sea el caso, pero posiblemente GuardarArchivo no debería ser, en primera instancia, un método del formulario, sino de otro objeto al cual llama el formulario. Es decir, ¿por qué anexar el método final para guardar un archivo a la interfaz de usuario que pregunta dónde guardarlo? Repito, no es que sea el caso, pero habría que ver en cada situación las justificaciones.

LineComment Saludos

[[AgustinOrtu]]

Yo tampoco estoy peleando, es simplemente un intercambio de ideas

Estoy de acuerdo con lo que propones:

Código Delphi [-]
type
  IGuardadorDeArchivos = interface
    procedure GuardarArchivo(const Ruta: string);
  end;


...

var
  Form: TAlgunForm;
  GuardadorDeArchivos: IGuardadorDeArchivos;
begin
  GuardadorDeArchivos := TGuardadorDeArchivos.Create;
  Form := TAlgunForm.Create(Self, GuardadorDeArchivos);
end;

// en algun otro punto se puede disparar esto

procedure
begin
  GuardadorDeArchivos.GuardarArchivo('C:\nueva carpeta\');
end;

Eso es genial, pero lo que a mi me molesta es que si yo quisiera, podria hacer esto:

Código Delphi [-]
procedure
begin
  Form.ActionList1.Actions[0].ExecuteTarget(NIL);
  Form.ActionGuardarArchivoExecute({hay que mandar un parametro sender ¡?¡?¡?¡});
end;

La "solucion" es meter el ActionList en la parte privada del form e instanciarlo en runtime

Pero es muy incomodo, a todos nos gusta diseñar forms con el IDE; por codigo es mucho mas tedioso (una subclase de TForm es "posible" manejar el layout de todo los controles por codigo, pero cuando estas por los tataranietos de TForm?? se hace imposible)

Código Delphi [-]
type
  TFormAlgo = class(TForm);
    // todo lo que esta desde aca hasta el "private" es accesible desde afuera! esto me molesta mucho
    edRutaArchivo: TEdit;
    btnAceptar: TButton;
    btnCancelar: TButton;
  private
  end;

[roman]

Empezado por AgustinOrtu

Yo tampoco estoy peleando, es simplemente un intercambio de ideas

Ja, ja. Nunca quise decir que estuviéramos peleando. Dije:

Empezado por myself

Ah, pero es que yo no estoy peleado con lo que propones

como una forma de decir que no estoy en desacuerdo. Otra cosa habría sido decir:

Empezado por myself

Ah, pero es que yo no estoy peleando contigo

LineComment Saludos

[mamcx]

Empezado por roman

En cualquier aplicación siempre hay algo recorriendo los controles y verificando cosas

.... si las validaciones son muy complejas (como, por ejemplo, incluir consultas a base de datos) se puede ver afectado el rendimiento de la aplicación

Claro que es así. El asunto no es de posibilidades, sino de comodidad , pero mas importante, de claridad y que el código sea correcto.

El problema de la GUI es que los datos se "mueven" en el tiempo, y esto muta los objetos. Mantener la coordinación requiere moverse entre varios lugares (que cierto que acciones y demás cosas ayudan). La idea aqui es como evitarlo? Como centralizarlo? Como "aplanar" el proceso?

-----
Pensemos por ejemplo, en el caso de la pantalla de login, que ademas chequea en tiempo real si el usuario ya esta tomado, y obtiene el gravatar de ese correo. Debe ademas actualizar la interface de forma correcta, no interrumpir y que ademas cuando le de "Login" cancele cualquier solicitud de red pendiente.

En un estilo tipico, esto seria relativamente engorroso de hacer. Veamos como es al estilo de "Programacion Reactiva". Me perdonan la syntaxis inventada pero me di cuenta que si lo hago en otros lenguajes le puedo meter cosas que tocaria explicar.

Código PHP:

FetchNetwork = Events.
    ([email], TextChange)
    .each(function edit, event
        return IsValidEmail(edit.text)
    //Ejecutar concurrentemente las llamadas de red, sin esperar la anterio
    ).nextAsync(function edit
        fetchGravatar(edit.text)
    ).nextAsync(function edit
        isEmailTaken(edit.text)
    //Cuando obtengo ambas respuestas...
    ).merge(function img, isTaken
        if isTaken
            return False

        form.imgUser.Load(img)

        return True
    )
//Password parecen validos, y son iguales
IsValidPass = Events.
    ([Pass1, Pass2], TextChange)
    //Por cada control...
    .each (function edit, event
        return IsValidPassword(edit.Text)
    )
    .merge()
    .filter(function result1:bool, result2:bool
        //Si son iguales
        result1==result2
    )

//Combino todo
Loop = Events.([IsValidPass, FetchNetwork])

//Cuando login Ok, cancelo el proceso de eventos

Loop.Stop() 


La parte importante, es que se puede hacer composicion de eventos, que estos hacen cascada y que solo continuan cuando el anterior tiene exito (o saca error, y se va al manejo de errores), por lo tanto, si esto en .filter(function result1:bool, result2:bool) ya se con certeza que las claves son validas y solo queda averiguar si son iguales. Se tengo que agregar otros edits no hay problema, y como puede hacer composicion y combinan eventos, puedo generar una libreria de soluciones universales y re-combinar al gusto.

El estilo anterior tiene la contra de que es un monton de callbacks y eso se pone algo pesado a la vista. Es mucho mas limpio si se hace con Communicating sequential processes, pero lastima no hay mucho de eso en el mundo GUI.

El asunto es que se requiere algo de ayuda del lenguaje para que sea natural de operar.

[Ñuño Martínez]

No olviden que no es necesario programar "en visual". Me explico: crear componentes con código. Puedes crear toda la aplicación sin usar el diseñador ni los recursos, haciendo herencia, poniendo los componentes en la sección PRIVATE de nuestros objetos de ventana... Mucho más OO, y encima genera ejecutables más pequeños.

[[AgustinOrtu]]

Claro que se puede, pero es más difícil

Diseña un reporte con una línea de herencia de 3 o 4 clases, vamos que no está fácil