Ok, valeu, vou tentar compilar, valeu... Luiz Escobar Analista/Desenvolvedor: WEB - HTML/JavaScript/PHP/MySQL WINDOWS - Delphi/MyDAC/ASSEMBLER/MySQL/xBase DOS - Clipper/Assembler xBase SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k LINUX - LAZARUS/Kylix/MySQL; http://www.megasistema.com.br
----- Original Message ----- From: Joao Morais To: delphi-br@yahoogrupos.com.br Sent: Monday, December 04, 2006 12:01 PM Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Luiz Escobar wrote: >> - É o mesmo botãozinho em cada componente. E se for um >> TDBSpeedButtonLookupComboBox, tem que dizer qual é o formulário alvo em >> cada formulário criado. Se não quiser dizer qual é o form, tem que ser MVP. > > Mas João, como em MVP ele sabe que eu quero cadastrar e qual é o FORM, indiretamente eu estou informando não é ?? vejamos: > > procedure buttonclick(...) > form1.showMODAL; > > procedure buttonclick(...) > cliente := TCLIENTE.nãolembrootermo(ID); Você não precisa disso. O registro de Presenter faz isso por você. Então se você tem um combo e liga a um Nota.Cliente, ele sabe que isso aponta para TCliente, sabe que vai usar o form TClienteEditViewForm, ele sabe instanciar o form, destruir, gravar os dados do Cliente em TCliente e depois gravar o ID do cliente em TNota. Depois nesse combo você pode digitar um pedaço do nome do cliente e o Combo é aberto com os clientes que possuem aquele critério. Novamente, sem código algum. Tudo o que tens que fazer é criar as classes (Wizard, pois sem ele é bem phodha), registrar, e por fim ligar o Combo ao atributo da classe (uma linha de código que chama um método com três parâmetros). Tá certo, você precisa registrar algumas coisas, e no lugar certo. E se você quiser criar umas funcionalidades diferentes, tem que ser no lugar certo também, mas tudo isso resolve-se com Wizards, sem código nenhum -- exceto o seu próprio código, lógico, MVP não faz milagre. Você precisa pelo menos saber o que quer :-) E lógico, ainda falta implementar os raios dos Wizards. > sempre penso em como fazer o software ser mais produtivo para o USUÁRIO também, > se as telas começarem a demorar d+ para serem apresentadas, to fora... Depende da persistência. InstantObjects tem uns perrengues (lentidão) quando você tem objetos muito complexos. Mas como te disse - uma que a equipe está trabalhando nesse perrengue, outra que eu posso escrever um broker para tiOPF, DePO ou qualquer outro. Outra ainda é que eu tenho intenção de criar um framework de persistência próprio. Ainda assim, mesmo com InstantObjects, não é nada de arrancar os cabelos. Tenho um projeto com quatro níveis de mestre-detalhe, e as telas apesar de não serem apresentadas instantaneamente, levam uma pequena fração de segundos para aparecer quando o objeto ainda tá no banco. Se o objeto tá em cache, a apresentação é instantânea, independente do tamanho do form. Quanto ao produtivo para o usuário, aqui sim está a vantagem. Você cria novas funcionalidades em quaisquer componentes, como Combo, StringList, ou mesmo Edit, registra o Model no framework e a funcionalidade é replicada para todo o teu sistema. Se você quiser, agora, usar um ListView para apresentar dados (o framework *ainda* não o suporta), basta você registrar uma View que entenda ListView e pimba, tá lá o ListView mostrando os teus objetos de negócio. Você não precisa que o desenvolvedor do framework faça isso por você, nem mesmo se o código fosse fechado. Assim você usa uma ferramenta que não te prende a apenas um padrão, um banco, um componente, uma funcionalidade. Veja MVP.txt nos docs aonde eu falo mais ou menos isso com outras palavras. > E que ASSEMBLY tem haver com isso... > Quanto a arrastar componentes, bom se alguem trabalhar em DELPHI e não fizer isso, bom, deve ser um MASOQUISTA! > O fato de eu, arrastar ou não componentes, e vc, ser o construtor de um MVP, não o torna melhor o pior programador que eu, acho que neste ponto vc deveria REVER OS SEUS CONCEITOS... Véi, foi forçado o comentário. Mas ainda assim tentei colocar dois exemplos extremos - Assembly é puro código e arrastar componente é puro click. Nenhum dos dois é bom porque por um lado lhe falta produtividade, por outro lhe falta recurso. MVP é mais orientado a código, especialmente _hoje_, _em Press_. Logo que a anta véia conseguir criar os Wizards tudo firacá mais divertido e clickável. Mesmo assim, desculpa a falta de jeito. Eu, pra mula, só tá faltando as penas. > se compilou aquele PHONEBOOK ?? to loco pra testar a performance do bixim... > Já vi que vc não quer me enviar o executavel pra eu testar... > >> Leia os Readme. > > Já LI!... :-/ Vide ($Press)/Demos/Readme.txt. Você precisa remover a dependência com InstantObjects, ou instalá-lo em teu micro. Ainda assim vou empacotar um binário com conectores para ZeosDBO (vários bancos, para testares com MySQL), UIB (velocidade), BDE (só pra desencargo) e deixo um link na lista. Ainda assim eu recomendaria você tentar compilar por aí para entender melhor como a coisa funfa. -- João Morais [As partes desta mensagem que não continham texto foram removidas]
