PUBLIC MARKS from bacon with tag rumos

gigamaster escreveu: na pratica, para que serve o mecanismo "preload"? o programador de xoops cube legacy (legado), pensou em. adicionar a ideia emprestada de mojavi2 ( c e assembly ) as instruções do mecanismo "preload" são processadas quando. legacy é iniciado. com esta característica, você pode incluir suas bibliotecas, registrar seus objetos personalizados e, muitas outras mais intruções são assim possiveis. tudo isto em um simples script.php que você coloca na pasta "preload" da raiz ou do módulo que desejar modificar. desta maneira não precisa de 'hackear' seu xoops. por exemplo, legacy pode aplicar um tema diferente para cada módulo, com o seguinte 'preload' de wanikoo: [url=http://xoopscube.org/modules/xhnewbb/viewtopic.php?topic_id=319]themechanger preload version 1.0 by wanikoo[/url] 1) personalizar editando themechanger.class.php.<br /

boas ideias do que está se tentando fazer veio daqui, relembrando. [url=www.xoopscube.com.br/modules/news/]o que vem a ser este tal de roadmap[/url] estamos aprendendo sobre o assunto que muita gente fala mas talvez não saiba exatamente o que é. as boas ideias nunca morrem, apenas ficam algum tempo esquecidas. :-)

gigamaster, obrigado pelas respostas. muito esclarecedoras, com destaque para o preload. parece criar muitas possibilidades. grato.

na pratica, para que serve o mecanismo "preload"? o programador de xoops cube legacy (legado), pensou em. adicionar a ideia emprestada de mojavi2 ( c e assembly ) as instruções do mecanismo "preload" são processadas quando. legacy é iniciado. com esta característica, você pode incluir suas bibliotecas, registrar seus objetos personalizados e, muitas outras mais intruções são assim possiveis. tudo isto em um simples script.php que você coloca na pasta "preload" da raiz ou do módulo que desejar modificar. desta maneira não precisa de 'hackear' seu xoops. por exemplo, legacy pode aplicar um tema diferente para cada módulo, com o seguinte 'preload' de wanikoo: [url=http://xoopscube.org/modules/xhnewbb/viewtopic.php?topic_id=319]themechanger preload version 1.0 by wanikoo[/url] 1) personalizar editando themechanger.class.php. 2) copiar themechanger.class.php para: /html/modules/leg

gigamaster escreveu:o mesmo aconteceu este último ano com xoops cube. as principais questões colocadas aqui nesta discussão encontram solução nos fóruns "preload" de xoopscube.org (gestão de acessos por grupos e utilizadores, extenção do editor, e muito mais ainda). nuno (tu é português? apesar de viver na suiça tu fala português com "sotaque" brasileiro.) você pode explicar na prática e em português o que o preload faz de fato? outra coisa: quem está desenvolvendo módulos para o xoopscube? até agora parace que são os mesmos para o xoops com adaptação. e no futuro próximo, quando houver incompatibilidades - com certeza elas virão - de onde se tirarão os módulos? esse é o ponto alto do xoops atual, a grande oferta de módulos. te agradeço desde já pelas respostas, nuno. para todos os demais: e só para esclarecer para todos os que leram meu outro p

há uma ideia comum mas errada do que chamamos "open source". a definição mais popular tende a confundir o recem chegado. numa ideologia irrealista. dois aspectos são aquim resumidos : humano e tecnologico. mais lenha para alimentar esse fogo sagrado =) um projeto open source está dedicado à concretização do destino em comum da nossa visão para o projeto e da comunidade global. há quem pense que para julgar pessoas e informações, são necessárias competencias e qualidades intelectuais especiais. e com o tempo temos provas de que a inteligência da "classe dirigente" de xoops.org, não possui mais essas qualidades, se conformando com um viés previsível e em causa própria. como utilizadores queremos que as coisa mudem, mas não só na aparencia. afinal, que adianta ter carrossaria de ferrari com motor de citroen 2 cavalos, se na hora da verdade, o calhambeque avaria em plena avenida. os "dirigentes", au

