[Cascavel-pm] OpenInteract

[Marco Lima]

Isso já deveria estar sendo colocado na página do grupo de estudo ?? não
podemos transformar a lista em canal de comunicação para isso ... depois
estamos iniciando um trabalho de estudo das ferramentas ... só o tempo
vai nos dizer qual vai se sair melhor e onde cada uma pode encaixar ...
eu como diretor de um empresa de tecnologia gostaria sim de ter opções
... mas que a decisão seja através de argumentos práticos ... e garanto
que cada caso é um caso ! 

Monges ! já existem os dois grupos de trabalhos ... e tenho certeza que
vão gerar bons frutos para comunidade brasileira ... por isso vamos nos
concentrar nos estudos !!

[  ] 'ção

> --- Ricardo Filipo <ricardo_filipo em yahoo.com.br> escreveu:
> > O IBPAS apoiará o projeto, pois está precisamente
> > coerente com o projeto "Padronização de Software para
> > Gerenciamento Empresarial".
> 
>   Isso é muito bom :-) todo apoio é muito bem vindo!
> 
> > Como vc pensa em integrar o OAK com o OpenIteract, na
> > medida que ambos fazem mais ou menos a mesma coisa? 
> 
>   Espero sinceramente que ambos (Ricardo Filipo e Marco Lima) me
perdoem a ousadia e a
> intromissão.
>   Ao me considerarem inconveniente, por favor ignorem o resto desta.
> 
>   Eu fui examinar a documentação do OAK e tenho 98% de certeza de que
ele é uma implementação do
> MVC, mas com o "V" implementado internamente: o Daniel Ruoso construiu
software para o "viewer"
> dentro do OAK, ao contrário da implementação oferecida pelo
OpenInteract, que "importa"
> funcionalidade de "viewer" de outro sistema, o Template Toolkit de
Andy Wardley. Outra semelhança
> (e diferença) entre os dois é que o OAK preferiu utilizar o DBI
(através de um Wrapper pequeno)
> para oferecer acesso a bancos de dados relacionais, enquanto o
OpenInteract preferiu utilizar
> SPOPS. A diferença é obvia. A semelhança é que ambos preferiram
"importar" software para acesso
> uniforme a bancos de dados relacionais ao invés de escrever suas
próprias soluções.
> 
>   IMHO, qualquer tentativa de integração vai nos levar necessariamente
a duas opções: ou
> simplificar o fonte, escolhendo uma das implementações propostas, ou
complicar ainda mais a
> utilização das implementações, obrigando o usuário a optar por uma das
duas implementações à
> força, antes de começar a construir seu sistema.
> 
>   Talvez devéssemos optar por uma "terceira via"...
> 
>   Mas isso é apenas a minha opinião, claro...
>   Putamplexos!
> 
> --
> Luis Campos de Carvalho
> Member of "São Paulo Perl Mongers",
> Unix SysAdmin & OCP/DBA Oracle
> http://br.geocities.com/monsieur_champs/
> 
> __________________________________________________
> Converse com seus amigos em tempo real com o Yahoo! Messenger 
> http://br.download.yahoo.com/messenger/ 
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
> 
> 

Marco Lima    
J. A. P. H.      

marco.lima em e-via.com.br
mago em rio.pm.org

+55 19 96 56 06 46

Sociedade Perl do Brasil   |   http://www.perl.org.br
Perl Monks                 |   http://www.perlmonks.org
Brasil Perl Mongers        |   http://brasil.pm.org

Register Linux User #355235
Slackware Linux, for the subgenius