cual es la mejor forma de llamar a un formulario de modificación de datos

[[Chris]]

Empezado por roman

La diferencia debiera darla quien abre la ventana poniendo el dataset en modo de edición o de inserción.

Terminarías repitiendo código Román. Tomé este diseño por la experiencia. Si quieres crear un nuevo registro, solo falta con:

Código Delphi [-]
TClientesViewer.NewRecord(Self);

Una simple línea de código.
Si lo que quieres modificar otro registro, también solo faltará con una simple línea de código

Código Delphi [-]
TClientesViewer.ShowRecord(Self, Table1.Fields['id'].AsString);

Empezado por roman

A la ventana de edición de registro debería darle lo mismo si está editando un registro existente o uno nuevo.

En cierta forma así es. Prácticamente lo único que hacen los constructores es adaptar la interfaz de la ventana para ligeramente diferenciarse entre modificación o inserción de un registro.

Saludos,
Chris

[roman]

Empezado por Chris

Terminarías repitiendo código Román.

No veo por qué. Se requiere una sóla línea de código para poner en modo de edición o de inserción al dataset. Normalmente, dicho código lo colocaría yo en el evento Execute de una TAction, lo cual te permite llamar al mismo código desde varios lugares. En dicho evento puedes colocar cualquier otra cosa que haga falta para personalizar el visor.

Como dije antes, en mi opinión, es un error de diseño dejar a la clase visora la tarea de escoger ese menester pues, para empezar, dicha clase debería ser agnóstica del dataset.

// Saludos

[[Chris]]

Empezado por roman

No veo por qué. Se requiere una sóla línea de código para poner en modo de edición o de inserción al dataset. Normalmente, dicho código lo colocaría yo en el evento Execute de una TAction, lo cual te permite llamar al mismo código desde varios lugares. En dicho evento puedes colocar cualquier otra cosa que haga falta para personalizar el visor.

Como dije antes, en mi opinión, es un error de diseño dejar a la clase visora la tarea de escoger ese menester pues, para empezar, dicha clase debería ser agnóstica del dataset.

// Saludos

En correcto lo que dices Román. Lo que sucede es que en mi aplicación existe más de un visor de registro. A cómo dice en un comentario anterior, existe la clase TBaseViewer que es el ancestro de todos lo visores. Dicha clase ya te imaginarás que implementa lo básico y general, dejando algunas cosas como "virtual" para que los herederos puedan personalizar.

Al haber más de un tipo de visor (cada uno con su ligeras diferencias) he preferido utilizar la estructura que os he mostrado. Si hubiese utilizado acciones a cómo mencionas, hubiese terminado repitiendo código para cada uno de los tipos de visores.

Saludos,
Chris

[roman]

Empezado por Chris

Al haber más de un tipo de visor (cada uno con su ligeras diferencias) he preferido utilizar la estructura que os he mostrado. Si hubiese utilizado acciones a cómo mencionas, hubiese terminado repitiendo código para cada uno de los tipos de visores.

¡Ah! Pero eso es otra cosa. Si tienes varias clases de objetos a editar, desde luego que puede resultar conveniente tener una jerarquía de ellos. Pero aún así, no veo porqué dejar al visor la decisión de escoger entre inserción y edición.

// Saludos

[[Chris]]

Empezado por roman

¡Ah! Pero eso es otra cosa. Si tienes varias clases de objetos a editar, desde luego que puede resultar conveniente tener una jerarquía de ellos. Pero aún así, no veo porqué dejar al visor la decisión de escoger entre inserción y edición.

// Saludos

Es que el visor no hace la elección. Es el "caller" al llamar a uno de los constructores previamente descritos. Aunque no sería tan malo dejar al visor hacer la decisión también. Los modelos de Django lo hacen así

Saludos,
Chris

[roman]

Empezado por Chris

Es el "caller" al llamar a uno de los constructores previamente descritos.

