[OT] XUL - uma linguagem, um conceito, uma sigla.

Esqueci de postar algumas referências sobre XUL.

[quote:52e7c29153=´Refências sobre XUL´]
[url=http://twiki.im.ufba.br/bin/view/XUL]XUL Brasil[/url]
[url=http://br-linux.org/linux/?q=node/1315]Análise do Firefox ´Deer Park´ Alpha 2[/url]
[url=http://www.univale.com.br/livre/2_sslu_br.htm]Algumas palestras sobre XUL em Outubro[/url]
[url=http://pt.wikipedia.org/wiki/XUL]XUL no Wikipédia[/url]
[/quote:52e7c29153]

Cara... tipo... será que tem como eu usar esse XUL nas minhas aplicações!? Será que alguem já tentou isso? :D

Pelo que deu pra entender, XUL é pra aplicações web, e não tem nenhum segredo.

Também pelo que entendi, já existe os componentes criados (botões,labels), como em Java e Delphi através de uma API (nesse XUL não sei como é que seria), basta implementá-los. O que eles fazem ou deixam de fazer é implementado via JavaScript.

Se for mesmo isso, não há necessidade de utilizá-lo, já que qualquer componente html pode ter eventos JavaScript. A não ser que haja alguma especificação importante, algumas funcionalidades extras, etc.. Darei uma pesquisadinha, quem sabe faço um exemplo aqui pra galera.

:wink:

[quote:c1f527aa01=´Adriano Santos´][color=blue:c1f527aa01][b:c1f527aa01]Você já estudou isso (XUL)?[/b:c1f527aa01][/color:c1f527aa01]
ou
[color=blue:c1f527aa01][b:c1f527aa01]Você já estudou algo que nem imagina onde, como e porque irá utilizar?[/b:c1f527aa01][/color:c1f527aa01][/quote:c1f527aa01]

Respondendo à primeira pergunta: Não, ainda vou pegar uma noite pra estudar XUL.

Respondendo à segunda pergunta: Sim, quando comecei com Java, eu nem sabia por onde começar direito. Eram tantas coisas (j2se, j2me, j2ee). :D

É ai que quero chegar [b:1d0c166d7f]titanius[/b:1d0c166d7f]. Como podemos, em Delphi, usufruir de tecnologias como esta para melhorar cada vez mais nossos aplicativos?

Tenho participado ativamente do [url=http://forumgdh.net/index.php]FórumGDH[/url] onde existem duas comunidades que discutem sobre [url=http://forumgdh.net/viewforum.php?f=32]FireFox[/url] e [url=http://forumgdh.net/viewforum.php?f=33]Thunderbird[/url]. Perguntei por curiosidade qual linguagem são desenvolvidos os aplicativos. São em C/C++ e suas intefaces em XUL como já havia mencionado.

[quote:1d0c166d7f=´Veja mais´]

[url=http://forumgdh.net/viewtopic.php?t=294598&highlight=]Curiosidade: Em qual(s) linguagem(ns) o FF e o TB são feitos[/url]

Código que forma a base (e que precisa ser rápido) é em C++:
http://lxr.mozilla.org/mozilla1.8/source/content/base/src/nsHTMLContentSerializer.cpp

Já o que pode ser feito através da plataforma Mozilla é JavaScript:
http://lxr.mozilla.org/mozilla1.8/source/browser/base/content/browser.js

Tem tambem em C. Nesse caso o próprio JavaScript. Smile
http://lxr.mozilla.org/mozilla1.8/source/js/src/jsgc.c (foi modificado ontem)

Esses arquivos são do Fx2
[/quote:1d0c166d7f]

Imagina desenvolver sistemas onde você possa trabalhar em paralelo com XUL desenvolvendo pequenas extensões para atender um ou outro cliente? Ou seja, ao invés da manutenção ficar focada totalmente em cima do executável vc faz apenas grandes atualizações no fonte o restante fica por conta das ´interfaces´ XUL, assim vc ´personaliza´ o software a medida que seu cliente solicita. Legal a idéia né?

Não [b:041dfccfd4]agsilva[/b:041dfccfd4], não é só WEB, pois como disse o Thunderbird e Firefox utilizam XUL para modelar e até criar novas funcionalidades no aplicativo. E sabemos que ambos são aplicativos desktop. Existe um termo usado por esta técnica chamado de [url=http://pt.wikipedia.org/wiki/Widget]widget[/url] que consiste em [i:041dfccfd4]componentes de interface gráfica com o usuário[/i:041dfccfd4] (fonte: Wikipédia).

Outros trechos sobre Widget:

[quote=´Widget´]
[i:041dfccfd4]Qualquer item de uma interface gráfica é chamada de widget...[/i:041dfccfd4]
[i:041dfccfd4]Outro ponto que pode ser colocado como Widgets são pequenas janelas que ficam no desktop[/i:041dfccfd4]

Sobre Widget:

http://pt.wikipedia.org/wiki/Widget

Tem algo parecido no .NET 3.0...

http://en.wikipedia.org/wiki/XAML

Ou em português: http://pt.wikipedia.org/wiki/XAML

Legal isso hein Massuda?

[quote:64c6b85bdf=´Adriano Santos´]

Não [b:64c6b85bdf]agsilva[/b:64c6b85bdf], não é só WEB, pois como disse o Thunderbird e Firefox utilizam XUL para modelar e até criar novas funcionalidades no aplicativo. E sabemos que ambos são aplicativos desktop. Existe um termo usado por esta técnica chamado de [url=http://pt.wikipedia.org/wiki/Widget]widget[/url] que consiste em [i:64c6b85bdf]componentes de interface gráfica com o usuário[/i:64c6b85bdf] (fonte: Wikipédia).

Outros trechos sobre Widget:

[/quote:64c6b85bdf]

Opa, foi falta de atenção minha mesmo quanto a utilização em desktop.

Só não entendi uma coisa: qual seria a utilização/benefício dessa tecnologia? Haveria um melhor separação de camadas da aplicação, não misturando negócios com visualização (isso acontece com Java utilizando o padrão de arquitetura MVC)?

:wink:

[quote:f596dd16ef=´Adriano Santos´]

É ai que quero chegar [b:f596dd16ef]titanius[/b:f596dd16ef]. Como podemos, em Delphi, usufruir de tecnologias como esta para melhorar cada vez mais nossos aplicativos?

Tenho participado ativamente do [url=http://forumgdh.net/index.php]FórumGDH[/url] onde existem duas comunidades que discutem sobre [url=http://forumgdh.net/viewforum.php?f=32]FireFox[/url] e [url=http://forumgdh.net/viewforum.php?f=33]Thunderbird[/url]. Perguntei por curiosidade qual linguagem são desenvolvidos os aplicativos. São em C/C++ e suas intefaces em XUL como já havia mencionado.

[quote:f596dd16ef=´Veja mais´]

[url=http://forumgdh.net/viewtopic.php?t=294598&highlight=]Curiosidade: Em qual(s) linguagem(ns) o FF e o TB são feitos[/url]

Código que forma a base (e que precisa ser rápido) é em C++:
http://lxr.mozilla.org/mozilla1.8/source/content/base/src/nsHTMLContentSerializer.cpp

Já o que pode ser feito através da plataforma Mozilla é JavaScript:
http://lxr.mozilla.org/mozilla1.8/source/browser/base/content/browser.js

Tem tambem em C. Nesse caso o próprio JavaScript. Smile
http://lxr.mozilla.org/mozilla1.8/source/js/src/jsgc.c (foi modificado ontem)

Esses arquivos são do Fx2
[/quote:f596dd16ef]

Imagina desenvolver sistemas onde você possa trabalhar em paralelo com XUL desenvolvendo pequenas extensões para atender um ou outro cliente? Ou seja, ao invés da manutenção ficar focada totalmente em cima do executável vc faz apenas grandes atualizações no fonte o restante fica por conta das ´interfaces´ XUL, assim vc ´personaliza´ o software a medida que seu cliente solicita. Legal a idéia né?[/quote:f596dd16ef]

Não conheço a linguagem C, mas pelo que parece ela não tem suporte/componentes para interface gráfica com o usuário. O resultado é em linha de comando, ou estou enganado? Se isso for verdadeiro, então fica fácil entender a adoção do XUL em aplicações desenvolvidas em C. Agora, em C++, não vejo real necessidade, bem como em Delphi, Java, etc.. Agora, a coisa muda se o que você disse é verdadeiro, isto é, você importa-se apenas com as regras de negócio da aplicação, enquanto o XUL cuida da interface com o usuário pra você.

:roll:

Sem problemas. :wink:



A separação de regras de negócios e design seria uma das vantagens, isso se o programador não estiver usando n-tier (multi-camadas) porque neste caso não seria interessante.

Porém vejo de outra forma. Vou dar um exemplo de utilização de extensões no Thunderbird.
Recebo um grande volume de emails diariamente e por isso necessito ter o leitor aberto o dia todo.

Preciso ter no mínimo Delphi, IbExpert e o Thunder abertos. O Thunder não tem um esquema para minimizar a aplicação para a bandeja do Windows, por isso existe uma extensão que agrega esta funcionalidade ao TB. Basta abrir o programa e mandar minimizar. Show, tenho uma janela aberta a menos e ainda por cima recebo minhas mensagens tranquilamente.

Essa é uma funcionalidade simples, e talvez desnecessária para alguns. Mas em um software comercial poderia significar uma nova funcionalidade para um determinado cliente. Vc manda somente a extensão para o cara e ele instala, sem precisar alterar e enviar o executável original.

[b:e20b6d667f]agsilva[/b:e20b6d667f] foi mais rápido que Eu, estava respondendo a sua pergunta anterior quando confirmei e chegou esta. A resposta será parecida.


Conheço bem pouco de C, pra falar a verdade só o conceito e a sintax.
Até onde sei você está correto. Não há suporte a componentes visuais.
Se não me engano o [b:e20b6d667f]Massuda[/b:e20b6d667f] conhece C, não tenho certeza.



Veja, novamente o caso aqui não é só Visual, não é só design. Não estudei XUL ainda, estou lendo algumas coisas. O pouco que li me diz que posso não somente desenvolver um novo layout como também janelas com funções e procedimentos novos.

[quote:e20b6d667f=´Dois tópicos que postei na comunidade da Mozilla´]
[url=http://forumgdh.net/viewtopic.php?t=294598&highlight=]Curiosidade: Em qual(s) linguagem(ns) o FF e o TB são feitos[/url]
[url=http://forumgdh.net/viewtopic.php?p=2275254#2275254][OT] Desenvolver Plug-ins, como?[/url]
[/quote:e20b6d667f]

Se conseguisse isso no Delphi ficaria muito bom... :D

agora mexer com .NET.. vixi... outra historia... hehe...

[]s

[b:365efa5066]titanius[/b:365efa5066] o q vc quis dizer com o ´vixi...outra historia...´? :lol:
Depois que participei do evento Webdays e vi .NET e como desenvolver com ele, fiquei com uma visão bastante diferenciada sobre o assunto. Hoje vejo a tecnologia com outros olhos, não que eu vá migrar agora ou daqui 10 anos, mas está tudo mais claro.

[quote:3c70281ab7=´Adriano Santos´]

[b:3c70281ab7]titanius[/b:3c70281ab7] o q vc quis dizer com o ´vixi...outra historia...´? :lol:
Depois que participei do evento Webdays e vi .NET e como desenvolver com ele, fiquei com uma visão bastante diferenciada sobre o assunto. Hoje vejo a tecnologia com outros olhos, não que eu vá migrar agora ou daqui 10 anos, mas está tudo mais claro.[/quote:3c70281ab7]

Eu não tenho essa ´visão´ e no momento estou meio sem tempo até pra procurar sobre o assunto... se tudo der certo, no ano que vem (sem faculdade) vai dar pra eu iniciar neste assunto... mas no momento fico no Win32 mesmo...

Só que tive um pequeno ´probleminha´... instalei o beta do Windows Vista.... e nenhum programa meu funcionou nele.. :(

Claro que deve ter algo pra fazer.. mas infelizmente, ou felizmente, é isso... .NET é o futuro...

Olha só o que um camarada do fórum da Mozilla me respondeu sobre o XUL. Eu ainda tinha ficado com dúvidas quanto a algumas coisas.



[quote:6432d8b847=´Alberto E. Kuniyoshi´]
A linguagem XUL permite além de criar a GUI da extensão, também cria a funcionalidade da mesma.



Dê uma olhada neste tutorial que é apresentado neste artigo do br-linux: http://br-linux.org/linux/como_criar_uma_extensao_para_o_firefox (detalhe que está em espanhol, mas aparenta estar muito bem explicado :))
[/quote:6432d8b847]
[/quote:6432d8b847]

Tópico completo: [url=http://forumgdh.net/viewtopic.php?t=300425][OT] Desenvolver Plug-ins, como?[/url]

A tecnologia me parece interessante, porém você corre sérios riscos de desenvolvimento de extensões nocivas à sua aplicação, ou estou enganado?

Se eu estiver certo, em aplicações que precisam de homologação, creio que isto seja inviável... No meu ponto de vista, uma Secretaria de Fazenda, por exemplo, nunca homologaria um software que permite extensões que agregam ou alteram suas proprieades originais.
E se homologasse, e alguém criasse uma extensão que permitisse alguma operação de fraude/sonegação fiscal, você responderia como co-responsável por permitir que o software sofresse influência externa.

Bem... é o que eu acho...

Vinicius... acho que está incorreta esta informação, ao meu ver, pois assim a Microsiga teria problemas com o seu Protheus... pois ele é homologado em todo o país... e permite que o usuario (quem comprou) programe em cima do sistema, numa linguagem chamada ADVPL, ou seja... se o cara quiser ele modifica o sistema inteiro.. eu mesmo trablahei numa empresa em que foi modificado o sistema de N.F.... ou seja... acho que o sistema é bom... se o usuario fizer algo em cima dele, é problema do usuário e sua responsabilidade...

Sei lá, algum amigo que etenda mais desse assunto poderia se expressar aqui...

Mas esse sistema de ´Plugin´, poutz.. achei muito interessante... qum sabe nao achamos um para o Delphi.. :D

[]s

Entendo...

Mas o exemplo que você citou não é muito bom para exemplificar o que eu quis dizer. ERPs ou Retaguardas são regulamentados por legislação fiscal específica porém não sofrem processos de homologação por secretarias de fazenda dos estados. Só são auditados em caso de fiscalização com suspeita de fraude/sonegação.

Longe de mim, pobre mortal, querer comparar meu ERP com o da Microsiga, porém alguns conceitos eu já utilizo em minhas aplicações há bastante tempo, como, por exemplo, construção de consultas e relatórios pelo próprio usuário, parametrização, etc. No exemplo que você citou, meus clientes podem parametrizar todo o faturamento, alterando totalmente como emitir suas Notas Fiscais e, quando emitidas, quais são os sub-processos executados pelo faturamento.

Mas estas aberturas para personalização são proibídas de existirem em ´Programas Aplicativos Fiscais´, falando em bom português, os PDVs. Quando você envia para registro e homologação, todo o software é analisado e são gerados hashes MD5 dos executáveis. Se mudar uma vírgula de lugar, muda-se o hash e, consequentemente, novo processo de homologação.

Os módulos de faturamento e fiscal de um ERP são tratados pelo estado como PED (Processamento Eletrônico de Documentos) e deve seguir algumas regulamentações, porém não totalmente ´travados´ como os PDVs.

Se você me disser que o [b:2324c13c10]software de automação[/b:2324c13c10] da Microsiga permite que os usuários alterem como ele trabalha com o ECF, então eu mudaria completamente de opinião...

[quote:9d629d4939=´Adriano Santos´]
Sem problemas. :wink:



A separação de regras de negócios e design seria uma das vantagens, isso se o programador não estiver usando n-tier (multi-camadas) porque neste caso não seria interessante.

Porém vejo de outra forma. Vou dar um exemplo de utilização de extensões no Thunderbird.
Recebo um grande volume de emails diariamente e por isso necessito ter o leitor aberto o dia todo.

Preciso ter no mínimo Delphi, IbExpert e o Thunder abertos. O Thunder não tem um esquema para minimizar a aplicação para a bandeja do Windows, por isso existe uma extensão que agrega esta funcionalidade ao TB. Basta abrir o programa e mandar minimizar. Show, tenho uma janela aberta a menos e ainda por cima recebo minhas mensagens tranquilamente.

Essa é uma funcionalidade simples, e talvez desnecessária para alguns. Mas em um software comercial poderia significar uma nova funcionalidade para um determinado cliente. Vc manda somente a extensão para o cara e ele instala, sem precisar alterar e enviar o executável original.[/quote:9d629d4939]

Ah sim, agora que foi cair a ficha: o XUL trabalha com suporte a plug-ins instaláveis, não se limitando a isso. Desenvolvo aplicações web com a linguagem Java, utilizando a IDE Eclipse. Esta, é baseada quase que totalmente em plug-ins. Um exemplo:

- Instalo o Eclipse e quase não vejo nada de empolgante, apenas algumas rotinas e um suporte para desenvolvimento Java. Mas se você for conferir, existem centenas de plug-ins desenvolvidos por aí, desde verificadores automáticos para melhorar a qualidade do código (como PMD), para desenvolvimento em C#, para gerenciadores de relatório (como BIRT), para suporte a Java EE, para escrever documentos XML, etc..

Isso é o que faz essa IDE ser magnífica e a mais utilizada pelo mundo Java (não se limitando a essa linguagem, mas tomando-a como foco). Imagina nossos softwares sendo desenvolvidos dessa maneira, onde uma aplicação é básica com alguns recursos. À media que o cliente vai criando novos requisitos, vamos nós desenvolver novos plug-ins. É só enviar pra ele, via email mesmo, uma rotina que instala na sua aplicação o plug-in. Agora, quando um cliente não querer tal requisito, é só desinstalar o plug-in, e não fazer uma versão totalmente nova.

Hoje vemos o SOA (Aplicação orientada a serviços) como uma maneira de dividir serviços da nossa aplicação e integrar outros já existentes. O XUL pode ser uma forma de elevar mais os projetos, dividindo a aplicação em plug-ins. Show!

:wink:

Por que .NET? Faz com C/C++, o que não tem absolutamente nada a haver com a primeira.

:wink:

Caro Vinicius, acho que o propósito do uso do XUL, não é alterar rotinas já programadas, como as que você citou, e sim, desenvolver e aplicar novas [b:a1e7f45136]funcionalidades[/b:a1e7f45136] ao sistema. Isso quer dizer na prática, num simples exemplo, que não iríamos alterar como o cadastro de clientes é feito, e sim, adicionar a funcionalidade de exportar, quando confirmar os dados, para documentos do OpenOffice (ou Word, como preferir).

Claro, alterar formulários e rotinas pode ser feito, mas acho que esse não seria o foco, ou mesmo propósito real do XUL. Veja, nos exemplos citados como Firefox, Thunderbird, Eclipse, etc., não há plug-ins que alteram a forma como algo é suportado no programa, e sim, adicionamos funcionalidades à medida que precisamos.

:wink:

Exatamente o que eu quis dizer e que, por falta de boa expressão, talvez não tenha ficado claro e o assunto acabou se desviando para itens do cotidiano como ERPs e PDVs, mas não era essa a questão que gostaria de propor.

Creio que a principal questão é: Qual será o foco desta tecnologia para nós? Como poderíamos utilizá-la no dia-a-dia?
Porque existem projetos aonde penso que, por força das leis, não poderemos empregá-la.
Em contra-partida em outros projetos posso pensar em algumas boas soluções, como, por exemplo exibição de interfaces diferentes para uma mesma classe sem necessidade de mudança do executável base.

Penso que trabalhar estas variações entre clientes com extensões ao invés de compilações diferentes ou DLLs me parece uma solução melhor.

Um dos problemas que penso que poderão existir é ´alguém´ desenvolver extensões para uma aplicação sua. Extensão esta que altere alguma caracterísca ou que comprometa a segurança dos dados ou o funcionamento da própria aplicação. Este é um risco que corremos quando instalamos extensões do FF, por exemplo.

Longe de mim também querer comparar o meu com eles.. :wink: o que quiz dizer era exatamente isso.. agora, devo ter me expressado mal, pois nao conheco nada de legislacao.. entao pra mim era a mesma coisa que um PDV...

Mas o que a Microsiga faz, é exatamente o que esse tal de XUL é proposto a fazer... ou seja, deixa o usuário modificar o sistema, nao importa onde... e entra aí o problema que o [b:bda641c30b]vininius[/b:bda641c30b] falou sobre seguranca...

E estou a bastante tempo tentando fazer algo parecido.. já tentei o PascalScript mas o trabalho é imenso para fazer...

Você não irá mais precisar refazer uma versão inteira do seu projeto só porque o cliente atual pediu mudanças drásticas. Você apresenta a aplicação completa pra ele, o mesmo vai retirando as extensões que desejar, e ao longo do tempo, com o desenvolvimento de plug-ins, o projeto vai ficando maduro. Em questão de tempo, não haverá mais quase nada a fazer para os próximos clientes. Eles irão pedir, e as extensões podem ser desinstaladas ou instaladas.

Bom, resumindo e ressaltando: Não refaremos mais uma versão do projeto inteiro para cada cliente. Há apenas a distribuição de extensões.



Cara, acho que não há problemas com a justiça. A própria Microsoft distribui atualizações pro Windows, não sei se pode se aplicar, mas talvez isso seja o mesmo que distribuir plug-ins. Até porque, o cliente não paga pelo programa, ele paga pela licença do programa, é diferente. Então, ao meu ponto de vista, não há o porque de a justiça cair em cima. Ah, mas é claro, é importantíssimo especificar no contrato, que o programa irá depender de extensões, porque existe muitos clientes por aí, que já viu né...



Bom, talvez eu esteja enganado, mas acho que você pode fazer um esquema de autorizações para plug-ins, ou mesmo uma técnica de versionamento, não sei. Uma coisa é: só você conhece as regras de negócio do seu projeto, a não ser que o mesmo seja distribuído no modo OpenSource. Então, ao meu ver, isso impossibilita um pouco outro programador de desenvolver extensões para o seu projeto.

O XUL foi desenvolvida pela Mozilla, que distribui tudo OpenSource, isto é, código aberto (mas não é software gratuito). Com certeza, essa linguagem é justamente pra ser desenvolvida pela comunidade do código aberto, e não por grandes empresas. Isso assusta, mas vamos pensar: só você conhece as regras de negócio do seu projeto. Isso já é um peso para outros programadores que queiram alterar seu sistema. Outra coisa também, é uma simples técnica de autorização, isso não é difícil, uma coisa simples de se desenvolver no Delphi. Também dá pra se utilizar de alguma técnica de versionamento, sei lá.

:wink:

Não é bem ´justiça´ e sim legislação tributária estadual/federal. Só para você entender +/- como funciona automação comercial, sintegra, livros fiscais, etc... e fazer uma idéia que que ´pé no...´ que é isso:

O software é totalmente analisado pelo estado a fim de garantir que ele não proporciona formas de sonegação fiscal, se comprovado ele é homologado e você autorizado a comercializá-lo, porém são retirados hashes (assinaturas) dos arquivos que compoem a parte executável do programa, incluindo-se DLLs e eventuais extensões. A qualquer alteração realizada em um destes componentes a assinatura muda, o que lhe obriga a efetuar nova homologação.

O software, não pode, de nenhuma forma estar sujeito a sofrer influência externa de usuário ou outra forma qualquer. Por isso *acho* muito difícil que extensões possam ser permitidas por estes órgãos governamentais.

Em casos de fiscalização (o que é frequente) se o software que o cliente utiliza tiver uma assinatura diferente da que você homologou, ele (o cliente) [b:154cb04394]e você[/b:154cb04394] são autuados por crime de sonegação fiscal.

Por isso eu acho que este conceito, dificilmente, poderá se aplicado neste tipo de aplicação. Logicamente, em outras com certeza!

É, aí realmente complica. Mas vejamos, você desenvolve o produto, e depois de um curto tempo de uso, o cliente pede mudanças. Seria necessário uma nova homologação do software. Acho eu que isso não pode ser aplicado nos dias de hoje. Software muda muito e não é viável dezenas de homologações.

Bom, o que devemos fazer é interar-nos sobre o assunto, saber sobre outros métodos de venda de software. Será que a venda de softwares como serviço, isto é, On Demand, não se adequaria?

Pesquisei no Google sobre outros modos de venda, mas não obtive nenhum sucesso. Alguém que conhece sobre técnicas de venda, poderia conferir no site da receita, ou através do telefone, não sei.

:?

Pronto, agora sim o exemplo M. Windows se aplica direitinho no contexto. A cada atualização muita coisa muda, DLLs são alteradas, etc..

Acho que aplicações baseadas em extensões não se aplicam a ERPs ou sistemas que trabalham em cima de faturas e fluxo de caixa, porque aí sim, a homologação é fatal (grana no meio).

:roll:

Exatamente... uma ´vírgula´ em outro lugar e todo o processo deve ser refeito: homologação para transferência eletrônica de fundos nas operadoras de cartão de crédito e homologação fiscal na receita estadual. E agora, aqui em Minas, estão enfiando-nos ´goela abaixo´ um terceiro processo que é um ´Laudo técnico de funcionalidade´ do software o qual custa R$ 1.500,00 (cada vez que passar pelo processo).

Você pode usar qualquer modalidade para venda da licença do software, até fornecer gratuitamente para o cliente, com isso a receita não se importa, contanto o software que o cliente usa, em sua exata versão, seja homologado. E ponto final. Simples assim (para eles) e um suplício para quem trabalha com isso...

Até o momento eu não tenho solução de PDV. Estou contruindo-a e deve estar pronta até o final do ano. Portanto, ao menos por enquanto só passo por isso no que se refere ao ERP (que não necessita de homologação, mas mesmo assim pode sofrer auditoria).
Sei da ´luta´ que é isso, através de colegas da área e mesmo das empresas que fornecem as soluções de PDV para meus clientes de ERP.

Estamos desviando o assunto novamente :)

Muito boa a explanação de todos e as idéias de cada um. De verdade não achei que daria tanto pano para manga. :wink:

Concordo plenamente com o [b:c8569e9403]Vinicius[/b:c8569e9403] em se tratando de projetos que requerem homologações por parte dos mais diversos orgãos que conhecemos. De fato, também acho bastante difícil ocorrer a homologação de um sistema como estes, que pode sofrer pequenas ´alterações´ de comportamento advindas de uma ´força externa´. Porém, como disse outro colega, as extensões não fariam a mudança total do sitema ou de uma determinada rotina. Ex. O Thunderbird é um leitor de e-mail e continuará lendo emails independente de quais extensões estão instaladas. Ninguém vai criar algo pra que pare de ler emails e vire um navegador internet. É grosseiro o que digo, mas é isso. As extensões devem vir com o propósito de facilitar uma dada tarefa ou adicionar uma funcionalidade.

Querem mais exemplos do que ocorre hoje no Thunder pelo menos pra mim?
Quando a gente dá um [i:c8569e9403]Enviar e Receber[/i:c8569e9403] no Outlook Express, aparece uma caixa de diálogo mostrando quantos emails de quantos estão vindo, o tamanho deles e etc. No thunder não tem isso, estou ansioso aguardando alguém criar uma extensão que o faça. Só não desenvolvo pq não sei. Isso seria facilitar a vida do usuário.

Num software comercial vejo a extensão como algo que agregue algum valor ao sistema e inclua funcionalidade. Imagine que seu cliente ´A´ deseja que na tela de clientes exista um botão para exportar o endereço de e-mail de cada cliente em um arquivo texto...bom isso é simples de se fazer, é só pra entendermos mesmo. Ao invés de vc criar este botão no executável base vc cria uma extensão e instala.
Somente este cliente terá o botão. Daí sim, acho super interessante. Como disse outro colega: ´ao longo do tempo vc terá uma serie de extensões que poderão ser distribuidas a medida que forem sendo solicitadas´.

Concordo também com o Vinicius que a segurança poderá ficar comprometida, tendo em vista que alguém poderá desenvolver uma extensão capaz de instalar um trojan, spyware, roubar dados do soft e etc, porém neste caso nossos sistemas costumam ser bem específicos não sendo de interessante de crackers ou programadores sacanas e ainda por cima as extensões devem ficar a cargo somente da empresa que as desenvolve, ou seja, eu vendo o sistema pra vc e [b:c8569e9403]somente[/b:c8569e9403] eu desenvolvo as extensões, pois ´eu´ conheço as regras de negócios do sistema que vendo.

Outro ponto, pra fechar, fiquei pensando na manutenção. Hoje FórumGDH (como disse participo ativamente) vejo muitos usuários com problemas no Firefox. Eu mesmo já tive algum tipo de problema. E quando vamos ver é alguma extensão que, não alterou, mas causou alguma falha no funcionamento do navegador.

Imagina o seu cliente te dizendo que deu um erro no programa. Vc terá que saber se é o programa ou alguma extensão provocando o erro. Se for extensão, pow legal. Conserta e reenvia a atualização, como se fosse uma dll ou módulo bpl.

É isso.

[quote:43da0d38cf=´Adriano Santos´]Imagina o seu cliente te dizendo que deu um erro no programa. Vc terá que saber se é o programa ou alguma extensão provocando o erro. Se for extensão, pow legal. Conserta e reenvia a atualização, como se fosse uma dll ou módulo bpl.

É isso.[/quote:43da0d38cf]

Só pra animar a galera:



Resultado = Dor de cabeça e café reduzidos + Cliente boquiaberto com o que acaba de ver.

Ah, esse exemplo, que é totalmente aplicável, também confirma que a linguagem não serve apenas para o visual da sua aplicação, como Skins (argh!), e sim, como regras de negócio instaláveis.

:wink:

Perfeito, e se você quiser deixar o sofware ainda mais experto pode criar um atuaizado de extensões assim como no FF/TB.


Acima é a tela de Temas do FireFox, mas a tela de Extensões é igual e sempre que uma extensão é atualizada o botão Atualizar agora fica ativo.

Tudo bem, podemos fazer a atualização do nosso software também automaticamente como os anti-vírus fazem atualmente. Porém, a extensão teria 200k no máximo, olha a rapidez disso. :wink: :wink:

Sim, uma tecnologia como essa pode mudar nossas vidas radicalmente. À muitos, podem impressionar um chefe, impressionar um cliente, diminuir tempo de trabalho, etc..

Mas isso tudo, só terá efeito na prática, se realmente isso for viável de acordo com a legislação. Se não, apenas poderemos utilizar em nossos projetos OpenSource, ou criar algumas extensões.

:cry:

Então, enquanto não descobrimos outras formas de venda, ao menos podemos implementar esta tecnologia nos ERPs. Certo?

:?