I'm building several sites that need similar "modules." For example, the sites may have the exact same login system, forum, etc.
Is there a way I could build these modules once and just "drop" them in these various sites? Some of the challenges I see:
Keeping the code consistent in the various sites. Any changes made to a module should propagate to all of the sites using that module. I guess I need a way to upgrade?
Database: these functionality need to work as part of a bigger application. Maybe the module needs to define relationships with other tables in its respective site.
I'm sure there are more problems. I think I should be looking at this: https://bitbucket.org/wiredesignz/codeigniter-modular-extensions-hmvc/wiki/Home, but I don't have any experience with it.
So, I'm looking for solutions, suggestions, or more problems to this idea.
You can create and use third party packages by adding them to the third party folder (which is new for CI 2). There is not much about it in the docs, but i found this.
http://codeigniter.com/user_guide/libraries/loader.html
You can autoload the third party packages in the autoload file. Packages can have their own controllers, models, views etc.
Interestingly, Phil Sturgeon wrote a bit (http://philsturgeon.co.uk/blog/2010/04/codeigniter-packages-modules) about packages not being modules (in the strict sense of the term), but you could probably use third party packages for what you need.
I would write them as libraries and use Git submodules to manage each module. Phil Sturgeon actually just wrote a great post about doing this in CodeIgniter.
If you're not using version control, I can't see an easy way to sync across all of your applications. Yes, HMVC will let you break apart your application into actual modules, but it won't help in syncing those modules across your applications.
Here is my question about 'Database communication in modular software'
that you may find useful.
I'm little bit familiar with Drupal, and as a modular application, I think it can be taken as good example of how relationships between modules should be defined.
Here is one good post about art-of-separation-of-concerns
I would like to hear if you have run into some concrete challenges, solutions and references concerning modular design in CI.
Related
I'm having a question, maybe some other faced the same problem.
Imagine you've build your own CMS and someone asks you to build a website for them. They give you FTP access to their hostingserver and you want to use your CMS for it. Is there a way to protect the source code of your CMS?
There are obfuscation frameworks, but ultimately they can be hacked too. Obfuscation is more like a deterrent.
However, I wouldn't worry too much - there are many open-source CMSs out there so there would be little point getting at yours.
Depends on how CMS is written. If it's in PHP, then there's Zend and I heard (but didn't check) about some kind of PHP compilers.
If it's .NET or Java, then you ship compiled and obfuscated modules and don't include source code.
And also care that in 99,9% of cases your CMS has much more value for you than for your customer. I.e. with the myriad of open-source CMS on the market they have little sense to misuse yours.
I have used backbone boilerplate on the past
https://github.com/backbone-boilerplate/backbone-boilerplate
I want to use marionette on my next project and I have found this
https://github.com/BoilerplateMVC/Marionette-Require-Boilerplate
My question is if it's a good idea to go with the marionette boilerplate or start form scratch.
As an aside, I'd like to suggest you give Yeoman a shot for scaffolding your first Marionette app. Yeoman works via what are called "generators", and provide much more than the the above Boilerplate MVC can offer you (Chai and Sinon for testing, Bower for client-side package management, etc...). Plus, Addy Osmani, who runs backbone-boilerplates is one of the heads of the project. Check out generator-marionette here.
I haven't used BoilerPlate, but glancing through it, it certainly seems like a valid approach to writing Marionette apps. If you're just getting started it will certainly help you see how the various pieces are supposed to be used. One gripe I've got is the folder structure. I prefer to break my applications down into modules, and then add models, collections, views, etc under each module. But this will certainly get you up and running quick, and there's nothing stopping you from customizing it to suit your needs.
I agree with others here: it is a useless limitation to imitate a folder structure that follows the 'old mvc model for server-side code'. You will remain more flexible further down the road if you think of your application strictly as completely self-containing modules, i.e. they contain their own controller/router/views/collections/templates etc. You can have a separate folder structure for shared code that is not a module, although anything can be made a module :)
Regarding boilerplate code and generators: i think in the beginning you should actually NOT do it, because you won't understand what you're doing. But that's just my personal opinion.
I am trying to learn how to make a site with PyroCMS. I know it is similar to CodeIgniter, but I have not worked on either in the past. I was wondering if anyone could tell me the differences, as most sites talking about PyroCMS will inevitably mention CodeIgniter as an explanation for anything potentially confusing about PyroCMS, but as they are tutorials about Pyro, they will not explain how to program in CodeIgniter. What is frustrating about this is they will not go into many core differences between the two, either, so it's not as easy as looking up a CodeIgniter tutorial and changing a few things.
I was wondering if anyone could tell me the main differences to watch out for that would be relevant for these tutorials. For example, the folder structure seems to be similar, but CodeIgniter has an Applications folder, while Pyro probably has another folder that does the same thing, but the Pyro tutorials don't say what that similar folder is.
PyroCMS is a CMS build on CodeIgniter. PyroCMS is used by individuals, small & medium-sized businesses, and large organizations worldwide to easily create & build a variety of websites & web-enabled applications.
CodeIgniter is an Application Development Framework - a toolkit - for people who build web sites using PHP. Its goal is to enable you to develop projects much faster than you could if you were writing code from scratch, by providing a rich set of libraries for commonly needed tasks, as well as a simple interface and logical structure to access these libraries. CodeIgniter lets you creatively focus on your project by minimizing the amount of code needed for a given task.
UPDATE:
One good overview for PyroCMS you can read here
PyroCMS is built using modular MVC, which means (in short) that each part of the system is its own micro-instance of MVC. This allows the system to be more flexible and cleanly organized than other CMS platforms. PyroCMS describes itself as a simple, flexible, community driven content management system.” And because PyroCMS is powered by CodeIgniter (at least for a bit longer, while the team migrates over to a Laravel backend), it is easy to learn, understand, and own.
CodeIgniter (CI) is one of popular php framework,it is very help full whenever we need to build large websites using php.It has so many libraries,helpers and plugins.But, CodeIgniter is not everything. We will not find 'engine generator' that can build page self. Several frameworks have features like that. For example, they can create web page (that to do basic Create, Read, Update, and Delete operation) automatically. CodeIgniter doesn't do this.
But codeigniter is very useful to decrease our code maximally without loosing functionalists.
I've use symfony and now using codeigniter is there any folder structure
that can be used in scalable applications similar to symfony.
I want to make an application that will be divided in sub-apps and the sub-apps
will have their own modules.
Thanks.
What you are describing is called HMVC (Hierarchical Model View Controller). This means that an application is split up into modules (or as you described them, rather accurately, "sub-apps"). Sadly CodeIgniter does not support HMVC unmodified, however there is a drop-in extension for CodeIgniter which allows you to use a HMVC architecture. [Thanks Wesley]
Alternatively you can use a fork of CodeIgniter which is specifically designed for HMVC called Kohana Framework. The project was originally a fork but has now changed massively and is barely recognisable from the original CI project.
As far as modules go, the go-to solution for CI is the HMVC package:
https://bitbucket.org/wiredesignz/codeigniter-modular-extensions-hmvc/wiki/Home
This is a "drop-in" solution; very easy to install, has been around for quite a long time, and is actively maintained.
Since Codeigniter tries to stay lightweight, you'll find that a lot of important things you need, like Auth or ORMs, are not built in, and you have to use third party code.
A lot of solutions hosted here: http://getsparks.org/packages/browse/latest
And the wiki: http://codeigniter.com/wiki/
What are some of the best practices for OOD with Ruby? Mainly, how should files and code be organized?
I have a project that uses several classes and files and I am just wondering how it should all be organized, grouped and included.
It sounds like you're asking which pieces go in which files.
Is your project a Web application? In that case you would most likely use the system of organization imposed by your framework (Rails, Merb, Sinatra, etc.)
Other kinds of projects also have their own typical structure that you can just follow. E.g. gems are usually set up in a certain way.
If it's a console app, there's no strict rule. Usually people put no more than one class or module in a file. You could have one main file that requires all the others.
Standard OOD concepts apply to ruby. For specifics, maybe this guide will be helpful:
http://www.rubyist.net/~slagell/ruby/oothinking.html