ps: não devemos e não queremos caminhar para um fork, estamos seguindo a linha do xoopsmexico, mantendo o máximo de compatibilidade e assim o pessoal do núcleo poderá utilizar aquilo que achar útil. de tudo o que foi escrito aqui no tópico, essa foi a melhor coisa que eu li :-d eu não diagramei na minha resposta acima, mas falamos da mesma coisa e também concordo 100%. realmente, tem uma parte que você comenta sobre isso. aliás, aquele jeito que você comentou é o mesmo que eu tinha colocado em um outro tópico antigo, fazendo uma pasta de plugins no root do xoops. até continuo com essa ideia, mas agora acho que seria mais fácil de fazer se cada módulo tivesse seu dir de plugin e usasse um nome pré-determinado pelo xoops para os php. não entendo muito de programação php, mas talvez seja mais fácil fazer um include/chamada para um arquivo dent

fbs777 escreveu: ok, postei antes minha defesa ao xoops, agora as críticas :-) ótimo, defesa campeã e concordo plenamente. tem algumas coisinhas a considerar, mas detalhes. um negócio que funciona muito mal é o esquema de bbcodes e "smarty tags". se quiser criar um novo bbcode ou um novo smarty tag tem que hackear dois arquivos do core. exemplo do módulo rw-banner, que tem bbcodes e smarty tags exclusivos. pra funcionar os dois, tem que incluir um pedaço de código no cabeçalho.php e outro no class/module.textsanitizer.php. esse dois hacks servem para chamar dois arquivos php incluidos no módulo: rw_banner/include/maketags.php e rw_banner/include/bbcode.php. o que deveria ter oficialmente no xoops, na minha opinião, é alguma coisa do tipo: - no cabeçalho, uma chamada/include (não sei os nomes das funções php) para xoo

ok, postei antes minha defesa ao xoops, agora as críticas :-) um negócio que funciona muito mal é o esquema de bbcodes e "smarty tags". se quiser criar um novo bbcode ou um novo smarty tag tem que hackear dois arquivos do core. exemplo do módulo rw-banner, que tem bbcodes e smarty tags exclusivos. pra funcionar os dois, tem que incluir um pedaço de código no cabeçalho.php e outro no class/module.textsanitizer.php. esse dois hacks servem para chamar dois arquivos php incluidos no módulo: rw_banner/include/maketags.php e rw_banner/include/bbcode.php. o que deveria ter oficialmente no xoops, na minha opinião, é alguma coisa do tipo: - no cabeçalho, uma chamada/include (não sei os nomes das funções php) para xoops_root_path/modules/todos_os_módulos/plugins/smartytags.php. - no class/module.textsanitizer.php, uma outra chamada/include para xoops_root_path/modules/todos_os_módulos/plugins/bbcodes.php. <br

eu tinha feito um tempo atrás, um post em um tópico aqui no xoops que estava mais para para a livro do que post sobre muita coisa que está sendo discutida aqui e outras ideias do que eu gostaria de ver no xoops, mas depois de alguma pane no portal foi feito uma restauração de backup do banco de dados do xoops e nisso meu post quilométrico e o próprio tópico foi para o espaço :-d tentei buscar no cache do google mas não achei. como eu levaria 1 semana para lembrar de tudo que eu coloquei no outro post, vou dar minha opinião só sobre o framework, por enquanto: pelo jeito, acho que só eu sou a favor dos frameworks :-d afinal, se dá para fazer uma coisa sem ter que mudar/atualizar/converter/adaptar/substituir/hackear/. o kernel, porque não fazê-lo? é muito melhor conseguir fazer alguma coisa sem ter que mexer no kernel do que não poder fazer a coisa a menos que mexa no kernel. o que talvez alguns não perceberam é que os fr

resposta enviada no http://www.xoopscube.com.br caramba elói, excelente. :-) mas antes . senta que lá vem a história normalmente estas istórias são as coisas mais legais de acompanhar , rs :-) e reviver. só gostaria de esclarecer algumas coisas. sou programador em php já a muuuiiitttooo tempo . colaborei muito tempo no phpbrasil.com (que foi ou não tenho certeza se ainda é uma referencia em php no brasil e fora - diga-se de passagem estou lá até hoje entre o 50 top colaboradores). meu último emprego (de carteira) foi em uma empresa de medicamentos onde fui contratado para portar todo o sistema de controle da empresa para sistemas web. topei a empreitada (o sistema era gigante e feito em foxpro para quem conhece sabe que foi descontinuado pela micro$oft) bom daí nasceu não um sistema mas um kernel (ou core se preferirem) semelhante ao xoops e ao joomla ju

