Viajando em Rails & Delphi

Olá Galera,

Este é o meu primeiro post aqui, por isso vou me apresentar rapidamente e ir direto ao assunto.
Meu nome é Anderson, eu sou desenvolvedor há 18 anos e uso o Delphi desde a versão 1 mas já programei em C, C++ e Clipper e VBA (shame)

Há anos eu venho namorando o Ruby e RoR, mas nunca tive tempo e dedicação necessária para realmente aprender a ferramenta. Agora, estou estudando e estou me apaixonando pela combinação Ruby & Rails. Apesar de ter um bom conhecimento de OOP ainda estou me acostumando com este mundo completamente novo.

Agora entrando no assunto do Título (E por ser um delírio eu to postando aqui no Lero-Lero).

Eu estou aprendendo a usar o Rails, mas não consigo deixar de pensar como este modelo de trabalho seria útil no desenvolvimento de aplicações Desktop usando um mecanismo de GUI desenvolvido em Delphi para interfacear com Rails.

Percebo que aqui tem muita gente que já programou em Delphi e sabe do potencial que esta ferramenta AINDA tem para criar aplicações ricas e belas interfaces gráficas no windows, e o Rails está altamente vinculado ao browser.

Então imaginem a seguinte situação:

Um frontend escrito em delphi interfaceado com um servidor rails.

No modelo MVC o M(odel) & o C(ontroler) seriam feitos em Ruby e o (V)iew seria feito através de uma ferramenta que utilizasse o melhor do delphi para “renderizar” a aplicação no Desktop.

Todas as regras de negócio e o ORM seria Ruby e um sistema de templates seria enviado para este frontend rico que poderia utilizar todos os recursos já disponíveis no Delphi. (para os programadores delphi: Já imaginou uma aplicação Ruby usando Quantum Grid e TChart e outras maravilhosas ferramentas/componentes do delphi?)

Este mecanismo de View, deveria receber os dados do Model (talvez em XML) e jogar nos controles e depois fazer o caminho inverso. (Poderíamos até mesmo imaginar as validações de cliente sendo feitas em Ruby dentro deste frontend)

Esta parte em Delphi, deveria ser o mais “fina” possível, fazendo simplesmente a GUI mas todas a inteligencia do sistema seria feita no Rails.

E o mecanismo de interface passaria tudo o que fosse necessário para que o frontend pudesse desenhar a app (Como dados de um dicionário de dados) abandonando todos os mecanismos de acesso a dados do Delphi.

E aí? Alguém consegue imaginar esta pira?

Valeu!

Isso tudo que vc imaginou já existe e se chama ActiveResource =). Dá uma googlada pra entender melhor como funciona.

Não sei como seria para fazer integração Delphi => ActiveResource… e mesmo assim, não estou vendo muita vantagem… hoje nós temos frameworks muito bons pra criar GUI’s ricas no brownser, como extjs e sproutcore, que deixam a app com “cara” de desktop. Obviamente não temos o mesmo controle que no desktop, mas pelo menos no quesito tela, já fica bem parecido.

Valeu Fernando,

Eu nao conhecia estas bibliotecas, são muito interessante. Gostei principalmente do sprouts

Mas o que eu estava pensando era realmente uma coisa bem desktop, com controle total sobre a GUI. Mas talvez isso seja só coisa de um dinossauro acostumado com um mundo off-line que ainda acha que algumas coisas devem ser feitas fora do browser.

Nao entendi muito bem o uso dos ActiveResources, “googlei” mas não achei nada que fizesse muito sentido para um novato como eu. Mas pelo que eu entendi, tem a ver com REST e acho que provavelmente REST&XML seriam o melhor meio para transferir dados entre o cliente(view) e o servidor (controller) na forma de mensagens que seriam facilmente entendidas pelos dois lados.

De qualquer modo, valeu pela idéia. E se alguem tiver mais alguma, fique a vontade, estamos na área de abobrinhas, então, qualquer coisa vale.

PS: Esta idéia na verdade vale para qualquer outra ferramenta RAD e nao somente o Delphi. O principal seria o estabelecimento de um protocolo de comunicação onde fossem definidos os dados e controles a serem renderizados no cliente. (Um tipo de protocolo GUI). A partir deste protocolo, qualquer um poderia implementar em Delphi, Java ou .NET.

