Simple question, but can't figure it out.
Why when calling $this->partial() in a view in Zend Framework 2 inside a view in the Admin module, it looks for the file in Application module??
Here's a stack:
include( '/.../module/Admin/view/admin/pages/index.phtml' )
include( '/.../module/Application/view/partials/pagination.phtml' )
I don't really understand what this include stuff is that you do...
You have two ways to assign templates for partials. I always suggest going the fully qualified way, as this is the fastest way possible, too.
$this->partial('NAMESPACE / CONTROLLERNAME / ACTIONNAME', array(/** key value pairs*/));
When you only use ACTIONNAME instead of the fully qualified template name, then the renderer will look inside your current module and sarch for actionname.phtml in said module.
You have to use the fully qualified template name in order to load partials from another module.
As mentioned previously though, ALWAYS go fully qualified. It's a lot faster ;)
Related
Using CodeIgniter, from a controller (application/controllers/home.php), observe the line:
$this->load->library(array('account/authentication'))
AFAIK, this will:
Load 'authentication.php' from
application/modules/account/libraries/authentication.php
Load 'authentication.php' from application/libraries/account/authentication.php
So, what if both exist? Experimenting, it seemed like CI looks for the first one, and if no such exists, it loads the second one. Isn't that kind of weird behavior?? The two files might have nothing to do with each other.
Isn't there a way of unambiguously declaring if you are referring to a local file or to a module file?
AFAIK, there is no default directory application/modules and I can't find any reference for it in CI's docs and source.
I would say that CI's behavior is according to no.2
And indeed taking a closer look at CI's loader (system/core/Loader.php) reveals the following:
We start at function 'library'
Which calls function '_ci_load_class'
'_ci_load_class' disassembles the library name you passed into two parts: subdir and class name.
First it looks for the class in libraries/subdir/class. If it finds it - good, it loads it.
If the class was not found there, it looks for it in some other predefined pathes ($this->_ci_library_paths).
If the library is still not found, it makes a last attempt and looks for it in libraries/class/class.
The only thing I can think of, is that you have defined a custom library path which points to a modules directory. But even then, CI should look for the library in modules/libraries/account/authentication.php.
Edit:
I just noticed you tagged your question with hmvc, which does use a modules directory.
Unfortunately, I have no experience with it.
I would (obviously) assume this what causes the behavior you described.
I'm starting to write a application in php with one of my friends and was wondering, if you have any advice on how to implement module support into our application.
Or is there a way how to automatically load modules written in php by a php application? Or should i just rely on __autoload function?
And we don't need plugins that are installable via a web interface, we just need some clever way to associate web pages of our project to some classes (they will render the page) so index.php can call the right class and retrieve it's generated sub-page.
And we are not using any kind of framework, for now at least.
Re your comment: Autoloading in conjunction with strict file naming would be totally enough in this case IMO.
You could define a specific namespace (not in the new PHP 5.3 namespace way, just in the sense of a common prefix to names), e.g. Module_* for module class names.
You could then organize your modules in directories with class files that contain exactly one class definition, for example:
/modules/Mail/index.php // defines class Module_Mail
/modules/Database/index.php // defines class Module_Database
/modules/Image/index.php // defines class Module_Image
Your autoloader function would then, whenever a Module_* class is requested:
$Database = new Module_Database("localhost", .....);
include the correct file from the right directory.
That's the way e.g. the Zend Framework does it, and does so pretty well.
Consider choosing a more specific namespace than Module_ to assure interoperability with other scripts and applications if that is an option in the future.
Slightly related: In a PHP project, how do you organize and access your helper objects?
It sounds like you are looking for a way to organise the different tasks that each page needs to carry out. In this case, take a look at the MVC pattern. It provides a simple way to seperate your data access (models) and how you render/present information (views).
You can map pages to functions with ease. If you store the information in an array of mapped values, and then use a function to compare the requested URL with each of the URLs in the array. Such an array could look like this:
$urls = array(
'/' => 'index',
'/aboutus/' => 'aboutUs',
);
There are several articles that discuss how to implement it in PHP in a couple of hours. This article is a very simple guide. I am not a fan of their use of the registry pattern but reading through should provide you with enough information as to how you can implement it yourself.
Regarding autoloading, you can also use spl_autoload_register, to define several (more than one) autoload functions, so each module can set up it's own implementation of autoloading.
All you need here is an MVC architecture, with one Controller class associated with each "module".
If you are not against using a framework, go for Zend MVC
It allows you to have the following principle :
An URL like this : http://yoursite.com/my-module/edit
Will more or less automatically call the editAction method in the MyModuleController class.
I have a kohana v3 app. 2 subdomains pointing to this app. what I have to setup that kohana uses a different template if the app called with subdomain2.example.com?
at the moment all calls (from subdomain1 and subdomain2) use the standard template: 'templates/default'
thank you!
daniel
First, get the subdomain name from $_SERVER['SERVER_NAME']:
list($subdomain) = explode('.', $_SERVER['SERVER_NAME'], 2);
Then choose what template to use based on the subdomain:
// Replace this with a switch() statement if you want to choose another way
$this->template = 'templates/'.$subdomain;
The above code should be placed in the Controller::before() method before you call parent::before(). This assumes that you are using the Controller_Template or an extension of it.
may anybody can help me: kohana v3: using different templates for different subdomains
danzzz, there are a few ways... (i dont have time to go into detail.. so i'll give a quick go here..) .. A) use URL rewriting to map bla.site.com to site.com/bla (and www.bla.com+bla.com to bla.com/www) ... use that first param as the trigger... then load a different module at the top of the stack so it can override anything from a lower module - this assumes anything that is overridable is kept in a module, otherwise, you can use it as a trigger any
where in the code...
and B) is really the same thing, but using that param as the view name or similar...
whenever i have something like that, i tend to leave my application folder empty, and have an application module near the top of the module stack.. that way, i can load a "skin" module higher up and have the cascading FS do all the hard work...
keep in mind that "skin" modules etc will need a strict set of rules and interfaces, if you make a change to the app, you need to know all the skins still work...
What class(FrontController , Bootstrap, Dispacher....) sets up the default structure path in ZF?
There is no single instance that has all the paths. Each component has it's own defaults, e.g. the FrontController knows that the controller directory should be named controllers, but it doesn't know how to make a full path from it (Dispatcher does it) or where to find the Action Helpers. That's defined in ActionHelper Broker. Consequently, Zend_View_Abstract holds the paths for View filters, helpers and scripts, etc.
Like #Pascal mentioned in his comment, you should not modify ZF at it's core. You will lose the changes once you update to a newer version anyway. Configure the paths through the API in your bootstrap or through the application.ini instead.
Actually it's the dispatcher's job to find the requested action controller.
So you'll have to extend either Zend_Controller_Dispatcher_Abstract or Zend_Controller_Dispatcher_Standard or even create a completely new one based on Zend_Controller_Dispatcher_Interface to fit your requirements.
But be aware that you'll have to change the way Zend_Controller_Action_Helper_ViewRenderer tries to find the required view files, too.
straight to the point :
I am using Kohana, and I am looking at another script written in plain PHP. In the script, I have a class ShoppingCart. If I am to convert the script to Kohana, where am I to put the class, its methods and its properties?
Is it in my existing default controller? Or should I put it in a separate controller? Or as noobie as it may sound, will I put it in the model?
That depends on the specifics of the class I suppose. To be honest I don't know anything about Kohana, but there's probably a place for "vendor files" somewhere. Maybe it's best to place it there and write wrapper functions for it in your controller. If the class already integrates well with Kohana you may instead choose to use it as a controller or model directly. Or you might want to take the time to rewrite it to make it work as a controller...
Only you can evaluate the best place for it, there's no hard and fast rule here.
Kohana has a folder for 3rd party libraries. The main one is under system/vendor, you can put it in you application/ as well.
Many PHP class loaders require details like your filename should be the same as the class name (at least that's what I read in the Kohana documentation) if you want the classes to be automatically loaded.
If you need to use 3rd party code in your app it's recommended that you create a folder in your app / module folder called 'vendor' and place all of that code there.
You can then include the files by calling:
include kohana::find_file('vendor', 'filename');
If needs be you can also create a wrapper for the external library, a good example of this is the email helper which uses the 3rd party Swift email library.
If you're porting your own class to kohana then you need to work out what the class will be doing and categorise it accordingly.
If the class will be fetching items from some kind of database then you should make it a model. Libraries are usually sets of code that you want reuse across controllers / models, such as authentication, calendar generation etc. Controllers are used for passing data from models to your views / libraries.
See the docs for more info
As per kohana convention, you should place custom classes in application/libraries folder. However for this, you need to know how to get the class to work after putting it there. If you can't figure that out, you can do anything like putting it in your controller or making another controller of it, etc.