Dá uma olhada em http://blaze.haughin.com
On Tue, Feb 26, 2008 at 2:07 PM, Osdeni José Sadzinski <[EMAIL PROTECTED]> wrote: > Estamos desenvolvendo um CMS na empresa, utilizamos o CI na versao > 1.5.4, com uma adaptação de modularização encontrada no wiki do CI > (Modular Separation) porém a mesma não funcionou qndo fomos migrar > para 1.6 (em função de tempo, permanecemos na 1.5.4) > > Seguimos a estrutura que a Separation modular propões e estamos > gostando da mesma. > > Precisamos criar uma pequena adaptação para questão de autenticação apenas. > > application/modules/blog/controller > models > views > > > > > 2008/2/26 Marcus Cavalcanti <[EMAIL PROTECTED]>: > > Aproveitando, um doc excelente que passa uma boa visão de como funciona o > > Drupal (in english): > > > > Drupal often gets criticized by newcomers who believe that object-oriented > > programming (OOP) is always the best way to design software architecture, > > and since they do not see the word "class" in the Drupal code, it must be > > inferior to other solutions. In fact, it is true that Drupal does not use > > many of the OOP features of PHP, but it is a mistake to think that the use > > of classes is synonymous with object-oriented design. This article will > > cover several of the features of Drupal from an object-oriented > perspective, > > so programmers comfortable with that paradigm can begin to feel at home in > > the Drupal code base, and hopefully be able to choose the right tool for > the > > job. > > > > Motivations for Current Design > > As of version 4.6, Drupal does not use PHP's class construct. This > decision > > was made for several reasons. > > > > First, PHP's support for object-oriented constructs was much less mature > at > > the time of Drupal's design. Drupal was built on PHP 4, and most of the > > improvements in PHP 5 relate to its object-oriented features. > > > > Second, Drupal code is highly compartmentalized into modules, each of > which > > defines its own set of functions. The inclusion of files is handled inside > > functions as well; PHP's performance suffers if all code is included on > each > > page call, so Drupal attempts to load as little code as possible per > > request. This is a critical consideration, especially in the absence of a > > PHP accelerator; the act of compiling the code accounts for more than half > > of a Drupal page request. Functions are therefore defined inside other > > functions in Drupal, with respect to the runtime scope. This is perfectly > > legal. However, PHP does not allow the same kind of nesting with class > > declarations. This means that the inclusion of files defining classes must > > be "top-level," and not inside any function, which leads either to slower > > code (always including the files defining classes) or a large amount of > > logic in the main index.php file. > > > > Finally, using classes to implement Drupal constructs is difficult due to > > the use of some advanced object-oriented design patterns used by Drupal > > itself. While this may sound self-contradictory, it should become clear in > > the following discussion that the lack of certain OOP constructs such as > > Objective-C's "categories" in PHP would mean that implementing some Drupal > > mechanisms (such as the theme system) would be more complicated using > > classes than using functions. > > > > OOP Concepts in Drupal > > Despite the lack of explicitly-declared classes in Drupal, many > > object-oriented paradigms are still used in its design. There are many sets > > of "essential features" that are said to be necessary to classify a system > > as object-oriented; we will look at one of the more popular definitions and > > examine some ways in which Drupal exhibits those characteristics. > > > > Objects > > There are many constructs in Drupal that fit the description of an > > "object". Some of the more prominent Drupal components that could be > > considered objects are modules, themes, nodes, and users. > > > > Nodes are the basic content building blocks of a Drupal site, and bundle > > together the data that makes up a "page" or "story" on a typical site. The > > methods that operate on this object are defined in node.module, usually > > called by the node_invoke() function. User objects similarly package data > > together, bringing together information about each account on the site, > > profile information, and session tracking. In both cases, the data > structure > > is defined by a database table instead of a class. Drupal exploits the > > relational nature of its supported databases to allow other modules to > > extend the objects with additional data fields. > > > > Modules and themes are object-like as well, filling the "controller" role > > in many ways. Each module is a source file, but also bundles together > > related functions and follows a pattern of defining Drupal hooks. > > > > Abstraction > > Drupal's hook system is the basis for its interface abstraction. Hooks > > define the operations that can be performed on or by a module. If a module > > implements a hook, it enters into a contract to perform a particular task > > when the hook is invoked. The calling code need not know anything else > about > > the module or the way the hook is implemented in order to get useful work > > done by invoking the hook. > > > > Encapsulation > > Like most other object-oriented systems, Drupal does not have a way of > > strictly limiting access to an object's inner workings, but rather relies > on > > convention to accomplish this. Since Drupal code is based around functions, > > which share a single namespace, this namespace is subdivided by the use of > > prefixes. By following this simple convention, each module can declare its > > own functions and variables without the worry of conflict with others. > > > > Convention also delineates the public API of a class from its internal > > implementation. Internal functions are prefixed by an underscore to > indicate > > that they should not be called by outside modules. For example, > > _user_categories() is a private function which is subject to change without > > notice, while user_save() is part of the public interface to the user > object > > and can be called with the expectation that the user object will be saved > to > > the database (even though the method of doing this is private). > > > > Polymorphism > > Nodes are polymorphic in the classical sense. If a module needs to display > > a node, for example, it can call node_view() on that node to get an HTML > > representation. The actual rendering, though, will depend on which type of > > node is passed to the function; this is directly analogous to having the > > class of an object determine its behavior when a message is sent to it. > > Drupal itself handles the same introspection tasks required of an OOP > > language's runtime library. > > > > Furthermore, the rendering of the node in this example can be affected by > > the active theme. Themes are polymorphic in the same way; the theme is > > passed a "render this node" message, and responds to it in a different way > > depending on the implementation of the active theme, though the interface > is > > constant. > > > > Inheritance > > Modules and themes can define whatever functions they please. However, > they > > can both be thought to inherit their behavior from an abstract base class. > > In the case of themes, the behavior of this class is determined by the > > functions in theme.inc; if a theme does not override a function defined > > there, the default rendering of an interface component is used, but the > > theme can instead provide its own rendering. Modules similarly have the > > selection of all Drupal hooks to override at will, and may pick and choose > > which ones to implement. > > > > Design Patterns in Drupal > > Much of Drupal's internal structure is more complicated than simple > > inheritance and message passing, however. The more interesting features of > > the system result from using established software design patterns. Many of > > the patterns detailed in the seminal Gang of Four Design Patterns book can > > be observed in Drupal, for instance. > > > > Singleton > > If we are to think of modules and themes as objects, then they follow the > > singleton pattern. In general these objects do not encapsulate data; what > > separates one module from another is the set of functions it contains, so > it > > should be thought of as a class with a singleton instance. > > > > Decorator > > Drupal makes extensive use of the decorator pattern. The polymorphism of > > node objects was discussed earlier, but this is only a small piece of the > > power of the node system. More interesting is the use of hook_nodeapi(), > > which allows arbitrary modules to extend the behavior of all nodes. > > > > This feature allows for a wide variety of behaviors to be added to nodes > > without the need for subclassing. For instance, a basic story node has only > > a few pieces of associated data: title, author, body, teaser, and a handful > > of metadata. A common need is for files to be uploaded and attached to a > > node, so one could design a new node type that had the story node's > features > > plus the ability to attach files. Drupal's upload module satisfies this > need > > in a much more modular fashion by using nodeAPI to grant every node that > > requests it the ability to have attached files. > > > > This behavior could be imitated by the use of decorators, wrapping them > > around each node object. More simply, languages that support categories, > > like Objective-C, could augment the common base class of all node objects > to > > add the new behavior. Drupal's implementation is a simple ramification of > > the hook system and the presence of node_invoke_all(). > > > > Observer > > The above interaction is also similar to the use of observers in > > object-oriented systems. This Observer pattern is pervasive throughout > > Drupal. When a modification is made to a vocabulary in Drupal's taxonomy > > system, the taxonomy hook is called in all modules that implement it. By > > implementing the hook, they have registered as observers of the vocabulary > > object; any changes to it can then be acted on as is appropriate. > > > > Bridge > > The Drupal database abstraction layer is implemented in a fashion similar > > to the Bridge design pattern. Modules need to be written in a way that is > > independent of the database system being used, and the abstraction layer > > provides for this. New database layers can be written that conform to the > > API defined by the bridge, adding support for additional database systems > > without the need to modify module code. > > > > Chain of Responsibility > > Drupal's menu system follows the Chain of Responsibility pattern. On each > > page request, the menu system determines whether there is a module to > handle > > the request, whether the user has access to the resource requested, and > > which function will be called to do the work. To do this, a message is > > passed to the menu item corresponding to the path of the request. If the > > menu item cannot handle the request, it is passed up the chain. This > > continues until a module handles the request, a module denies access to the > > user, or the chain is exhausted. > > > > Command > > Many of Drupal's hooks use the Command pattern to reduce the number of > > functions that are necessary to implement, passing the operation as a > > parameter along with the arguments. In fact, the hook system itself uses > > this pattern, so that modules do not have to define every hook, but rather > > just the ones they care to implement. > > > > Why Not to Use Classes > > The above hopefully clarifies the ways in which Drupal embodies various > OOP > > concepts. Why, then, doesn't Drupal move in the direction of using classes > > to solve these problems in the future? Some of the reasons are historical, > > and were discussed earlier. Others, though, become clearer now that we have > > stepped through some of the design patterns used in Drupal. > > > > A good example is the extensibility of the theme system. A theme defines > > functions for each of the interface elements it wants to display in a > > special way. As noted earlier, this makes themes seem like a good candidate > > to inherit from an abstract base class that defines the default rendering > of > > the elements. > > > > What happens, though, when a module is added that adds a new interface > > element? The theme should be able to override the rendering of this element > > as well, but if a base class is defined, the new module has no way of > adding > > another method to that class. Complicated patterns could be set up to > > emulate this behavior, but Drupal's theme architecture quite elegantly > > handles the situation using its own function dispatch system. In this case > > and others like it, the classes that on the surface simplify the system end > > up serving to make it more cumbersome and difficult to extend. > > > > Room for Improvement > > While Drupal does reflect many object-oriented practices, there are some > > aspects of OOP that could be brought to bear on the project in more > powerful > > ways. > > > > Encapsulation, while adequate in theory, is not applied consistently > enough > > across the code base. Modules should more rigorously define which functions > > are public and which are private; the tendency right now is to publish most > > functions in the public namespace even if the interface is volatile. This > > problem is exacerbated by Drupal's policy of forgoing backward > compatibility > > in exchange for cleaner APIs whenever necessary. This policy has led to > some > > very good code, but would need to be excercised much less often if better > > encapsulation conventions were followed. > > > > Inheritance is also weak in the system. While, as noted above, all modules > > share a common set of behavior, it is difficult to extend this to new > > modules. One can create new modules easily that augment the behavior of > > existing ones, but there is not a way to override just some of a module's > > behavior. The impact of this can be marginalized by breaking large modules > > into smaller "a la carte" bundles of functionality, so that undesired > > aspects of a module may be more easily left out of the system. > > > > Other Paradigms > > Drupal is on the surface a procedural system, because it is built in a > > procedural language (PHP without classes). The paradigm behind a piece of > > software is not entirely dependent on its representation in code, however. > > Drupal is not afraid to borrow concepts from many disparate programming > > paradigms where it is convenient. A great deal of the power of Drupal comes > > from its underlying relational database, and relational programming > > techniques that mirror it. The fact that Drupal's work, much like that of > > any web application, consists of many reactions to discrete and rapid page > > requests should make the behavior of the system resonate with proponents of > > event-driven programming. To an aspect-oriented programmer, the invocation > > of hooks in arbitrary modules may look strikingly similar to a pointcut. > > And, as should be abundantly clear by now, Drupal is no stranger to > > object-oriented concepts either." > > > > 2008/2/26 Marcus Cavalcanti <[EMAIL PROTECTED]>: > > > > > > > Gustavo, > > > > > > Eu já li alguma coisa sobre modularização com CI no Wiki, mas lembro que > > era algo bem superficial, mas muito provavelmente esse assunto já deve ter > > sido debatido aos montes no fórum do CI, portanto dê uma procurada lá que > > você pode achar algo que lhe ajude. Existem também alguns projetos de CMS > > com CI, dê uma olhada em algum, de repente é mais interessante você > > contribuir para um já bem encaminhado do que começar um do 0... > > > > > > Se eu tivesse tempo hábil, um dos meus projetos pessoais, seria fazer um > > CMS genérico com a arquitetura do CI/Kohana, mas baseado na arquitetura do > > Drupal. Você conhece o Drupal? O Drupal é fascinante, sem dúvidas um dos > > melhores, senão o melhor projeto open-source do PHP, um case de sucesso que > > todo ano recebe vários prêmios bizarros e é usado em gigantes como Sony, > > MTV, NASA, etc ... confesso que no começo eu tinha um certo preconceito com > > o Drupal, por ele não ser OO, por ele não ser MVC, por ele não ser várias > > coisas, mas depois eu vi, é que o problema é que eu não conhecia o Drupal o > > suficiente e que minhas conclusões eram totalmente precipitadas, agora > > conhecendo melhor o Drupal eu percebo que ele é OO sem ser OO > > explicitamente, que ele é MVC sem sem ser MVC explicitamente e que ele usa > > Patterns o tempo todo sem ser explícito .. a curva de aprendizado é um > > poquinho grande, mas depois que você conhece e entende como as coisas > > funcionam, vc se apaixona .. "amor a segunda vista" digamos assim .. > > > > > > O Drupal é todo modularizado, onde cada módulo tem sua própria API > > definida pela API de Hooks do Drupal, com suporte a dependências, interação > > com outros módulos, interação com o core e tudo de forma independente, > > fantástico! Ainda tem suporte a categorias no formato de taxonomias, que é > > um formato avançado para organização de conteúdo usado por exemplo em > > gigantes do ecommerce como americanas, submarino, shoptime ... tem uma api > > de form que é muito fácil fazer forms, internacionalização fácil, rápida e > > eficaz através de arquivos de termos, enfim, uma enfinidade de coisas > > sólidas e bem definidas... o Drupal está na versão 6 (saiu recentemente) e > > aconselho que você olhe com calma, tempo e profundamente ... e o drupal tem > > módulo para praticamente tudo! testes unitários, automatizados, > integrações, > > fórums, blogs, serviços (web services), google, amazon .. sinistro! > > > > > > www.drupal.org > > > > > > Enjoy :) > > > > > > > > > > > > 2008/2/26 Gustavo Villa <[EMAIL PROTECTED]>: > > > > > > > > > > > > > > > > Quem aqui trabalha com CodeIgniter como CMS? > > > > Estou montando a arquitetura do sistema que usaremos num projeto de CMS > > > > OpenSource colaborativo, e tenho algumas questões que gostaria de > > > > discutir com quem já tem um pouco mais de experiência em CI. > > > > > > > > Basicamente são questões como: > > > > - Qual a melhor arquitetura para separar diversos módulos/componentes > em > > > > uma única pasta? ex.: application/modules/NomeDoModulo > > > > - Como separar as views dos módulos da view do sistema? > > > > /modules/NomeDoModulo/view? > > > > - Como implementar essas coisas sem que seja preciso alterar o CI. > Quero > > > > manter o CI sempre atualizado com novas versões disponibilizadas. > > > > > > > > Podem entrar em contato comigo via e-mail? > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Lista mailing list > > > > [email protected] > > > > http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br > > > > > > > > > > > > > > > > _______________________________________________ > > Lista mailing list > > [email protected] > > http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br > > > > > > > > -- > Abraços, > > Osdeni José Sadzinski > E-mail: [EMAIL PROTECTED] > Telefone: (48) 9916-3735 > > > > _______________________________________________ > Lista mailing list > [email protected] > http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br > -- Felipe Diesel http://felipediesel.net http://sigasw.com.br _______________________________________________ Lista mailing list [email protected] http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br