Imagine View Desktop recebendo do Controler rails algo assim (estilo YAML para facilitar a leitura):

login{

  type: dialog 

  caption: “Autenticação”

  username {caption:“Nome de Usuário” type:text control:edit     required}

  password {caption:“Senha”           type:text control:edit     hidden}

  savepass {caption:“Lembrar de mim”  type:bool control:checkbox default=0}

}

Ao fim da edição pelo View, o Controler receberia de volta:

login{

  username: “admin”

  password: “minhasenha”

  savepass: 1

}

Este é só um exemplo grosseiro, mas aqui poderia caber muita coisa interessante como validação, titulos, máscaras de edição e outras coisas vindas diretamente do Model do Rails.

Caberia ao GUI decidir como implementar cada controle (form, label, edit, checkbox, grids e etc) e devolver a resposta editada na forma de um YAML, XML ou REST.

Imagine só um Scaffold GUI feito automaticamente pelo sistema? Com menus e telas de edição? Imagine mudar o Model e ter o GUI alterado automaticamente?

Note que no exemplo imaginado, o Controler passa uma “dica” do tipo do controle que recomendado para aquele dado.

Em última instância, o cliente (View) seria só um tipo de runtime desktop do rails.

IMPORTANTE: O que está em discussão aqui é o PROTOCOLO DE COMUNICAÇÃO VIEW/CONTROLER e não o aplicativo que irá implementar o mesmo.

Como vc falou, é necessário usar algum protocolo pra comunicacão, e aí vc tem várias opcões, o REST é uma delas. Definindo o que vc vai usar pra comunicacão, aí é definir tua API. Essa API pode ser consumida por qualquer linguagem, é só vc documentar corretamente quais os parâmetros, formato deles, quais são obrigatórios, o que é retornado, etc.

Pegue o twitter como exemplo. A API deles é REST, e tem clientes pro twitter em praticamente qualquer linguagem. Qualquer um que quiser escrever um cliente pro twitter consegue, bastando consultar a documentacão da API (e por não ser tão complicado, tem centenas por aí xD).

O ActiveResource é uma maneira à lá ActiveRecord de consumir API’s REST no estilo Rails, mas não é o único, se vc for no github e pesquisar por “rest client” vai encontrar um monte, e pra várias linguagens =).

Sobre aquele esquema da view desktop receber informacões sobre os campos a serem exibidos, eu não gosto dessa idéia… se vc já conhece a API, sabe quais dados são obrigatórios, formato, etc. É responsabilidade SUA escrever a view da forma que lhe convir. Isso porque o cara que escreveu a API não tem detalhes como o formato de data/números de onde vc está, se vc vai usar alguma máscara, e por aí vai. Voltando ao twitter, imagine se eles tivessem que fazer isso pra cada formato de data usado em cada país ;)

Isso não quer dizer que não seja possível fazer, mas em caso de API’s EU não acho interessante.

Pois é,
Apesar dos detalhes de implementação da API/protocolo Você ve utilidade nisso?

Eu pergunto, porque acho que este tipo de coisa deveria amplamente discutida par se avaliar o custo e a utilidade da idéia. Mas em suma seria fazer no desktop o que o DHH fez com o rails (convention over configuration), um padrão simples que funcione e que seja reconhecido por todos como útil e eficiente.

Esta idéia é simples e um sonho que eu nutro há muito tempo: uma forma de prototipação imediata que seja praticamente passível de uso. Uma vez definido o modelo de dados, o aplicativo já pode ser experimentado mesmo que de forma rústica com informações vindas do servidor. Por exemplo digamos que tenhamos uma tabela com chave auto-referenciada (uma árvore, como um plano de contas) isso poderia ser explicitado no protocolo CONTROLER/VIEW de forma a dar a entender ao VIEW que isso seria melhor representado por um treeview.

Como você mesmo disse, se o protocolo for bem definido, a implementação é coisa simples, cada um faz como quiser mas a base seria uma só para todos.
Uma pergunta do novato: O rails sozinho já tem (ou pode ter) todas estas informações de metadados? Isso já é definido no model? Título do campo por exemplo é possível definir já no model?

Quanto às mascaras eu sinto que aí há uma controvérsia, e acho melhor adicionar a isso no no “server side” imagine que estamos tratando de CPF/CNPJ por exemplo. Quem tem mais autoridade para definir o formato de exibição/edição? o Cliente ou o servidor?