Ja, ja. Entonces, si el caller hace la distinción, ¿para qué quieres dos constructores? Digo, quizá es que tus visores son muy distintos si se trata de edición o de inserción, y hay que hacer mucha inicialización según el caso. Pero para mi gusto, como dije al pricipio, un tal visor debería actuar prácticamente igual en cualquiera de los dos casos, salvo por algún detalle menor.

// Saludos

[[Chris]]

Empezado por roman

Pero para mi gusto, como dije al pricipio, un tal visor debería actuar prácticamente igual en cualquiera de los dos casos, salvo por algún detalle menor.

Realmente las diferencias en cada modo son detalles menores, que bien se podrían expresar en tres o cuatro líneas de código. Pero aunque sean ese poco número de líneas, ya es algo! Y hay que concentrarlas en un solo lugar. Sino habrá que repetir esas cuatro líneas para cada clase de visor. Aparte, no sabes si en un futuro esas cuatro líneas puedan convertirse en 8 y después en 15 y así sucesivamente.

Saludos,
Chris

[novato_erick]

jajaja calma chicos mi idea no era llegar a una polémica de técnicas empleadas cada una es interesante.... al fin al cabo el embrollo que he creado se resume en el titulo que presenté al iniciar el hilo.

Hey gracias por compartir sus experiencias...

Me dijo roman

Por otra parte, creo que sería mejor mostrar la ventana con ShowModal, a menos que haya alguna razón especial que no conozco.

lo hago porque como veras en el codigo

Código Delphi [-]
procedure TFrmPrincipal.AgregarExecute(Sender: TObject);
begin
 FrmCliente := TfrmCliente.create(FrmCliente);
 Try
      FrmCliente.Parent := FrmPrincipal.Panel4; // el formulario que llamo se pega al panel
      FrmCliente.Caption := 'Clientes';// 
      dmacceso.cdsClientes.Active := True;
      dmacceso.cdsClientes.Insert;
      FrmCliente.Show;
 Finally
         If FrmCliente.Caption <> ' ' then
           Begin
              FrmPrincipal.TabSet1.Tabs.add(FrmCliente.Caption);// en el tabset muestra el caption de mi formulario
              FrmPrincipal.TabSet1.TabIndex := FrmPrincipal.TabSet1.Tabs.Count - 1;
           end;
      end;
 //utiles.MuestraVentana('Clientes','Normal');
end;

si lo hago con

Código Delphi [-]
frmClientes.showmodal

, mi formulario se pega en el panel pero no me deja hacer nada en mi aplicación...

Tambien roman

De hecho, ¿por qué frmCliente tiene un botón Modificar y uno Guardar? Yo pondría sólo el botón Guardar que sirve para lo mismo en ambos casos (inserción y edición)

porque si lo dejo en insert me crea otro registro con el mismo nombre y como le tengo evitar duplicidad de datos me manda error...

dijo oscarac
no es mi intención desanimarte

desanimarme para nada. Ese termino lo utilizo cuando alguien desea algo pero solamente cree que hay una forma de hacerlo. Yo en cambio no me importaría tomar otras opciones para lograrlo al fin al cabo terminar lo que deseo es mi objetivo principal. y ustedes tienen mas experiencia que yo. ténganlo por seguro que los leeré...

Saludos

[roman]

Empezado por novato_erick

jajaja calma chicos mi idea no era llegar a una polémica de técnicas empleadas cada una es interesante....

Exactamente. Y si no hubiera habido polémica no nos habríamos enterado de las distintas técnicas.

Dicho de otra manera, polemizar no tiene nada de malo. Sirve para aprender nuevas cosas.

// Saludos

[roman]

Empezado por novato_erick

si lo hago con

Código Delphi [-]
frmClientes.showmodal

, mi formulario se pega en el panel pero no me deja hacer nada en mi aplicación...