outra prova do que estamos falando que faz o nosso xoops ser melhor a cada dia com a inclusão de novos utilizadores e porque não dizer, mais ajuda para ideias, soluções, desenvolvimento. [url=http://www.xoopscube.com.br/modules/newbb/viewtopic.php?topic_id=7729&forum=20&post_id=44044#forumpost44044]by léu - curso extensivo - cms/xoops[/url]

opa!epa. esse foi o maior post que já li em todos os tempos :) e muito esclarecedor tambem, a meu ver. conheci varias coisas novas e lembrei as vicissitudes de um desenvolvimento opensource. mas. vou continuar achando que falta algo na coordenação do processo - isto é, na turma do core. no minimo um roadmap mais estruturado. vejam, falo como utilizador - um utilizador chato, é verdade - mas no maximo um heavy user. que começou baixando um pacote chamado melponeme e viu - como um passe de magica - que fazer um portal era possivel, sim. com xoops. hoje eu não encontraria o que vi. ia ter que catar um xammpp da vida, e sair a caça de um xoops. e me deparar [quase, quase.] com xoops do a, xoops do b e etc. nao estou querendo ser radical ou ranheta [posso até ser, mas não quero], mas está meio bagunça em demasia, neh nao? sou contra fechar tanto que se vire monolitico. acho que uma das belezas do opensource é exatamente a

interessante tópico e espero que este debate continue em bom e alto nível. antes de inicar e responder, vamos tentar pensar positivamente e acreditar que nós também fazemos parte disto e fazemos a diferença quando participamos. open source é assim, ficar sentado esperando cair do céu, não vai cair sempre com facilidade, mas as vezes, damos sorte e o que queremos se encontra fácil. nem vou entrar no mérito de quem faz mais ou menos e sim se podemos ajudar a este processo melhorar e com isto atingir nossos objetivos no brasil que seria ter um xoops ou não tenho certeza o nome que porventura iremos ter um dia aqui, mas algo útil para todos nós utilizadores, desenvolvedores e hospedeiros. quando damos ideias de melhorias para módulos, temas, core, etc. estamos participando ativamente do processo, mesmo que isto não seja aceito hoje, fizemos a nossa parte. por isto, não tenha medo de participar do processo aqui. envie as novidades que

olá pessoal, acredito que o excesso de frameworks é um reflexo natural de como vai a coisa. demonstra que o núcleo está ficando para trás e não está se atualizando, e os desenvolvedores exparsos não tem tempo para esperar, mesmo os que colaboram com o core, os devs acabam tendo necessidades profissionais de recursos e partem para solução a parte, prórpia, portada. vejo que o pior disso tudo é que o conjunto fica fraco, aos poucos incompatível e muito propício a divisões e subdivisões. diante disso, penso, qual seria a solução? quem sabe, alguma ideia de solução não esteja ao alcance do xoops, mesmo que seja uma campanha. é isso

pois é amigo beduino, isso é uma coisa que incomoda: me desculpem o termo chulo, mas a impressão que dá é que os desenvolvedores do xoops - do núcleo do xoops - são um bando de frouxos. poxa, os caras parecem que comem mosca! não informam sobre o rumo que o xoops está tomando de fato! os caras não dizem o que fazer, não mudam o core, não atualizam. cadê o wysiwyg? cadê o seo para as urls? caramba! esses montes de frameworks (tem ainda o xoopsmexico!) é a maior prova de incompetência em conduzir um projeto opensource da envergadura do xoops. se precisa de framework, então que tenha apenas um e que seja mantido pelo xoops team e distribuido junto com o core. cada vez mais estou achando que os japoneses fizeram bem em cair fora do xoops e fundarem o xoopscube! parece que os japas estão levando a sério a herança do xoops e inovando. ou seja, estão no caminho certo! é amargo dizer iss

realmente eu fico um tanto impressionado com a quantidade de soluções que vem sendo encontradas pelos principais desenvoldores [ou correntes de desenvolvedores] para o xoops. a turma da smartfactory lança módulos somente para php5. ok. já me explicaram o porquê. tratamos de atualizar os hosts. mas, eu estava iniciando a tradução para o português do smartblocks e não prestei atenção . e pau na instalação teste. ai fui ler com calma e descubro que parte dos módulos novos da smartfactory precisa de . uma pasta frameworks, batizada de smartobjects. pensei que eu fosse viver sem pastas frameworks [outra turma de dev que pendura os módulos em cada vez mais colossais pastas frameworks] à lá xoopsforge/phppp. vamos então aos módulos do gijoe . e descubro outro gatilho [posso - e provavelmente estou] falando uma grossissima bobagem - o tal do xoops_trust_path, que cria uma outra pasta no root com trocentas outras variáveis. [hoje descobri um mod ch