| Reusability vs customization |
[eluser]jnorris441[/eluser]
My boss is one of those guys who wants to make all of the code in one site, and have all the sites run off of that one base site. That tends to make my life hell, because instead of copying the code and modifying it for each custom site, I have to code all the custom stuff together and it gets messy. Matchbox sounded good, but copying the modules from site to site is what I need to avoid. Is there something out there that would let me have customizations per site, otherwise use a default controller? I know I can accomplish this by creating a library for everything and creating a new CI site for every domain, but when I add features to the application it would be a lot of work to go in and add it for each site since they would be separate at that point. Since the Code Igniter events aren't contained in libraries but in the controllers, that means I would need to have a shared base controller for all these sites for me to add features to, and then for each site extend that controller for any custom stuff. Anyone run into this sort of thing?
[eluser]Phil Sturgeon[/eluser]
This sounds like a freaking nightmare. If I were in your position I would take the boss aside and explain to him what the problem is here. When that had no effect I'd threaten to leave and if that didnt work, id slap him in the beard. However there is a less dramatic solution. I understand you want one code-base and you are keeping it all in one place so you dont have to modify several code-bases with your modifications? This to me sounds like SVN time! It would be a little more tricky than normal SVN useage, but it would be a great way to keep one central repositry for all of the core code, then on the edges you can add your frilly customisation that only appeals to one single site. Do this via branches, then simply re-commit the central code (libraries, models, whatever) to the center. OR if the customisation is purely views, you can quite easily set up a sub-dir for each site in the view folder and use a config variable (or dynamic variable based on the $_SERVER['SERVER_NAME'] which detects which sub-dir to look for views in.
[eluser]esra[/eluser]
It sounds like you need something like this: Code: application/In the above, each site would have its own config/ and templates/ directories. If a specific config file did not exist for a particular site, a default configuration file would be loaded from extensions/config/. It's possible to do this, but it means hacking common.php and codeigniter.php and subclassing multiple system libraries (Loader.php, Router.php, Language.php, and Config.php at the least). This was discussed much earlier in CodeIgniter forum threads using an approach called mod_loader. The mod_loader approach allowed a selection of alternate directory paths to be defined. Those paths were scanned in cascading order (e.g., application/ first, then extensions/, and then system/). The basic cascading approach was used in the Kohana project to handle file loading, but I'm not sure if it is possible to create something like an extensions directory. Maybe someone who is familiar with Kohana can elaborate on whether this is possible or not. The more search paths you have, the more hit you experience on performance because the core needs to search more paths to find a specific file. An alternate approach might be to simulate namespaces using one of the solutions posted on the web which usually involves using the __autoload magic method. Hacking the class loader and configuration loading routine in CodeIgniter.php and Common.php would probably be necessary, as well as subclassing the other files mentioned above. However, namespace simulation might yield some other benefits because it makes it possible to discretely define search paths within indivudual modules, as well as system extensions. For an example of this, you might look at the namespace approach used by the Claw framework on tigris.org. ----- You might note that some of the Nuke-based CMS frameworks used part of the above approach to handle multisite installations. For example, PostNuke Phoenix and Xaraya allowed multiple sites to share a common set of modules and each site could use their own template sets.
[eluser]RazorX[/eluser]
Hmmmm, sound like you may want to consider creating a development site locally. Have a database keep track of all the sites using the shared code base along with ftp login info... If you stick to libraries and keep site uniqueness independent of these libraries... You could have your development site ftp in and push out your code to the other sites.
[eluser]jnorris441[/eluser]
Thanks these are all good ideas. I've already coded a store in coldfusion that acts like this, and yes it was a nightmare.
[eluser]Grahack[/eluser]
FatBear needs a (frightening) plugin architecture. Maybe we could join our efforts. Dunno. link to the original post
[eluser]zdknudsen[/eluser]
In the latest version of Matchbox you can specify exactly where to look for modules. So if all your sites are on the same server you could have a modules directory with the modules that should be shared between sites. You can also have seperate parts of modules in different module folders. So if you, on top of the beforementioned directory, also specify a custom directory for each site (e.g. a /modules folder in their application folder) you could have config files in the custom directory and the base functionality based on that in the base module directory. Please let me know if I'm not clear enough. 
[eluser]esra[/eluser]
[quote author="Zacharias Knudsen" date="1198703909"]You can also have seperate parts of modules in different module folders. So if you, on top of the beforementioned directory, also specify a custom directory for each site (e.g. a /modules folder in their application folder) you could have config files in the custom directory and the base functionality based on that in the base module directory.[/quote] Then, is the below feasible? If extensions/frontend/ and extensions/backend/ are modules for storing base controllers for the frontend and backend elements of an application, then individual application/site?/modules/ should be able to access any dependencies associated with those base controllers. So, if those based controllers, loaded factory classes which delegated to their respective libraries, helpers, etc., then the subordinate modules should be able to access those methods. Code: application/
[eluser]esra[/eluser]
[quote author="Grahack" date="1198700422"]FatBear needs a (frightening) plugin architecture. Maybe we could join our efforts. Dunno. link to the original post[/quote] If you took an approach somewhat similar to modular separation to reinvent the plugin library directory structure, it's probably possible to integrate the concept of a hook with different flavors of plugins (or plugin groups). For example, plugin groups could exist for auth, forms, validation, content, views, widgets, etc. and the plugins of those groups could reside in a directory with the group name. Then from a backend interface, it actually becomes possible to manage plugins in the same way that it is possible to manage modules. That is, by grouping plugins, it becomes possible to categorize them and enumerate the directories as a means of discovery to determine which plugins are currently installed. Much more feasible in PHP5 but possible in PHP4 using an adapter-like approach with support for plugin groups. Then the hook internals could be abstracted into the plugin interface. Example: Code: plugins/
|
| Welcome Guest, Not a member yet? Register Sign In |