No soy yo quien para juzgar tu diseño, pero nunca he sido fan de encajar formularios dentro de otra ventana. Por otra parte, ¿realmente deseas hacer otra cosa mientras tienes abierto el formulario de edición de datos?

Claro que quizá tengas una necesidad especial de diseño o requerimiento, pero para mi gusto, un formulario para editar un registro debe ser modal y justamente no permitirte hacer nada más durante la edición.

// Saludos

[novato_erick]

Ya me estoy dando cuenta a tropezón en los problemas que causa usar formularios encajados en ventana (Se comportan extraño) y me limita a muchas cosas mas.

En cuanto el porque lo requería de esa manera es que el usuario deseaba que trabajara como Los exploradores de Internet, que puedes usar muchas pestañas y hacer varias cosas. solamente trasladándote por pestañas tenia a mano varios formularios (los mas usados).

Ese es el porque se esta trabajando de esa manera.

y tranquilo, siempre las criticas las recibo como algo positivo, y como dijo caral, a base de experiencia llegare a ser como varios de ustedes... .


lo que hice es que los formularios principales los uso con pestañas, pero si tengo que llamar los formularios de modificación ahí si no lo hago con pestaña... envió un ejemplo de lo que hice:

Código Delphi [-]
class function TfrmCliente.Execute: Boolean;
var
  frmCliente: TfrmCliente;
begin
  frmCliente := TfrmCliente.Create(nil);
  try
    Result := frmCliente.ShowModal = mrOk;
  finally
    frmCliente.Free;
  end;
end;

mas adelante seria agradable poner a funcionar los requerimientos solicitados por mis usuarios.


Saludos;

[[Chris]]

Empezado por roman

No veo por qué. Se requiere una sóla línea de código para poner en modo de edición o de inserción al dataset.

Román, no me quedaba claro porque insistías en que para el visor de registro le debería dar igual si está editando o creando un nuevo registro. Igual, no se necesitaba mucho código. Ahora me doy cuenta que desde tu punto de vista tenías toda la razón de pensar así. Pero en mi caso, no es conveniente hacerlo y sí se requieren de los dos constructores. Ahora te explico:

Había pecado en no mencionarte que los visores no trabajaban con el mismo TDataset que utilizan los exploradores. Por ejemplo un explorador de clientes trabaja con un Dataset que mediante SQL solo descarga los campos absolutamente necesarios (los mostrados en la regilla y uno que otro). Talvez solo utilicen 4 ó 5 campos de un total de 20 que puede tener la tabla. Los visores son ya otra cosa. Ellos sí necesitan todos o casi todos los campos de la tabla. Es por eso que necesitan de otro TDataset que trabaja con SQL.

El código de los constructores no es simplemente "Dataset.Edit;" o "Dataset.Insert;". Su código es un poco más sofisticado -por decirlo de cierta manera-. Inclusive, una de las primeras cosas que hacen es determinar los privilegios del usuario. También adaptan el SQL para solamente descargar del servidor el campo que se va a modificar, o abrir el TDataset sin descargar ningún dato si es que se creará un nuevo registro.

Esa es la razón por la que existen dos constructores. Códigos completamente aislados para dos própositos distintos que requieren de una lógica especial para cada caso. Talvez ahora me puedas entender en el por qué he insistido en la necesidad de tener dos constructores según la operación que se valla a realizar.

Por último, no me quiero despedir sin antes darte las gracias por tan buen agradecimiento que has hecho Erick a los que hemos participado en este hilo. Uno sería más feliz si todos los que aquí consultan tuvieran semejante don del agradecimiento a cómo lo tienes. Te lo digo porque me he topado con personas que ni siquiera te dicen un "gracias" al final. Pero bueno, uno también al final lo hace por "amor al arte"

Saludos,
Chris

[roman]

Hola Chris,

Yo sigo sin ver del todo la necesidad de los dos constructores. Bueno, entiendo que tengas razones para hacerlo y seguramente tienes razón, pero tu argumento de los distintos dataset no me convence .

