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
