I have two apps running at same server and one of them is CI. I need the one that is not CI to use models, libraries, helpers etc. So I needed something like get_instance(), but I'm not in a controller's context, I'm outside CodeIgniter.
How can I get a generic instance of a controller, or instantiate models or import helpers from a different application?
Example:
A and CI are apps and both runs on the same server
ROOT
A
script.php
CI (it's a CodeIgniter project, with controllers, models etc)
...
random_model.php
...
random_helper.php
How can I make script.php on A use random_model.php on CI?
Nice question, but I'm afraid that you can't do that, and even if we assume you can do it, this will do more damage than good, for example you call a custom library that is using the session library, then your application "A" will implicitly use that session library and can have unpredictable consequences,mostly if "A" is using native php session.
This is not only true for session but other configuration settings too (database, base_url,charset,...and other settings) and it will auto load other libraries, helpers, packages ...etc if any from your autoload.php
a better way is to create a controller under the "codeigniter" project and call it as you usually do with other controllers.
or even better, create a second codeigniter project, since it has a very small footprint, for your script "A" and avoid all conflict between the two projects and get more organized
I hope that makes sense.
Related
When should we use multi-module structure (instead simple structure) in php Phalcon?
I have found some multi-module skeleton, such as:
https://github.com/ovr/phalcon-module-skeleton,
https://github.com/phalcon/mvc/tree/master/multiple.
But I don't know should i use this multi-module structure in a project instead use multi projects.
Something i can think about it is: more complex configuration, complex folder structure, my web url be longer (/[module]/[controller]/[action]) and , importantly, performance will be low (for more loading things than).
However, I think that there are something interesting with it (so many ITer had used it). Is there Someone can give me advantages, disadvantages and criterias for selection.
P/s: the same problem with Zend2 Module!
If you are building a single purpose application as an API that does not use Views, you should rather use single module structure. If it will be a realy simple API of for example storing/logging, micro app will do aswell.
Multi module application structure is useful if you are willing to build more complex solutions. For example an public application with public content, but with admin panel. This one would be handy to write in multi-module to separate administrative controllers/views from those public ones.
My habit is to use multi-module structure, because mostly I have to build applications that are CRM's with their API and an public accessible content part (eg. docs). For such purpose it's just handy to create such modules as:
frontend - for controllers accessible by everyone
backend - for controllers accessible after authentication and authorisation like administrative things
API - for API purposes ;)
common - a part I rather am willing not to implement, but in one project I'm forced to put here some abstract controllers that will be extended in other modules.
This way you can keep separate services configuration for each module, what saves you from cutting off things that you are using at purpose of module A, but not on module B. Like authentication part - important for backend, but useless for frontend part. Or Database configuration - slaves for frontend, master for backend, etc. So this may be also a performance-wise solution for big projects.
Update
Sometimes "multi-project" is an option including "multi-module" project ;) It strongly depends on what you are trying to achieve. Eg. if you take API apart, it may be easier to scale it over multiple instances, but at first it costs you an efford to configure separate project.
If system is supposed to be single-server instance or every istance should be absolutely independed on other instances, single multi-module project will be enough - lets say a standar CMS, blog platform, even simple browser game or homepage of mobile app including API for it. But if you are building a whole universum of apps like an internal API to privide content, CRM to manage it and a couple of web pages to serve it, keeping these as separate projects will be easier to manage later.
Well for example I in my application im splitting every functionnality - for example i have model Link - it's splitted to seperate module to have nice application structure where each funtionality is seperated module. It's like less classes to load in loader. Beacause you only need models and routes from each module to load for whole app, and you load other things like librarys/controllers/helpers/services in module.
Before using Symfony2, I used to have a common lib with a lot of simple but useful functions (for instance, a function which takes "Azè_rtï" in argument and returns "aze-rti").
So, well, I created a Bundle: CommonLibsBundle.
But.. I have only one or two php files. It does not make sense to me to use a controller / view / model in this kind of situation.
What should I do? May I erase all folders in my new bundle (Controller, DependencyInjection, Resources, Tests... + CommonLibsBundle.php) and just put my lib.php in it?
Many thanks,
Bliss
Unless you need to tap into the Symfony framework itself - for configuration or to define services, it doesn't need to be a bundle - it's just a library. Give it a reasonable namespace, and call as required as you would any other component or library.
Even if you wanted to add Symfony-specific services that you could call, there is something to be said to still have an external simple library - usable anywhere, which then is wrapped by a very thin bundle which would only add the Symfony-specific (or Laravel, or ZF, or whatever) services and configuration as required.
As the subject says, really.
Assume I have two apps, namespaced as App_A and App_B. App_A has App_B imported as a git submodule and then autoloaded via its composer.json.
When I call App_B\SomeModel->someMethod() from an App_A controller, will the model query the database configured in App_B's config files, or will it inherit the config values from App_A?
Short answer: it won't inherit App_B's config files.
Expanded answer: App_A is loaded with it's config files. You call App_B\SomeModel::someMethod() from App_A, App_A's configuration will be used. To have two independent applications with 'knowledge' of each others state you would need to define a communication method between the two such as Message Queues(MQ), HTTP, Sockets, Streams etc etc. You would also never import App_B as a submodule of App_A and vice versa unless you're ok with App_*'s classes being used in the context of the loaded application stack.
Another option is to look at the HMVC or Heirarchical MVC pattern. This could possibly give you a solution to this problem without keeping the applications separate. There was a bundle in Laravel 3 enabling HMVC but I haven't looked into it since then as it (imo) is an anti-pattern. I don't know if one exists for Laravel 4 or 5.
I need create a lot functions, used by 6+ Controllers. So... shared functions:
This functions needs:
Model Access
Database Access
Lib Access
Vendor Access
Plugin Access
View Redirect
Return parameters (callback)
What the best way?
Lib
Component
Behavior
Vendor
My website configuration:
CakePHP 2.3
MySQL 5.5
PHP 5.3.9
Apache 2.2
Sorry for my english.
Thanks.
Helpers are for (multiple) views
Behaviors are for (multiple) models
Tasks are for (multiple) shells
Components are for (multiple) controllers
So - if you share those functions across controllers, the logical answer would be to use components.
All the rest of your "options" provided fail for at least one reason.
But keep in mind that you still have to keep the model stuff close to the model layer and should only use it via model methods in the controller/components.
Don't make those components a powerful model or something. They are meant to share "logic" between controllers.
Simply you can write those function in Appcontroller file so you can access them globally.
I'm looking to try and use codeigniter with different domains all using the same code structure, within the code igniter framework.
The libraries, models and database should be the same across all the domains, the only difference should be the controllers and views that are used.
Preferably I would like to have a setup similar to this:
controllers/domain1.com/index.php
controllers/domain2.com/index.php
controllers/domain3.com/index.php
Does anyone have any experience modifying code igniter to work in this way?
Take a look at the loader class page in the manual and scroll down to the Application "Packages" part. Combine this with the part of running Multiple Applications you should be able to be running multiple sites, with the same models and configs and avoid duplicating your code.
There is a manual page that describes how do you achieve this. Consult with Running Multiple Applications with one CodeIgniter Installation.
The only difference is that it looks like you'll have to duplicate your models/configs as well.
In my experience I need to build a system on a different subdomain, since the default domain has an existing base codeigniter and it was not design to handle multiple domains or subdomains.
And part of my goals are:
use the existing shared core objects in dir config, core, helpers and libraries.
and the existing public dir files, but separate images/mysubdomain/* and other dirs/subdomain/*
And so this is what I have done.
I've modified router.php in the same config dir and made a condition that routed a default controller in a separate dir inside mysubdomain/default if subdomain===true
ie. /controllers/mysubdomain/default.php
With a separate base controller that extends the main Controller inside /controllers/mysubdomain/.
Then mysubdomain are defined (ie models/mysubdomain/* and views/mysubdomain/* in all my controllers in mysubdomain.
and this works perfectly as I need it.