Ao meu ver, isso é uma atribuição de ambos, apesar de o servidor ter a última palavra/responsabilidade na validação, normalmente o cliente é o melhor lugar para se fazer verificações de dados, por isso normalmente a gente faz isso nos dois lados não é mesmo? Cautela e canja de galinha não faz mal a ninguém.

Então, o calculo do digito verificador seria uma coisa a ser feita nos dois lados. Agora imagine que junto com os metadados venha um script de calculo mod11 para ser interpretado pelo cliente na validação por exemplo.

Nos casos de data eu concordo que é responsabilidade do cliente já que isso varia de lugar para lugar e o armazenamento normalmente é numérico. Mas os ranges por exemplo também é atribuição do servidor (por exemplo definir que data de faturamento não pode ser no futuro ou passado é uma coisa que deve ser definida no modelo e não no cliente.

Mas eu vejo vantagem em o servidor passar informações como titulos de campo por exemplo. De forma que a interface só mostrasse o que vier do servidor. Uma forma de usar o reflection do Model para implementar o cliente.

Gostaria de ouvir a opinião de todos, então se você chegou até aqui e acha isso tudo uma grande bobagem, por favor, diga porque, ou se ao contrário você gostou da idéia, gostaria de ouvir em que sentido você acha que isso é bom.

Valeu!

Acho que o nome disso que vc quer é MDA mas nunca vi nada sobre isso na prática…

Uma pergunta do novato: O rails sozinho já tem (ou pode ter) todas estas informações de metadados? Isso já é definido no model? Título do campo por exemplo é possível definir já no model?

Não… o ActiveRecord guarda apenas metadados da tabela que ele mapeia, não dados do seu domínio (apesar de ser possível guardar, afinal, estamos falando de Ruby =D).

Quanto às mascaras eu sinto que aí há uma controvérsia, e acho melhor adicionar a isso no no “server side” imagine que estamos tratando de CPF/CNPJ por exemplo. Quem tem mais autoridade para definir o formato de exibição/edição? o Cliente ou o servidor?

Eu não gosto de guardar dados formatados no banco… não quero convencer ninguém a fazer o mesmo, mas minha justificativa é que a view é responsável por formatar os dados como bem entender. As regras de negócio não tem nada com isso, e não devem se preocupar com o formato dos dados na maior parte das vezes.

apesar de o servidor ter a última palavra/responsabilidade na validação, normalmente o cliente é o melhor lugar para se fazer verificações de dados, por isso normalmente a gente faz isso nos dois lados não é mesmo?

Exatamente. Validar no servidor é OBRIGATÓRIO. Validacão no cliente é OPCIONAL, mas um opcional muito bem vindo para facilitar a vida de quem vai usar.

o calculo do digito verificador seria uma coisa a ser feita nos dois lados. Agora imagine que junto com os metadados venha um script de calculo mod11 para ser interpretado pelo cliente na validação por exemplo.

Em qual linguagem esse script seria retornado? Representar um algoritmo de forma genérica para que possa ser interpretado em várias linguagens não é trivial, metadados desse tipo devem ser bem tensos… a menos que vc limite os clientes a uma linguagem específica (o que pode ser válido em algumas situacões), fazer isso vai dar um belo trabalho =).

os ranges por exemplo também é atribuição do servidor (por exemplo definir que data de faturamento não pode ser no futuro ou passado é uma coisa que deve ser definida no modelo e não no cliente

Aqui acho que entra de novo a especificacão da API, que eu falei no post anterior. Bastaria dizer os critérios que cada parâmetro deve respeitar, e o cliente implementa como lhe convir.

eu vejo vantagem em o servidor passar informações como titulos de campo por exemplo. De forma que a interface só mostrasse o que vier do servidor. Uma forma de usar o reflection do Model para implementar o cliente.

A idéia em si eu acho interessante, mas não consegui pensar em uma aplicacão prática… ainda acho que a view pode ser personalizada de acordo com outros critérios, que não sejam impostos pelo servidor ;).

Preciso lembrar alguem q tamo falando de… deldslkds .. desculpa, dedksl…. ops…. delfí ????

Gsus….Delfimnisso.

>Preciso lembrar alguem q tamo falando de… deldslkds .. desculpa, dedksl…. ops…. delfí
>???? Gsus….Delfimnisso.

