I want to rewrite JSON View in the RequestHandler. So there's a file project_root/lib/JsonView.php. What I want to do is to
Import the JsonView.php file in another file in project_root/app/View/CustomJsonView.php. (I think I could use App:import, would it be right ?)
Choose this file as the custom in requestHandler like this:
public $components = array('RequestHandler' => array( 'viewClassMap' => array('json' => '/right/way/to/this/file/CustomJsonView', )));
But how do I write the right way for this file ?
I also saw this one https://book.cakephp.org/2.0/en/core-libraries/components/request-handling.html#RequestHandlerComponent::viewClassMap
but there is no explanation about the right paths to the file. My CakePHP version is 2.4.4 .
You are not supposed to pass full paths, but "short classnames", just like shown in the linked example, where ApiKit.MyJson refers to the MyJsonView view class in the ApiKit plugin, which could be located in app/Plugin/ApiKit/View/MyJsonView.php.
If you follow the conventions and place your CustomJsonView class in app/View/CustomJsonView.php as shown in the docs, you then just pass CustomJson as the short classname in the request handlers viewClassMap option.
Whether you use App::import() or just require to include the /lib/JsonView.php file, is up to you, both works. In any way you must make sure that whatever you are importing there doesn't clash with existing class names (JsonView is a kinda reserved name as it already exists in the core), and that it is either following the CakePHP view class naming conventions, or you must extend it.
See also
Cookbook > Views > Creating your own view classes
Cookbook > Core Libraries > General Purpose > App Class> Loading Vendor Files
Related
I am working on a newly created Phalcon project, and I don't really know how to actually use multiples views.
What is the entry point? I don't really know when each method in the controller is called, under which conditions, etc.
Where is the control flow defined? is it based in the name of the view? or is there a place where you can register them?
Phalcon is a bit different than other well-known PHP frameworks, in that not much is pre-configured or pre-built by default. It's quite loosely-coupled. So you have to decide where and how your control flow will work. This means that you will need to dig deeper in the documentation and also that there could be different way to achieve the same thing.
I'm going to walk you through a simple example and provide references, so you can understand it more.
1) You would start by defining a bootstrap file (or files) that will define the routes, or entry points, and will setup and create the application. This bootstrap file could be called by an index.php file that is the default file served by the web server. Here is an example of how such bootstrap file will define the routes or entry points (note: these are just fragments and do not represent all the things that a bootstrap file should do):
use Phalcon\Di\FactoryDefault;
// initializes the dependency injector of Phalcon framework
$injector = new FactoryDefault();
// defines the routes
$injector->setShared('router', function () {
return require_once('some/path/routes.php');
});
Then it the routes.php file:
use Phalcon\Mvc\Router;
use Phalcon\Mvc\Router\Group as RouterGroup;
// instantiates the router
$router = new Router(false);
// defines routes for the 'users' controller
$user_routes = new RouterGroup(['controller' => 'users']);
$user_routes->setPrefix('/users');
$user_routes->addGet('/show/{id:[0-9]{1,9}}', ['action' => 'show']);
$router->mount($user_routes);
return $router;
Im defining routes in an alternate way, by defining routes groups. I find it to be more easy to organize routes by resource or controller.
2) When you enter the url example.com/users/show/123, the routes above will match this to the controller users and action show. This is specified by the chunks of code ['controller' => 'users'], setPrefix('/users') and '/show/{id:[0-9]{1,9}}', ['action' => 'show']
3) So now you create the controller. You create a file in, let's say, controllers/UsersController.php. And then you create its action; note the name that you used in the route (show) and the suffix of Action:
public function showAction(int $id) {
// ... do all you need to do...
// fetch data
$user = UserModel::findFirst(blah blah);
// pass data to view
$this->view->setVar('user', $user);
// Phalcon automatically calls the view; from the manual:
/*
Phalcon automatically passes the execution to the view component as soon as a particular
controller has completed its cycle. The view component will look in the views folder for
a folder named as the same name of the last controller executed and then for a file named
as the last action executed.
*/
// but in case you would need to specify a different one
$this->view->render('users', 'another_view');
}
There is much more stuff related to views; consult the manual.
Note that you will need to register such controller in the bootstrap file like (Im also including examples on how to register other things):
use Phalcon\Loader;
// registers namespaces and other classes
$loader = new Loader();
$loader->registerNamespaces([
'MyNameSpace\Controllers' => 'path/controllers/',
'MyNameSpace\Models' => 'path/models/',
'MyNameSpace\Views' => 'path/views/'
]);
$loader->register();
4) You will also need to register a few things for the views. In the bootstrap file
use Phalcon\Mvc\View;
$injector->setShared('view', function () {
$view = new View();
$view->setViewsDir('path/views/');
return $view;
});
And this, together with other things you will need to do, particularly in the bootstrap process, will get you started in sending requests to the controller and action/view defined in the routes.
Those were basic examples. There is much more that you will need to learn, because I only gave you a few pieces to get you started. So here are some links that can explain more. Remember, there are several different ways to achieve the same thing in Phalcon.
Bootstrapping:
https://docs.phalconphp.com/en/3.2/di
https://docs.phalconphp.com/en/3.2/loader
https://docs.phalconphp.com/en/3.2/dispatcher
Routing: https://docs.phalconphp.com/en/3.2/routing
Controllers: https://docs.phalconphp.com/en/3.2/controllers
More on Views (from registering to passing data to them, to templating and more): https://docs.phalconphp.com/en/3.2/views
And a simple tutorial to teach you some basic things: https://docs.phalconphp.com/en/3.2/tutorial-rest
The application begins with the routing stage. From there you grab the controller and action from the router, and feed it to the dispatcher. You set the view then call the execute the dispatcher so it access your controller's action. From there you create a new response object and set its contents equal to the view requests, and finally send the response to the client's browser -- both the content and the headers. It's a good idea to do this through Phalcon rather than echoing directly or using PHP's header(), so it's only done at the moment you call $response->send(); This is best practice because it allows you to create tests, such as in phpunit, so you can test for the existence of headers, or content, while moving off to the next response and header without actually sending anything so you can test stuff. Same idea with exit; in code, is best to avoid so you can write tests and move on to the next test without your tests aborting on the first test due to the existence of exit.
As far as how the Phalcon application works, and in what steps, it's much easier to follow the flow by looking at manual bootstrapping:
https://docs.phalconphp.com/en/3.2/application#manual-bootstrapping
At the heart of Phalcon is the DI, the Dependency Injection container. This allows you to create services, and store them on the DI so services can access each other. You can create your own services and store them under your own name on the DI, there's nothing special about the names used. However depending on the areas of Phalcon you used, certain services on the DI are assumed like "db" for interacting with your database. Note services can be set as either shared or not shared on the DI. Shared means it implements singleton and keeps the object alive for all calls afterwards. If you use getShared, it does a similar thing even if it wasn't initially a shared service. The getShared method is considered bad practice and the Phalcon team is talking about removing the method in future Phalcon versions. Please rely on setShared instead.
Regarding multiple views, you can start with $this->view->disable(); from within the controller. This allows you to disable a view so you don't get any content generated to begin with from within a controller so you can follow how views work from within controllers.
Phalcon assumes every controller has a matching view under /someController/someView followed by whatever extension you registered on the view, which defaults to .volt but can also be set to use .phtml or .php.
These two correspond to:
Phalcon\Mvc\View\Engine\Php and Phalcon\Mvc\View\Engine\Volt
Note that you DON'T specify the extension when looking for a template to render, Phalcon adds this for you
Phalcon also uses a root view template index.volt, if it exists, for all interactions with the view so you can use things like the same doctype for all responses, making your life easier.
Phalcon also offers you partials, so from within a view you can render a partial like breadcrumbs, or a header or footer which you'd otherwise be copy-pasting into each template. This allows you to manage all pages from the same template so you're not repeating yourself.
As far as which view class you use within Phalcon, there's two main choices:
Phalcon\Mvc\View and Phalcon\Mvc\View\Simple
While similar, Phalcon\Mvc\View gives you a multiple level hierarchy as described before with a main template, and a controller-action based template as well as some other fancy features. As far as Phalcon\Mvc\View\Simple, it's much more lightweight and is a single level.
You should be familiar with hierarchical rendering:
https://docs.phalconphp.com/en/3.2/views#hierarchical-rendering
The idea is with Phalcon\Mvc\View that you have a Main Layout (if this template exists) usually stored in /views/index.volt, which is used on every page so you can toss in your doctypes, the title (which you would set with a variable the view passed in), etc. You'd have a Controller Layout, which would be stored under /views/layouts.myController.volt and used for every action within a controller (if this template exists), finally you'd have the Action Layout which is used for the specific action of the controller in /views/myController/myAction.volt.
There are all types of ways you can break from Phalcon's default behavior. You can do the earlier stated $this->view->disable(); so you can do everything manually yourself so Phalcon doesn't assume anything about the view template. You can also use ->pick to pick which template to use if it's going to be different than the controller and action it's ran in.
You can also return a response object from within a controller and Phalcon will not try to render the templates and use the response object instead.
For example you might want to do:
return $this->response->redirect('index/index');
This would redirect the user's browser to said page. You could also do a forward instead which would be used internally within Phalcon to access a different controller and/or action.
You can config the directory the views are stored with setViewsDir. You can also do this from within the controller itself, or even within the view as late as you want, if you have some exceptions due to a goofy directory structure.
You can do things like use $this->view->setTemplateBefore('common') or $this->view->setTemplateAfter('common'); so you can have intermediate templates.
At the heart of the view hierarchy is <?php echo $this->getContent(); ?> or {{ content() }} if you're using Volt. Even if you're using Volt, it gets parsed by Phalcon and generates the PHP version with $this->getContent(), storing it in your /cache/ directory, before it is executed.
The idea with "template before" is that it's optional if you need another layer of hierarchy between your main template and your controller template. Same idea with "template after" etc. I would advise against using template before and after as they are confusing and partials are better suited for the task.
It all depends on how you want to organize your application structure.
Note you can also swap between your main template to another main template if you need to swap anything major. You could also just toss in an "if" statement into your main template to decide what to do based on some condition, etc.
With all that said, you should be able to read the documentation and make better sense of how to utilize it:
https://docs.phalconphp.com/en/3.2/api/Phalcon_Mvc_View
I am a Drupal dev and new to code-igniter or any such php frameworks.
Now i have to modify an existing application done on codeigniter and the structure must be as follows:
example.com/motors
example.com/motors/car-for-sale
example.com/motors/car-for-rent etc.
Before it has only one url example.com/motors and i want to create more urls as mentioned above.
In the application\views\content folder i have the following structure:
application\views\content\motors.php
application\views\content\motors
application\views\content\motors\car-for-sale.php
In the application\controller folder i have the following structure:
application\controller\motors.php
application\controller\motors\motors.php
application\controller\motors\car-for-sale.php
I want to get the url example.com/motors & example.com/motors/car-for-sale from the files resides in the motors folder.Also how can i set a default file to load when i open example.com/motors?
You can't have a (controllers) directory that matches the name of a controller class at the same level. That is, since you have a controllers/motors.php, the files under controllers/motors/* will never be reached.
Instead (and this is the answer to your second question), you should set the default_controller name and rename controllers/motors.php to controllers/motors/<default_controller>.php.
Note that the default_controller setting points to a controller name (not a file location) and is applied to all directories. That is, if you set it to 'Default', then controllers/Default.php will be used when you open http://domain.tld/ and controllers/motors/Default.php will be used if you open http://domain.tld/motors/.
Also, your controller names MUST start with a capital letter, so default.php would be incorrect and should be Default.php instead. This might be working for you on Windows right now (because of its case-insensitive file system), but as soon as you upload your site to a Linux (or other UNIX-based) host, any classes with file names that don't start with a capital letter won't work.
It looks like you're trying to build a CodeIgniter site with a completely different paradigm from what it is designed around.
The structure you are after can be set up using the routes.php file within application/config
In there, you can set routes to go to any location needed, so for you, something like:
$routes['motors/cars-for-sale'] => 'motors/cars_for_sale';
$routes['motors/cars-for-rent'] => 'motors/cars_for_rent';
Then in application/controller you'd have a Motors.php file, which starts:
class Motors extends CI_Controller{
And also has the functions cars_for_sale and cars_for_rent
The mappings in routes sets this to link together.
In order to get the views you want for any given route, in the controller function, you'd have:
$this->load->view('path/to/view/file', $array_of_data); // view path does not need the .php extension
I'd recommend having a look and possibly even a follow through of the CodeIgniter tutorial in their documentation
According to official documentation:
The filename of the translation files is also important: each message file must be named according to the following path: domain.locale.loader:
I must to name all files such as messages.en_US.php, navigation.en_US.php, admin.en_US.php etc. and place in some folder.
i18n\
admin.en.php
messages.en.php
navigation.en.php
admin.fr.php
messages.fr.php
navigation.fr.php
But my project structure should follow the following structure:
i18n\
en_US\
admin.php
messages.php
navigation.php
fr_FR\
admin.php
messages.php
navigation.php
So how to configure symfony2 to support my structure and use translations in common way:
echo $this->get('translator')->trans('hello', array(), 'messages');
It is possible, you have to load resources calling the addResource() method.
$translator->addLoader('php', new PhpFileLoader());
//Inside a loop:
$translator->addResource('php', 'path/to/messages.php', $locale);
Here is the documentation
https://symfony.com/doc/4.1/components/translation.html#loading-message-catalogs
This is not possible. If you want to use Symfony, stick to the conventions from Symfony!
To be correct: It's not possible in a simple way. You would need to write your own translator component and throw the translator component from Symfony away..
I want to change the Gii template follow my own template that I have where I found the code to change
<div class="errorMessage">....</div> become my own template style??
I have changed most of the gii templates style follow mine but i have not found the line to change the "div" error message on : framework\gii\generators\crud\templates\default
The main view file for CRUD generation is in framework\gii\generators\crud\templates\views\index.php. The form is generated using CCodeForm, and the error messages are generated using the $form->error() method.
You can customise these considerably by just passsing parameters to the $form->error() method as described here, or you can override the $form->error() method by creating your own class which extends CCodeForm, but that may have unintended results!
I'd suggest, for ease, that you pass parameters to each of the $form->error() methods that are called in the view file.
To do this, follow these steps;
Create a folder 'gii' in your protected folder
Create a folder within that called 'crud'
Into that folder copy the entire contents of `framework/gii/generators/crud. These files will now override the default files from gii.
Open protected/gii/crud/views/index.php
Find all the error fields. They look like <?php echo $form->error($model,'controller'); ?>
Add an array of html options to the error declaration, so it looks like <?php echo $form->error($model,'controller', array('class' => 'alert alert-error')); ?>
Thats it! This method has the benefit that you haven't modified the core framework files, so if you update yii your changes will not be overwritten. For more information, have a look at this http://www.yiiframework.com/doc/guide/1.1/en/topics.gii
In zend framework I register my namespace like this (in application.php):
'autoloaderNamespaces' => array(
'Cms_'
)
And after this - I'd expect that Zend would always check that path in addition to Zend and ZendX paths if unknown class is called. But for some reason this doesn't work with for example view helpers.
I still have to register a separate path for my view helpers even though view helper scripts are named according to Zend coding standards and are located in:
Cms/View/Helper/
And this is how I register helper path in config file:
view' => array(
'charset' => 'UTF-8',
'doctype' => 'XHTML1_TRANSITIONAL',
'helperPath' => array(
'Cms_View_Helper_' => 'Cms/View/Helper'
)
),
So - I'm not sure why I have to register "Cms" namespace twice first through 'autoloaderNamespaces' and then through View "helperPath"? Shouldn't Cms namespace include Cms/View/Helper namespace?
can someone plz clarify this:)
View Helpers are considered application specific, so in the Recommended Project Directory Structure View Helpers are supposed to be placed in application/views/helpers. Which means, they usually wouldn't be found if ZF would just resolve the conventionalized class name.
When you call helpers with $this->helperName() or $this->getHelper('HelperName') from the View, the View will use the PluginLoader with the configured prefix and path to fetch that helper and inject the current View Instance. See sourcecode for all the details:
http://framework.zend.com/svn/framework/standard/trunk/library/Zend/View/Abstract.php
http://framework.zend.com/svn/framework/standard/trunk/library/Zend/Loader/PluginLoader.php
So in other words, when loading a ViewHelper, you are not using the Autoloader. See:
Loading Plugins in the Zend Framework Reference Guide
This is taken directly from one of my application.ini files.
autoloaderNamespaces.Foo = "Foo"
includePaths.library = APPLICATION_PATH "/../library"
My "Foo" libraries are in the library directory - library/Foo. All I've done up until this point is make the "Foo" library available within the include paths.
I need to add a separate helper path to the default list for my view, otherwise the view won't look in that directory for matching view helpers. I think of loading view helpers as direct discovery. The view needs explicit instructions on where to look for helpers.
I believe it is exactly as you describe, the documentation on custom view helpers is pretty explicit about it:
You may, and should, give the class name a prefix, and it is recommended that you use 'View_Helper' as part of that prefix: "My_View_Helper_SpecialPurpose". (You will need to pass in the prefix, with or without the trailing underscore, to addHelperPath() or setHelperPath()).
This does make some sense to me though. In theory you could build a library of generic view helpers that could be re-used across multiple applications, so binding them to a specific application namespace would be inconvenient, i.e. if all my helpers were prefixed 'MyApp_' I would have to rename them to be able to use them in 'MyOtherApp'.