|
gildot |
|
| |
| Contribuído por jmce em 16-07-00 12:47 do departamento killer-apps | | | | | | | Foi lançada a versão 2.2 do Zope. Esta versão procura responder, com um sistema de permissões particularmente cuidadoso, ao problema de segurança de administração via WWW designado por server side trojan, "descoberto" quase ao mesmo tempo que o problema de client side trojan (já aqui referido) e traz-nos um novo sistema de ajuda online, um tutorial, mais performance... Foi também lançado o dev.zope.org, que vai ser o centro da abertura do processo de desenvolvimento do Zope, sistematizando as contribuições externas. [mais no desenvolvimento] | | | | | | O Zope é um "servidor de aplicações" que facilita a criação e a gestão de serviços WWW dinâmicos através de um conjunto de componentes bem integrados, escritos em Python e C, com: - servidor WWW baseado no Medusa;
- uma base de dados de objectos, com suporte para "undo", especialmente "talhada" para uso na web, onde podem ser guardados objectos heterógeneos a cada um dos quais corresponde um URL e arrumados segndo uma estrutura hierárquica análoga à de directórios e ficheiros num sistema de ficheiros
- aquisição: um objecto não deriva apenas propriedades e conteúdo da sua classe mas também dos objectos que o contêm; se por exemplo criarmos um objecto "header" num certo folder, todos os objectos não apenas nesse folder mas também nos abaixo dele poderão usar o "header"; isto facilita por exemplo a "factorização" do elementos dos documentos a apresentar e a gestão das partes comuns a muitas páginas de um sítio;
- mecanismos de pesquisa;
- sistema para "templating" de documentos e partes de documentos, com uma linguagem (de tags inseridas no conteúdo) com acesso ao uso de expressões em Python mas incluindo limitações necessárias para prevenir problemas de segurança (vistos em sistemas análogos que deixam realizar operações arbitrárias); quando o algoritmo for mais fácil de exprimir como código "vulgar" ou incluir operações mais "sensíveis", é adicionado separadamente e (por exemplo) integrado como um "método externo";
- interface de gestão via http e ftp;
- suporte para criação e distribuição de extensões;
- controle de acessos muito flexível que facilita a gestão em equipa e permite delegação sucessiva de autorizações (pode dar-se permissões diferentes a grupos diferentes, e deixá-los sub-delegar parte dessas permissões);
- acesso a bases de dados com SQL externas, com muitos adaptadores já criados; suporte para transacções nas bases de dados externas integrado com as transacções do próprio Zope;
- repetindo alguns: suporte de HTTP 1.1, FastCGI, FTP, WebDAV, DOM, XML (com desenvolvimentos muito interessantes), XML-RPC, SQL, RSS, LDAP, ...
- os incondicionais de Perl poderão escrever métodos nessa linguagem (e poderá aparecer suporte para outras);
- e a lista continuaria...
Trata-se de uma infra-estrutura muito "refrescante" para quem está farto da escrita fastidiosa de CGIs "from scratch" e de a tentar sistematizar... e mesmo para quem tem de manter serviços WWW coerentes com conjuntos de páginas práticamente estáticas.. Existem já um conjunto interessante de produtos para o Zope, a maior parte distribuídos como ele em regime "Open Source", como o Squishdot, um sistema para fóruns de discussão não tão extenso como o "slash" (usado no Slashdot e aqui no Gildot) mas já usado em alguns fóruns muito interessantes como o technocrat.net. Algumas apresentações mais cuidadas das capacidades do Zope podem ser vistas na devshed e no zope.org. < Programar.. onde? como? quando? | WAP phones: espada e feitiçaria > | | gildot Login | | | Referências | | |
Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | por Anonimo Cobarde em 16-07-00 15:08 GMT (#1) |
| Aproveitem e vejam também esta crítica ao Zope que apareceu no site LinuxWorld. O autor acusa os projectistas de se preocuparem em demasia em tornar o produto Object-Oriented (nerd oriented) em vez de o tornarem fácil de usar. |
| | | | | A documentação é um campo onde há muito a fazer. Outro lado do Zope que não aprecio muito são alguns aspectos do DTML pouco "python-like" no sentido em que há uma variedade razoavelmente grande de coisas a aprender e ter em conta e que talvez pudesse ser reduzido a um pequeno conjunto de ideias mais elegante e óbvio. A própria sintaxe é uma questão em estudo: há já projectos para a "limpar" e fornecer suporte para a conversão do DTML actual para o futuro. Zope is based on the programming language Python, but you don't need to write Python code to use it. You'll do most of your programming in Zope with the Document Template Markup Language (DTML). DTML is similar to HTML, so it's very easy to get started. Pode-se fazer muita coisa em DTML, de facto. Mas quem quer trabalhar mais a sério chega facilmente a situações em que exprimir alguns algoritmos directamente em python é mais eficaz. Umas vezes é mais fácil inserir código num documento (pequenos "if"s, valores de variaveis, etc, inseridos em DTML) em vez de estar a fazer um programa inundado de "print"s. Outras vezes a predominância do código é tão grande que é mais fácil programar algo parecido com um pedaço de CGI. De qualquer forma, em DTML usam-se expressões de Python; para quem nunca tiver percebido Python, muita coisa pode ser mais difícil de compreender, e grande parte da beleza do Zope deriva da do Python; há quem diga que o DTML até a estraga e esconde. DTML "semelhante" a HTML? DTML é algo que se usa DENTRO de um documento em HTML (e não só). O facto de os elementos (como <dtml-if ...>) estarem dentro de <...> parece-me irrelevante para a simplicidade. Talvez seja mais uma questão de tradição relacionada com o que acontece em outros produtos. [...] you have to edit much of your code in a browser text box. Expecting someone to code in a browser text box is considered a human-rights violation in most civilized nations, though it probably isn't severe enough to lose Most Favored Nation status for trade agreements. To be fair, there are ways to write DTML for your applications with your own editor, but they mean sacrificing the Web environment's seamless feel. De facto editar dentro da janela de um browser, com os browsers que temos, é horrível. Só que raramente isso é indispensável. Apenas o faço para pequeninas alterações; normalmente edito conteúdo usando Emacs/XEmacs via FTP (o ZServer proporciona este tipo de acesso). Curiosamente o autor diz que é mau viver dentro do browser para depois se queixar do "sacrifício" que é não continuar no "Web environment". Prefiro usar sempre o mesmo editor (no meu caso xemacs, mas há quem use vim com ftp também, por exemplo) do que ter que usar um editor novo por cada ambiente de desenvolvimento como algumas empresas tanto gostam. De qualquer forma, para quem quer um "seamless web environment", está em desenvolvimento o Mozilla Studio, que irá explorar as possibilidades do Mozilla. Zope attempts to be object-oriented programming (OOP) to the max. If you wanted to open an online shoe store, you would probably start by creating a shoe object based on the Zope ZClass. You would define the object as catalog-aware, which means you can do things like sort your shoe database. Tal como em Python, há uma orientação por objectos forte em Zope, mas também como no Python não somos, felizmente, forçados a ver o mundo todo segundo o lado mais purista dessa "filosofia" ou sequer a saber muito sobre ela. As ZClasses são uma das formas de resolver problemas, mas há muitas outras. Quem quer adoptar uma aproximação mais centrada em bases de dados relacionais pode fazê-lo (e para grandes volumes de dados com estrutura muito regular pode ser uma das boas técnicas a usar num projecto). Neste momento a documentação poderá ser algo pobre e certas interfaces insuficientes para quem está mimado por produtos supostamente de maior "produtividade", mas mesmo esses poderão supostamente ver o seu sonho realizado. Não conheço praticamente nada do Enhydra, mas parece estar mais rico em termos de interfaces, "papinha feita" em alguns domínios e "buzzword-compliance" com a agenda da Sun e outros "matulões" da indústria. Mas o simples facto de estar centrado em Java desmotivar-me-ia. Por um lado por estar "rendido" à elegância e liberdade do Python (onde se pode pensar de forma tão ou tão pouco "object-oriented" quanto se quiser) e por outro por ter muito mais confiança no futuro desta linguagem (que é Open-Source) que no de uma que me parece ainda sujeita aos caprichos da Sun e de mais alguns "big boys" depois de todo o hype inicial. O Zope irá também atrair aficionados de Perl com a possibilidade de incorporar Perl methods... É muito importante ter em conta que um dos objectivos importantes do Zope é ajudar a separação entre gestão de código e de conteúdo, o trabalho em equipas onde há diversas competências, pelo que a acusação de "nerd-oriented" me parece injusta. Mal irá a equipa de desenvolvimento de um serviço WWW se não incluir "nerds". Os responsáveis por conteúdo poderão limitar-se a alguns usos simples de DTML enquanto os "nerds" tratam do núcleo da funcionalidade, tudo isto suportado por gestão de permissões bastante interessante. Quem achar que pode, pouco sabendo da natureza destes serviços, trabalhar sozinho e ver o software fazer tudo, sucumba às promessas das ferramentas MS e sofra as consequências. I was a Java fan for a couple of years, so when I came to Zope I had some preconceptions about what constitutes an "object". I finally started to get the Zope and Python way of thinking when I realized you could assign arbitrary properties to objects--and those arbitrary properties are first class citizens in the language. For me, Java restricted me to a mindset that required perfection, while Python and Zope encouraged exploration without language-imposed limitations. Python made coding fun again. :-) -- Shane Hathaway |
| | | por Anonimo Cobarde em 17-07-00 13:11 GMT (#3) |
| Ena, finalmente o Gildot a prestar alguma atencao ao Zope e ao Python, depois de alguns artigos sugeridos "estrategicamente" ignorados. Aproveito para relembrar (um dos artigos ignorados) que o portal da Oni http://www.portal.pt/ foi todo reconstruido usando precisamente Zope e Python. Cummprimentos -- Mario Valente |
| | | | | Já numa sessão de IRC organizada por pessoal da Digicool, há uns tempos, houve alguém de Portugal que se me queixou de que o Gildot não dava atenção ao Zope, e que parecia que alguém o queria manter "em segredo" por ser tão interessante... Não me lembro de ter deitado fora alguma notícia sobre Zope, e também não vejo razões para outros o terem feito, pelo menos com esse "fundamento". Será que se conseguiria realmente esconder alguma coisa? Seria um gato escondido com uma cauda muito grande de fora... (ou vice-versa). Quanto à ONI, tinha ideia de um serviço ter sido criado em Zope, mas não sabia ainda que o portal.pt tinha sido já todo reciclado com ele... Já agora, caso alguém saiba... Porquê Zope sobre NT? |
| | | por Anonimo Cobarde em 17-07-00 17:35 GMT (#6) |
| >Gildot não dava atenção ao Zope, e que parecia >que alguém o queria manter "em segredo" >Não me lembro de ter deitado fora alguma notícia >sobre Zope Houve pelo menos dois artigos sugeridos por mim, ja' em Novembro passado, sobre o Magazine da Oni e sobre o seu site de jogos serem feitos em Zope e a proposito de novos desenvolvimentos em Python/Zope, que foram "ignorados" Quanto ao "manter em segredo" e' no minimo estranho que alguns dias depois tenham aparecido sites feitos em Zope (e Squishdot em particular) por pessoas ligadas ao Gildot. E' de lembrar que o Squishdot+Zope permite a qq um criar um Gildot killer.... >Porquê Zope sobre NT? Because you can! :-) Refira-se que o desenvolvimento foi todo feito em plataforma Linux. Portar para a plataforma do cliente (NT....) foi tao simples quanto copiar um ficheiro. Cumprimentos -- Mario Valente |
| | | | Continuo a achar algo "puxada" a ideia de alguém tentar "esconder" notícias sobre um produto, e logo num fórum na Internet... O Gildot está longe de ser a principal fonte de informação sobre novo software para quem desenvolve software em Portugal, ou estou enganado? (Mal estarão se não se informarem regularmente em mais de um sitio...). Ter uma atitude dessas seria no mínimo provinciano. Sem querer atirar certezas, há outras razões mais simples pelas quais algumas notícias nao aparecem: problemas de links, desactualização (algumas raras vezes, infelizmente, por ter de uma forma ou outra passado demasiado tempo até algum editor notar uma sugestão mais atentamente), receio de estar a fazer publicidade (lembro-me de casos de aplicações de software livre para construir serviços de empresas portuguesas em que se receou estar a fazer publicidade de algum tipo), etc... Há fases com poucas notícias submetidas, outras com muitas onde se acaba por ter de escolher, e eventualmente de forma injusta: o que para um editor é muito relevante pode ser uma notícia de menos importância para outro. As disponibilidades de tempo dos editores também variam muito. Quando acharem estranha a rejeição de um artigo, sugiro que escrevam para os editores para esclarecer o que se terá passado... É melhor do que construir "offline" teorias de conspiração ou atitudes "Calimero-like" ("it's an injustice, it is"). Por acaso, se com a release do 2.2 e algum tempo livre me ocorreu fazer uma notícia mais desenvolvida apresentando o Zope, foi em parte por causa da reclamação que me foi feita na tal sessão de IRC (e em parte por causa do meu crescente entusiasmo com este produto), caso contrário teria talvez ficado pelo anúncio da nova release. Quanto ao Python, já têm aparecido aqui diversos "fãs" a glorificar a linguagem em alguns threads, embora reconheça que tem sido muito desprezado nos próprios artigos, e eu próprio poderia ter criado alguns deles, dado o uso regular que tenho feito da linguagem. Quanto a "qualquer um" fazer um "Gildot killer" com o squish... na verdade muita da funcionalidade presente no código do slash ainda não existe no squishdot, pelo que haveria muito mais envolvido do que acertar layout e ajustar parâmetros... Mas sim, o essencial para fazer um fórum razoável rapidamente está lá, e o squish está gradualmente a ficar mais "limpo". E sobre o NT: "Because one can"? Que se podia eu sabia (vivam ferramentas como o Python e o Perl pelo que permitem fazer sem grandes mudanças em "ambientes hostis"). A curiosidade era sobre a razão do uso da plataforma, mas não me tinha ocorrido que a ONI fosse apresentar um tal constrangimento. Mesmo com o Zope a funcionar bem, há riscos e inconvenientes intrínsecos da plataforma... |
| | | | E' de lembrar que o Squishdot+Zope permite a qq um criar um Gildot killer.... Knock! knock! knock! Acorda! O gildot é código de slashdot que todos podem ir buscar pôr a correr! Nem sequer é preciso andar a procurar implementações alternativas! Mas a maior ingenuidade é mesmo achar que o essencial do gildot é o código que está a correr e não o facto de ter reunido o conjunto de malta que por aqui andamos a mandar bitaites (e às vezes a ler umas parvoices). |
| | | | Para quem não quiser procurar muito , existe o nuke , que é bastante semelhante ao slashdot como ao gildot tanto com aspecto como em funcionalidades. A diferença é que é feito em php3... Para quem quiser ir buscar www.linuxpreview.org |
| | | por Anonimo Cobarde em 19-07-00 11:50 GMT (#11) |
| Bem podes limpar as maos a parede, pelo novo portal. |
| | | por Anonimo Cobarde em 17-07-00 17:17 GMT (#5) |
| Não sou da opinião de que a documentação seja tão escassa. Existem os HowTo's e as Tips, assim como o sistema de help integrado no 2.2. Para os curiosos, dêem uma saltada a Zope Architecture . |
| | | | | Existe bastante documentacao mas ainda muito dispersa... E' preciso integrar as muitas contribuicoes em menos documentos para nao ser tao chato andar a viajar por tudo aquilo `a procura de certos pedacinhos de informacao (mesmo quando ate' ja' os vimos antes). |
| |
|