Boa piada, Delfimnisso. Muito boa mesmo. Por isso eu ainda me sinto um dinossauro.

Na verdade não. Eu até fiz a chamada falando da integração Delphi&Rails, mas logo percebi que o Delphi deveria ser tirado do foco da discussão. O que se discute aqui é um PROTOCOLO de comunicação entre o CONTROLER e a VIEW. De forma a conseguir implementar uma VIEW em desktop usando clientes ricos e ferramentas de desenvolvimento de aplicações desktop como Delphi, .NET, QT ou qualquer outra coisa que você possa imaginar.

A idéia é poder fazer scaffolds poderosos no desktop que sejam facilmente customizados posteriormente. Repito: Imagine criar o seu model com todas as constraints e regras de negocio que você puder imaginar em Rails e a partir disso montar um PROTÓTIPO desktop altamente customizável na camada VIEW.

A idéia é um mecanismo de transferência de METADADOS do Model para o cliente de forma que uma aplicação pudesse ser montada com o mínimo de esforços.

Agora melhorou, hehe.. um rails pra desktop.
Eu acho q hoje algo pra ser desktop já ta partindo de alguma dificuldade incrivel de se implementar como saas. Ateh games já ta começando a ser saas!
Sendo assim, fica mto complicado um fw q atenda tudo pq provavelmente vc vai precisar de coisas mto OS-especificas.
E tem de monte “pequenas” soluções pra pequenas coisas, vide shoes.
E ñ tem jeito, software q nao instala é o futuro. (soh falta uma solucao boa de offline sync p/ mobiles hehe)

Acho que o nome disso que vc quer é MDA mas nunca vi nada sobre isso na prática…

Acertou na mosca! É verdade, todas as tentativas de MDA que eu já vi até hoje deram em um resultado tosco. Com uma curva de aprendizado intransponível. Mas a idéia é isto mesmo: Guiar a Arquitetura da aplicação a partir do Model.

Não… o ActiveRecord guarda apenas metadados da tabela que ele mapeia, não dados do seu domínio (apesar de ser possível guardar, afinal, estamos falando de Ruby =D).

Como ficaria no Model para colocar o Caption de um campo por exemplo? Vincular “Data de nascimento” ao atributo birth_date?

Eu não gosto de guardar dados formatados no banco
Quem falou em guardar dados formatados? O que impede de termos no model algo como

para definir como um numero de telefone deve ser editado ou exibido mas no armazenamento voce guarda só os dados limpos " 1122223333"?

view é responsável por formatar os dados como bem entender.
Concordo, mas ela não poderia receber algumas dicas e ter a colaboração do Model e do Controller sobre como fazer isso? Note que quem projetou o M e o C já sabe muito sobre o domínio do projeto e como deve ser o V. Além disso, seria uma forma fantástica de desenvolvimento progressivo. Altera o M/C e já vê funcionando na View na hora.

As regras de negócio não tem nada com isso, e não devem se preocupar com o formato dos dados na maior parte das vezes.
Não entendi a ligação entre as regras de negócio além do fato de validar as mesmas no cliente de forma dar mensagens como:
“Desconto invalido: 15%. Para este conjunto de produtos o máximo é 10%”

Isso sem ter que enviar o pacote de dados novamente para o Controler para que ele diga isso? Idealmente estas regras (script ruby) também poderia ser recebido no pacote de metadados pela view de forma que fosse avaliado em tempo de edição sem ter que chamar o servidor para validar.

Note que isso é opcional. Estas validações podem (e talvez devam) ser executadas somente no Controler.

Exatamente. Validar no servidor é OBRIGATÓRIO. Validacão no cliente é OPCIONAL, mas um opcional muito bem vindo para facilitar a vida de quem vai usar.

Concordo, não há controvérsia aqui.

Em qual linguagem esse script seria retornado?

Ruby?

Aqui acho que entra de novo a especificacão da API, que eu falei no post anterior. Bastaria dizer os critérios que cada parâmetro deve respeitar, e o cliente implementa como lhe convir.

Novamente um bloco de código ruby que defina a validação:

{|date| date <= today}

Isso é mamão com açucar para fazer em delphi por exemplo. Ruby embedded em delphi já tá pronto.

O foco seria achar um modo de fazer um Marshalling dos objetos Ruby entre as plataformas.

