From: lscheidegger - x. <lsc...@xd...> - 2003-08-19 03:01:42
|
>>=20 >> - Report (o cl=E1ssico), t=EDtulo, subt=EDtulo, tabela, links = (bot=F5es) >Legal, mas ainda nao tah aprofundado o suficiente - o que tem num=20 >titulo? O que tem num subtitulo? O que eh uma tabela? >Pra onde vao os links? Isso se refere a aquilo que eu estava falando das 3 fases de uma opera=E7=E3o: =3D> A chamada, ou seja, o link para chegarmos em uma determinada opera=E7=E3o =3D> O display, que =E9 a interface t=EDpica da = opera=E7=E3o, como um formul=E1rio =3D> O processamento (qdo cab=EDvel) , que =E9 a persist=EAncia dos dados submetidos. Para criarmos uma chamada temos basicamente parametros, esses = par=E2metros tem um id e um valor, portanto path.extensao?parametro1=3Dvalor1¶metro2=3Dvalor2 Por=E9m os valores desses par=E2metros devem permitir algumas op=E7=F5es din=E2micas, da=ED temos 3 op=E7=F5es: - Imagine que temos um link em um relat=F3rio para editar o registro, ou seja, estamos passando o id ou primary key do registro certo? Quando processarmos esse request, temos que setar as propriedades da classe da camada de neg=F3cios, a qual se destina o request, com base nesse id passado. Nessa situa=E7=E3o temos que ter acesso rapidamente aos valores = da propriedades; - A segunda situa=E7=E3o no relat=F3rio supracitado (eu sempre quis usar = essa palavra), o id que ser=E1 passado em cada registro se refere a um statement de consulta no banco de dados, nos objetos serializados, xml, ou qq outra fonte de dados, vou chamar essa origem de dados de instancia. - E podemos ter uma terceira op=E7=E3o de informa=E7=F5es, que =E9 o = pr=F3prio framework, por exemplo, supondo que para uma determinada tela tenhamos que passar um flag passado pela url, mas que n=E3o seja relacionada a nenhuma propriedade da classe, como recuperar essa informa=E7=E3o para redireciona-la em outro link dessa mesma p=E1gina? Como podriamos tb reenviar informa=E7=F5es a respeito da sess=E3o do usu=E1rio? Nesse peda=E7o consideramos apenas requests GET, mas entrando na fase do display/process, muitas vezes temos que passar par=E2metros para um processamento, ou seja, gerar hiddens. Portanto par=E2metros passados de link / display, se tornam par=E2metros de url, par=E2metros de display = para process transformam-se em hiddens. Sei que =E9 =F3bvio mas =E9 legal verbalizar essas coisas. >> - ListReport , relat=F3rio composto de uma listagem de links, como em >> not=EDcias relacionadas de um site de not=EDcias >Entao, qual a diferenca entre Report e ListReport? (eu faco uma ideia,=20 >mas a gente precisa mastigar melhor as definicoes) O ListReport =E9 uma listagem de links, que apresenta por exemplo uma listagem de m=FAsicas com seus respectivos compositores, e o link envia para o download da m=FAsica, sem que essas informa=E7=F5es estejam = organizadas por c=E9lulas. http://www.mirandoresultados.com.br/interna.php?pagina=3Dview.php&workspa= c e=3Dmr&class=3DArticle&method=3DdisplayArticle§ionID=3D35&primaryKey[= 0]=3D53&d elegate=3Dhuxley&template=3Dtemplate.htm&from=3DO+Livro&xsl[0]=3Darticle2= .xsl&wi zard=3D0&st=3Dffbd9af24dd7a868b5d1f769774dde4e >> - NestedReport , report que cont=E9m master-detail em uma mesma tela, >Precisamos de um tipo totalmente diferente de Report pra isso? Hmm,=20 >acho que nao... alguem quer defender a tese? :D N=E3o =E9 um tipo diferente de relat=F3rio, na verdade =E9 uma = especializa=E7=E3o de report, como uma rela=E7=E3o de heran=E7a. No final teremos muitos = poucas interfaces mapiadas, mas teremos um monte de especializa=E7=F5es. >> - Form (o cl=E1ssico) t=EDtulo, subt=EDtulo, campos, links >Beleza, so falta definir cada um deles, especialmente o que eh um=20 >"campo" e um "link" Ai entra algo que eu gostaria de mudar radicalmente de tudo que j=E1 fizemos, acho que n=E3o temos que escrever nada que se pare=E7a com = html, como: <field> <text_field> <size>100</size> <maxLength>100</maxLength> </text_field> </field> Ao inv=E9s disso acho que temos que deixar a interpreta=E7=E3o do que = deve ser uma campo em um formul=E1rio, para nosso meio-campo, ou seja, a = ferramenta que utilizaremos para dar o parse do xml de defini=E7=E3o, no caso o Velocity. A minha proposta =E9 que nossa defini=E7=E3o saia refletindo a orienta=E7=E3o a objeto, ou seja, com defini=E7=E3o de propriedades e = m=E9todos, e o nosso parser com base no tipo de sa=EDda mais o tipo de opera=E7=E3o/interface que foi solicitado no request, gere um tipo de = sa=EDda adequado, portanto ter=EDamos um xml de defini=E7=E3o como esse: = <properties> <number id=3D'id'> <type>auto_increment</type> <caption>Id do usu=E1rio</caption> </string> <string id=3D'nome'> <length>100</length> <mandatory>true</mandatory> <caption>Nome do usu=E1rio</caption> </string> <date id=3D'dataNascimento'> <format>dd/mm/yyyy</format> <mandatory>1</mandatory> </date> <number id=3D'salario'> <type>money</type> <caption>Sal=E1rio</caption> </string> </properties> <operations> <operation type=3Dadd> <entity>User</entity> <schema>BlakePipeStore</schema> <parameters>=20 <parameter type=3D'session' id=3D'user' value=3D'userId'> <parameter type=3D'url' id=3D'template' value=3D'template> <parameter type=3D'property' id=3D'id' value=3D'id'> <parameters> </operation> </operations> Essa ferramenta de integra=E7=E3o que tem que entender que nosso = defini=E7=E3o acima em um tipo de sa=EDda html, em um tipo de opera=E7=E3o de = inclus=E3o deve dar uma sa=EDda html de formul=E1rio, em outra sa=EDda como wml, deveria = gerar os cards correspondentes. Ou seja, uma solu=E7=E3o abstrata. >> - Search campo + bot=E3o + link para advanced search >Hmm...o que a gente mostra no advanced search? Quando o cara faz uma=20 >busca simples, que dados a gente procura? Voc=EA procura em todas as propriedades que voce marcou como searchable, um advanced search, vc mostra campo a campo que vc habilitou.=20 >> - Advanced Search parecido com o form, o que muda s=E3o os = par=E2metros=20 >> de >> processamento >...que seriam? Um formul=E1rio em uma opera=E7=E3o de inclus=E3o ou edi=E7=E3o, vc = processa =E9 volta a consulta, em um search, vc pode querer apresentar os dados retornados em interfaces d=EDspares como lista de produtos, no caso do submarino = por exemplo, em uma tabela, uma lista de links, etc. Exemplo: http://www.mirandoresultados.com.br/interna.php?pagina=3Dview.php&workspa= c e=3Dmr&class=3DArticle&method=3DdisplayArticle§ionID=3D35&primaryKey[= 0]=3D53&d elegate=3Dhuxley&template=3Dtemplate.htm&from=3DO+Livro&xsl[0]=3Darticle2= .xsl&wi zard=3D0&st=3Dffbd9af24dd7a868b5d1f769774dde4e Voc=EA tamb=E9m pode querer mudar o tipo de campo conforme a busca, = supondo que voc=EA tenha em seu cadastro de usu=E1rios a informa=E7=E3o cidade = de resid=EAncia, supondo que vc queira que o usu=E1rio na busca escolha = entre todas as cidades que j=E1 foram cadastradas, para que ele n=E3o tenha = que advinhar os valores j=E1 cadastrados, portanto vc altera o tipo b=E1sico = da propriedade para essa opera=E7=E0o para o tipo escolha, que em um = formul=E1rio resultaria em um combo, radio, checkbox, ou list. >> - Cross , refer=EAncia cruzada de duas entidades (n para n), exemplo >> cl=E1ssico: usu=E1rio x grupo, vc pode querer ver todos os usu=E1rio >> vinculados a um determinado grupo, na consulta de grupo, bem como ver >> todos os grupo vinculados ao usu=E1rio na consulta de usu=E1rio. >Joia. Como modelar isso de forma generica? Eu normalmente crio uma entidade que s=F3 existe logicamente, nesse caso seria algo como UsuarioGrupo, e essa entidade s=F3 implementa uma opera=E7=E3o, Cross, essa entidade sempre ser=E1 chamada ou da entidade = user, portanto vc passar=E1 o id do usu=E1rio do qual vc quer ver quais grupos est=E3o relacionados, ou da entidade group, que vc tb mandar=E1 o id = para ver quais usu=E1rios est=E3o vinculados. Resumindo, dessa entidade "agregadora", dependendo do par=E2metro que vc receber da url, vc = mostrar=E1 uma listagem ou outra. Eu tenho isso funcionando, posso te mostra se quiser. >>- Menu (listagem de links) >Corta fora - no Inectis ja tem um esquema bem mais flexivel ;) OK, mas precisa estar num esquema an=E1logo ao das outras interfaces. >> - Interfaces compostas como: >> - formul=E1rio em abas; >Detalhe do template, nao? N=E3o, especializa=E7=E3o das interfaces, qto menos templates criarmos, = melhor est=E1 o nosso mapeamento de interfaces, j=E1 temos essas interfaces compostas mapeadas em nosso framework, inclusive com a possibilidade de criar interfaces mistas de formul=E1rio, relat=F3rios, busca. =C9 tb de interfaces geradas dinamicamente, com interfaces geradas no template. O rafael pode falar legal disso. >> - help (estilo hlp) com lista de links a esquerda e conte=FAdo a >> direita >Corta fora tambem, isso o Inectis ja faz :) Tranx. >> Que eu me lembre essas s=E3o as principais, se algu=E9m lembrar de >> alguma outra feel free, >>Acho que os principais ja tao aih, a gente so precisa esmiucar eles=20 >>melhor. >> por=E9m temos que resolver antes de escrevermos os c=F3digos que = lidem=20 >> com as interfaces, como ser=E1 feita essa integra=E7=E3o, desculpe = mas para >> mim n=E3o est=E1 muito claro, pois se formos usar algo que n=E0o seja = xsl,=20 >> temos que entender como esse algo processar a defini=E7=E3o e = gerar=E1=20 >> sa=EDdas distintas como htm, xml, wml, excel, csv, txt, etc. >Juro que eu nao vejo a *menor* necessidade de pensar nisso agora - isso >eh detalhe de >implementacao, e se a gente nao ficar satisfeito com Velocity, podemos mudar facilmente >pra outra tecnologia. Mais ou menos, concordo em parte acho que temos que ter um esbo=E7o em mente, pois isso =E9 o outro lado da metodologia, ou seja, a = integra=E7=E3o, se ela n=E3o for completamente transparente e flex=EDvel, estaremos ganhando por um lado e deixando de ganhar de outro. >> - Como montar uma interface que permita ao cara criar forms, >> listagens, relatorios e acoes pela web? >>=20 >> N=E3o s=F3 pela web n=E9? o foco principal =E9 esse mas tb todos os = tipos de >> sa=EDda de informa=E7=E3o que forem confort=E1veis ao usu=E1rio. Por = interface=20 >> nesse ponto vc est=E1 se referindo a uma esp=E9cie de IDE para ajudar = a=20 >> programar utilizando-se do Blake? >Nao exatamente. Estou me referindo a duas coisas, na verdade: >- Um modelo de objetos conciso e abrangente (que a gente esta=20 >discutindo na primeira >metade do e-mail com todo aquele monte de pergunta chata) Sim. >- Uma API para lidar com o modelo de objetos Sim. Sim. >- Uma interface para a API <- e' disso que eu estou falando nessa=20 >pergunta. Como montar >uma ferramenta web que te permita construir a porra toda sem necessariamente saber=20 >programar, a nao ser pelas regras de negocio? Acho que isso n=E3o ser=E1 poss=EDvel, pelo menos n=E3o em uma primeira = vers=E3o, acho que para conseguirmos de tal n=EDvel de abrang=EAncia vamos ter que maturar bastante o blake. Acho que teremos que nos contentar na primeira vers=E3o, com o blake processando todas as interfaces / opera=E7=F5es = b=E1sicas que citamos. Eu vejo isso como uma hierarquia, em um n=EDvel temos intelig=EAncia de interfaces, depois disso temos a intelig=EAncia de opera=E7=E3o, que =E9 = aquelas 3 fases que comentei (link/display/process), e por fim teremos intelig=EAncia de sites. Vejo que vc j=E1 est=E1 pensando na =FAltima = fase, que bom... Eu tb tenhos esse objetivo, apesar de muito me preocupar o desemprego que tal revolu=E7=E3o trar=E1, e acredite se n=E3o formos = n=F3s outros far=E3o. []'s Luiz Obs. Me empolguei! |
From: Rafael S. <ra...@in...> - 2003-08-19 03:19:57
|
-----Mensagem original----- De: bla...@li... [mailto:bla...@li...] Em nome de lscheidegger - xdevelopment Enviada em: segunda-feira, 19 de agosto de 2002 00:04 Para: bla...@so... Assunto: RES: [Blake-devel] Fontes do Inectis [...] > Ao inv=E9s disso acho que temos que deixar a interpreta=E7=E3o do que = deve ser uma campo em um formul=E1rio, para nosso > meio-campo, ou seja, a ferramenta que utilizaremos para dar o parse do xml de defini=E7=E3o, no caso o Velocity. A > minha proposta =E9 que nossa defini=E7=E3o saia refletindo a orienta=E7=E3o a objeto, ou seja, com defini=E7=E3o de = propriedades > e m=E9todos, e o nosso parser com base no tipo de sa=EDda mais o tipo = de opera=E7=E3o/interface que foi solicitado no > request, gere um tipo de sa=EDda adequado, portanto ter=EDamos um xml de defini=E7=E3o como esse: <properties> > <number id=3D'id'> > <type>auto_increment</type> > <caption>Id do usu=E1rio</caption> > </string> > <string id=3D'nome'> > <length>100</length> > <mandatory>true</mandatory> > <caption>Nome do usu=E1rio</caption> > </string> [..] > Essa ferramenta de integra=E7=E3o que tem que entender que nosso = defini=E7=E3o acima em um tipo de sa=EDda html, em um > tipo de opera=E7=E3o de = inclus=E3o deve dar uma sa=EDda html de formul=E1rio, em outra sa=EDda como wml, = deveria gerar os > cards correspondentes. Ou seja, uma solu=E7=E3o abstrata. Entao.. eis um ponto interessante. Nisso estamos considerando que o resultado final estara em um formato XML, o qual devera ser processado por alguma ferramenta para a construcao da interface. SE nesse caso tratassemos tudo como objetos, ou seja, passar para o parser de interface uma arvore com os objetos, poderiamos navegar por eles para termos o que fosse necessario tambem, sendo ( com uma analise rapida, claro ) bem mais simples interagir pelos dados.=20 O formato do objeto em si nao tenho mto definido, mas digamos que seria como o formato do XML mesmo: public class Seila { // Tipo: number, string, date etc private int type; private String caption; private boolean mandatory; // etc etc... // gets e sets } entao o sistema faz o processamento que precisar e vai construindo uma arvore com esses objetos. Dai digamso que estamos usando o Velocity para a cosntrucao da interface.. ficaria algo como <!-- REPORT INTERFACE --> <!-- Caption --> <table> #foreach ($caption in $tree.report.objetosDeCaptionList) <tr> #foreach ($name in $caption.names) <td><b>$name</b></td> #end </tr> #end <!-- Conteudo --> #foreach ($line in $tree.report.objetosComOsDadosList) <tr> #foreach ($column in $line.columns) <td>$column.data</td> #end </tr> #end <!-- Links --> #foreach ($link in $tree.report.linksList) blablabla #end E assim por diante. Com isso conseguiriamos colocar qualquer tipo de conteudo em qualquer canto da tela, de maneira simples. Algo nesse estilo. Rafael |
From: Guilherme S. <gui...@gu...> - 2003-08-19 12:54:35
|
Vamos la, vou colocar a opiniao nos pontos que achei que sao interessantes para o comeco, o resto que parece ser muito especifico deixei de lado: Uma vez que o list e o nested report nao passam de especializacoes, eles deveriam ser tratados como report... (basico de oop). Se o report for generico suficiente, list e nested serao gerados facilmente atraves deles. Pessoalmente, eu consigo visualizar o report gerando um listreport facinho, mas um nestedreport fica mais complicado e, ao contrario do que o rafael disse, eu tenho a impressao que o nested pode ser bastante requisitado dependendo do projeto. De qq jeito, minha opiniao fica: faca o report, funcionou, vai em frente... (acho que mais ou menos o que o carlos falou no primeiro email) >> - Form (o clássico) título, subtítulo, campos, links >Beleza, so falta definir cada um deles, especialmente o que eh um >"campo" e um "link" A definicao eh para montar os objetos? Mas os campos nao ficaram de ser lidos atraves de reflection? Voce passa um bean e ele joga o campo la no formulario? A ferramenta de integracao: nao passa de uma interface a ser implementada pelos cuspidores de html/wml/excel/o q for... e selecionadas atraves do arquivo de definicao/request/...?? >> - Interfaces compostas como: >> - formulário em abas; >Detalhe do template, nao? O formulario em aba nao pode ser considerado um tipo de menu? Nao seria interessante comecar com um ponto, tipo, FORM e ir em frente ate ver ele funcionar do jeito desejado? Ai alguem vai pra frente com o REPORT enquanto outra pessoa aperfeicoa e afina o FORM? e reticencias? ps: pq "blake"? (o q significa) Guilherme |
From: lscheidegger - x. <lsc...@xd...> - 2003-08-19 13:44:55
|
[...] >De qq jeito, minha opiniao fica: faca o report, funcionou, vai em frente... (acho que mais ou menos o que o >carlos falou no primeiro email) Blz, eu tb concordo com isso, s=F3 quis esclarecer o tipo de coisa que temos que resolver no futuro, a minha opini=E3o eu reitero, temos que fazer as interfaces uma a uma, estressando bastante as possibilidades de cada uma. >ps: pq "blake"? (o q significa) William Blake foi um poeta e pintor vision=E1rio que nasceu em 1753,1755 ou 1757 h=E1 controv=E9rsias. H=E1 uma aura de bruxo ou de louco em = torno da hist=F3ria dele, tanto sua pintura quanto poesia foram consideradas inovadoras para a =E9poca que foram feitas. Porque pensei nele? Porque eu queria homenagear algum artista, e ele foi de um per=EDodo do in=EDcio da revolu=E7=E3o industrial, e em toda = revolu=E7=E3o como a industrial, ou a web, todos pensam que o mundo j=E1 est=E1 muito evolu=EDdo, e que nada mais temos a desenvolver. N=E3o precisamos = refletir muito para ver o quanto a ind=FAstria mudou daquele tempo para c=E1, da mesma forma a web mudar=E1, ela est=E1 em um est=E1gio muito = embrion=E1rio, e a minha proposta =E9 que sejamos algumas das pessoas que v=E3o levar a web para o pr=F3ximo patamar evolucion=E1rio. []'s Luiz |
From: Rafael S. <ra...@in...> - 2003-08-20 03:59:01
|
Bom,=20 -----Mensagem original----- De: bla...@li... [mailto:bla...@li...] Em nome de Guilherme Silveira Enviada em: ter=E7a-feira, 19 de agosto de 2003 09:55 Para: bla...@li... Assunto: Re: [Blake-devel] Fontes do Inectis > ... ao contrario do que o rafael disse, eu tenho a impressao que o nested pode ser=20 > bastante requisitado dependendo do projeto. Nos projetos que fiz ate hj, nao lembro de muitos casos onde um nested fosse necessario. Mas, como tinha colocado no email anterior, por ser relativamente simples de fazer, nao ha motivo de deixar de fora :) [...] > A definicao eh para montar os objetos? Mas os campos nao ficaram de ser lidos atraves=20 > de reflection? Voce passa um bean e ele joga o campo la no formulario? Isso eh um dos pontos que esta em aberto ainda. Estamos juntando as ideias para soh entao definir como vai ser. Atualmente ha as possiblidades de usar xml, doclet/reflection e coisas do genero. Mas parece que estamos caminhando para o lado de=20 Rafael |