Yo también uso datasets distintos según si son para mostrar una lista de registros o si son para editar un registro. Aquí un ejemplo extraido de un caso real:

Inserción:

Código Delphi [-]
begin
    with TSolicitanteEditorForm.Create(Self) do
    begin
        SolicitudesDm.QSolicitante.Open;
        SolicitudesDm.QSolicitante.Append;

        if ShowModal = idOk then
        begin
            Self.txtRfc.Text := SolicitudesDm.QSolicitante['rfc'];
            Self.txtApellidos.Text := SolicitudesDm.QSolicitante['apellidos'];
            Self.txtNombre.Text := SolicitudesDm.QSolicitante['nombre'];
        end;
    end;
end;

Edición:

Código Delphi [-]
var
    SolicitanteId: Integer;

begin
    SolicitanteId := QSolicitantesSesion['solicitante_id'];

    SolicitudesDm.QSolicitante.Close;
    SolicitudesDm.QSolicitante.ParamByName('id').AsInteger := SolicitanteId;
    SolicitudesDm.QSolicitante.Open;

    with TSolicitanteEditorForm.Create(Self) do
    begin
        SolicitudesDm.QSolicitante.Edit;

        if ShowModal = idOk then
        begin
            QSolicitantesSesion.Refresh;
            QSolicitantesSesion.Locate('id', SolicitanteId, []);
        end;
    end;
end;

En ambos casos se usa una dataset específico (QSolicitante) para editar los datos que se pone en modo de inserción o edición según la operación, y esto lo hace quien llama, no el editor en sí.

En el evento Show del formulario de edición se hace una ligera distinción entre edición e inserción:

Código Delphi [-]
procedure TSolicitanteEditorForm.FormShow(Sender: TObject);
begin
    if dsSolicitantes.DataSet.State = dsInsert then
        Caption := 'Nuevo solicitante'
    else if dsSolicitantes.State = dsEdit then
        Caption := 'Datos del solicitante';
end;

pero el resto del formulario funciona igual tanto en uno como en otro caso. Aun suponiendo que tuviera muchas distinciones entre inserción y edición (que, insisto, no veo porqué habría de ser así) haría algo como esto:

Código Delphi [-]
procedure TSolicitanteEditorForm.FormShow(Sender: TObject);
begin
    if dsSolicitantes.DataSet.State = dsInsert then
        InicializaInserción()
    else if dsSolicitantes.State = dsEdit then
        InicializaEdicion();
end;

// Saludos

[[Chris]]

Empezado por roman

Hola Chris,

Yo sigo sin ver del todo la necesidad de los dos constructores. Bueno, entiendo que tengas razones para hacerlo y seguramente tienes razón, pero tu argumento de los distintos dataset no me convence .

Hola Román!

Aparte de los Datasets separados también hubieron otras razones por la que tomé este diseño. Uno de ellos era independizar al máximo el visor del explorador y viceversa. Es así porque necesitaba que cualquier parte de la aplicación pudiera, con la mayor simplicidad posible, llamar al visor en modo de inserción/edición o simplemente vista. No solamente los exploradores.

Otra de las razones es que en mi aplicación, los visores no se muestran en forma modal (requerimiento auto impuesto por usabilidad). Esto ocaciona que el explorador no pueda "quedarse esperando" a que un usuario ingrese o modifique un nuevo cliente por ejemplo. Cuando los visores hacen un cambio a la base de datos, lo notificacan a toda la aplicación por medio de Mensajes de Windows. Así el resto de módulos pueden decidir si procesar o no la notificación. Algo muy similar a cómo funcionan ciertas partes de la API de Windows.

Este diseño me ha dado mucha independencia y agilidad para desarrollar nuevo módulos. Ya que los exploradores y visores descienden de una clase base que implementa lo básico para cada uno, los herederos simplemente solo implementan lo que es específico para el tipo de dato con el que trabajan.

Saludos,
Chris