A idéia em si eu acho interessante, mas não consegui pensar em uma aplicacão prática… ainda acho que a view pode ser personalizada de acordo com outros critérios, que não sejam impostos pelo servidor ;).

O desacoplamento é muito importante e desejável, mas o princípio DRY nos induz a não repetir o trabalho. Assim se alguma constraint já é definida no server, o que impede exatamente a mesma constraint ser avaliada na VIEW (cliente) antes de enviar os dados para o CONTROLER (servidor)?

Talvez aqui eu ainda esteja com um pensamento muito “Client/Server” possivelmente contraditório ao modelo Rails de trabalho. Mas este não parece o caso.

Por último, acabei de descobrir que isso que eu to falando já existe: Announcing: Ext Scaffold Generator Plugin for Rails Talvez este seja um bom lugar para começar.

Mas ainda vejo vantagem na idéia de integrar outros produtos com Rails. Uma delas é que para quem tá aprendendo, seria MUITO mais fácil trabalhar com ruby somente no MODEL e no CONTROLLER e aproveitar todo o conhecimento de muitos anos do desktop para fazer a VIEW.

Como ficaria no Model para colocar o Caption de um campo por exemplo? Vincular “Data de nascimento” ao atributo birth_date?

Apesar de eu não achar interessante vincular um label a um campo (acho que i18n resolve muito bem), uma forma seria algo declarativo, como:

Não gosto dessa abordagem por limitar a uma única língua. E se adicionarmos suporte a várias línguas, estaremos complicando nosso model com tarefas que não são responsabilidade dele, por isso insisto que i18n faz um trabalho melhor (e na camada correta) =).

O que impede de termos no model algo como mask:“00(99)0999-9999” para definir como um numero de telefone deve ser editado ou exibido mas no armazenamento voce guarda só os dados limpos “1122223333”?

ABSOLUTAMENTE NADA nos impede, mas não é porque é vc PODE que vc DEVE fazer ;). Como falei antes, não acho que formatação dos dados seja uma das responsabilidades do modelo. Mas isso é preferência pessoal.

Não entendi a ligação entre as regras de negócio além do fato de validar as mesmas no cliente de forma dar mensagens como: “Desconto invalido: 15%. Para este conjunto de produtos o máximo é 10%”

Na minha visão, validações entram na especificação da API (novamente, opinião pessoal).

Talvez aqui eu ainda esteja com um pensamento muito “Client/Server” possivelmente contraditório ao modelo Rails de trabalho

Bom, teu pensamento é 3-tier total =D. Mas nada impede usar Rails pra fazer isso, vc só estaria ignorando a view.

A idéia é um mecanismo de transferência de METADADOS do Model para o cliente de forma que uma aplicação pudesse ser montada com o mínimo de esforços. Imagine criar o seu model com todas as constraints e regras de negocio que você puder imaginar em Rails e a partir disso montar um PROTÓTIPO desktop altamente customizável na camada VIEW. Seria uma forma fantástica de desenvolvimento progressivo. Altera o M/C e já vê funcionando na View na hora

Já esbarrei nessa idéia algumas vezes lendo alguns artigos, mas nunca vi uma solução legal… e menos ainda envolvendo linguagens diferentes. Fazer algo assim usando apenas Ruby não seria tão difícil, mas fazer um negócio desse genérico o suficiente a ponto de suportar linguagens diferentes exigiria bem mais esforço.

Por último, acabei de descobrir que isso que eu to falando já existe. Talvez este seja um bom lugar para começar.

Bacana, depois vou olhar com calma o plugin =).

PS: tudo que eu falei aí é baseado em experiência/opinião pessoal, então a chance de eu falar alguma besteira é grande xD.

Por enquanto estou com outras tarefas, mas tão logo eu possa, eu pretendo trabalhar nesta idéia, começando pelo mecanismo de Marshalling para compreender melhor o funcionamento do sistema de objetos distribuídos do ruby & rails. Creio que o caminho é por aí, os objetos ruby deveriam viajar entre o servidor e o cliente embedded em Delphi.

Além disso, eu ainda sou um principiante em Rails, e antes de começar um projeto assim eu ainda tenho “muito feijão para comer” como se diz aqui na minha terra.

Valeu!

Se for distribuir objetos em Ruby, use Drb, ou talvez, Rinda. Vai facilitar muito sua vida =)

E Json ou Bson p/ marshaling.