So I've been creating my first client website with cakePHP, and have run into a problem.
I'm trying to create a system similar to WordPress where you can create new pages (simply title, slug and content), and they are served up to their slug address (i.e. About will be available at mysite.com/about).
I've created my own controller & model for 'Pages' (overwriting the core pages controller), and have set up simple functions (view, admin_add, admin_delete). My model is simple, just the $name so it can connect to the db.
I'm pretty sure my problem lies in config/routes.php. Here is the code I'm currently using:
App::import('model', 'Page');
$Page = new Page();
$pages = $Page->find('list', array('fields' => array('id', 'slug')));
Router::connect('/:pages', array('controller' => 'pages'), array('Page' => implode($pages, '|')));
It just doesn't work though. When I visit an page I have (i.e. mysite.com/newpage), it tells me the newpage controller can't be found.
PLEASE HELP! I'm on a tight deadline :)
Thanks,
~harley
You need to extend the Class CakeRoute. Put your custom model code in there, and then pass that class name to your route definition in routes.php
routes.php would look something like this.
App::import('Lib', 'routes/MyCustomRoute');
Router::connect('/:page', array('controller'=>'pages', 'action'=>'display'), array('routeClass' => 'MyCustomRoute'));
Then over in libs/routes/my_custom_route.php
class MyCustomRoute extends CakeRoute {
function parse($url) {
$params = parent::parse($url);
//import your model
App::import('Model','Page');
//create model object
$Page = new Page();
//find using $params['page'];
if($Page->find('first', array('conditions'=>array('page.slug'=>$params['page'])))){
//return $params if successfull match
return $params
} else
return false;
//return false to fall through to next route.
}
Related
I want to write a plugin in ZF2,
An example of the plugin is a like button that shows in every post. It should for example print in PostsAction,
I know I can use:
$like = $this->forward()->dispatch('Application\Controller\Index', array(
'action' => 'like',
'postId' => $Id
));
$like variable returns a button that users can click on.
But I want to echo this in the view. In forward the view is not defined.
Also if I use
return $this->getView()->render('application/index/like', array('postId' => $Id));
I don't have access to postId in likeController, because it is set in the view. How I can implement these type of plugins that need a dynamic variables?
Looks like you only need partials. A partial in ZF2 is only a view which you print in another view and give some params to it.
So you could define a View:
// application/partials/button.phtml
<button data-postId="<?php echo $this->postId ?>">Like It!</button>
And use it in other View:
echo $this->partial('application/partials/button.phtml', array(
'postId' => $thePostId
));
Official Documentation
Nice Answer on SO to implement with template_map
Solution using view helper
I think what you are looking for is a custom view helper. You can read on this in the official ZF2 documentation.
You have to write your custom button view helper, register it and then you can use it in your view.
The helper class:
namespace Application\View\Helper;
use Zend\View\Helper\AbstractHelper;
class LikeButtonHelper extends AbstractHelper
{
public function __invoke($post)
{
//return here your button logic, you will have access to $post
}
}
Register your helper within a configuration file:
'view_helpers' => array(
'invokables' => array(
'likeButtonHelper' => 'Application\View\Helper\LikeButtonHelper',
),
)
And finally in the view you can use it like this:
foreach($posts as $post){
echo( ... your code to show the post ...);
echo $this->likeButtonHelper($post);
}
UPDATE - Solution using forward plugin
I think I get what you mean now. I also think the example you are talking about is what in the ZF2 forward plugin documentation is referred to as “widgetized” content.
I think you are doing it correctly. You can attach the return value $like as a child to the view of the original controller (from where you forwarded in the first place).
So in your WidgetController:
use Zend\View\Model\ViewModel;
class WidgetController extends AbstractActionController
{
public function likeAction()
{
$post= $this->params()->fromRoute('post');
$viewModel = new ViewModel(array('post' => $post));
$viewModel->setTemplate('view/widgets/like');
return $viewModel;
}
}
So in your PostController:
use Zend\View\Model\ViewModel;
class PostController extends AbstractActionController
{
public function postsAction()
{
$likeWidget = $this->forward()->dispatch('Application\Controller\WidgetController', array(
'action' => 'like',
'post' => $post
));
$viewModel = new ViewModel();
$viewModel->setTemplate('view/posts/post');
$viewModel = new ViewModel(array(
//...add your other view variables...
));
// Add the result from the forward plugin as child to the view model
if ($likeWidget instanceof ViewModel)
{
$viewModel->addChild($likeWidget , 'likeWidget');
}
return $view;
}
}
And finally in your post view template add:
echo($this->likeWidget);
That is where the widget will eventually output.
The problem remains that you can not do this inside a foreach loop (a loop for printing your posts) in the view. That is why I suggested using a view helper and #copynpaste suggests using a partial, those are more suitable for adding additional logic inside a view.
Note:
Personally I don't like this forward solution for something so simple as a like button. There is hardly any logic in the controller and it seems overly complicated. This is more suitable for reusing a whole view/page that will be both rendered by itself as well as nested in another view.
The partials or view helpers seem much more suitable for what you want to do and those are very proper ZF2 solutions.
I found it ,developed by Mohammad Rostami,Special thanks to him :
Plugin In ZF2
Just started development in the Phalcon PHP framework and am also pretty new to PHP in general. My question is on how to create a request with a route, which I believe I have done, and pass the parameters of the route to the controller action that is linked to the said route. Below I have included the three files that I have been working on and summarize what each one is supposed to do. I also have the end result and where my problem lies directly.
The first file is the index.php file that takes in all route requests for my site.
<?php
//Include all routes on site
foreach (glob("../app/routes/*.php") as $filename)
{
include $filename;
}
foreach (glob("../app/controllers/*.php") as $filename)
{
include $filename;
}
//Create routes and initialize routes
$router = new \Phalcon\Mvc\Router();
$router->mount(new PublicRoutes());
$router->mount(new ApiRoutes());
$router->mount(new AdminRoutes());
$router->handle();
$controller = $router->getControllerName();
$action = $router->getActionName();
$params = $router->getParams();
$di = new \Phalcon\DI\FactoryDefault();
$d = new Phalcon\Mvc\Dispatcher();
$d->setDI($di);
$d->setControllerName($router->getControllerName());
$d->setActionName($router->getActionName());
$d->setParams($router->getParams());
$controller = $d->dispatch();
The second file is the actual routes mounted in for my API call which I am testing everything out with.
<?php
class ApiRoutes extends Phalcon\Mvc\Router\Group
{
public function initialize()
{
//Basic api route for pixelpusher
$this->add(
"/addhawk/api/:action/:model/:params",
array(
"controller" => "api",
"action" => 1,
"model" => 2,
"params" => 3,
)
);
}
}
The third, and final file is the controller class for the API with the only action I am testing right now.
<?php
class ApiController extends \Phalcon\Mvc\Controller
{
public function handlerAction()
{
//Pull in parameters
echo "<h1>API Handler Entered</h1>";
$model = $this->dispatcher->getParam("model");
echo $model;
//Choose correct api based off of api param
if( $model == "grid" ) {
echo 'grid';
}
else if ( $model == "admin" ) {
echo 'admin';
}
else {
//No valid api must have been found for request
}
//Return result from api call
return true;
}
}
So, the url is "localhost/addhawk/api/handler/grate/view" which results in the following output in html courtesy of line 9 in the ApiController.
There is no print out of the $model variable as it should do. There is also no error so I have no idea why it's not printing. According to the documentation and every resource I have read online, all parameters should be available directly from each controller action thanks to the dispatcher and $di class or something similar. So my question is why can I not access the parameters if everything seems to be saying I should be able to?
I've created a new form element class for a special, complex purpose (text input field with an add-on button to open a "search wizard" popup).
To render this element properly, I've also created a form view helper. Everything works and is fine so far.
However, if I try to render the form using the FormCollection view helper, the element is rendered as a basic input element. That's because the FormElement view helper, which the FormCollection helper relies on, uses a hard-coded series of if clauses to map the element's type to a specific form view helper. It can't map my element's class and thus falls back to FormInput.
I.e. (taken from Zend/Form/View/Helper/FormElement.php, line 41-49):
if ($element instanceof Element\Button) {
$helper = $renderer->plugin('form_button');
return $helper($element);
}
if ($element instanceof Element\Captcha) {
$helper = $renderer->plugin('form_captcha');
return $helper($element);
}
...
$helper = $renderer->plugin('form_input');
return $helper($element);
and so on.
I've got a little stuck here because this architecture doesn't really promote extensibility.
The only solution that came to my mind (except rendering the form by hand) is to extend the FormElement view helper class and thus create my own CustomFormElement view helper. However, because of its complexity, I've put the custom element into an own module. So I'd have to write this CustomFormElement helper dynamically to add custom elements from any module. I don't think this is a recommended procedure.
Is there another solution or is maybe even my complete approach unrecommended? Thanks in advance!
I think the simplest way is to extend Zend\Form\View\Helper\FormElement, handle your field types in your render() method and register your FormElement as default FormElement for your application/module. Assuming that you have your custom TestField that you would like to render:
namespace Application\Form\View\Helper;
use \Zend\Form\ElementInterface;
use \Zend\Form\View\Helper\FormElement
use \Application\Form\Element\TestField;
class MyFormElement extends FormElement
{
public function render(ElementInterface $element)
{
$renderer = $this->getView();
if (!method_exists($renderer, 'plugin')) {
// Bail early if renderer is not pluggable
return '';
}
//your custom fields go here...
if ($element instanceof TestField) {
$helper = $renderer->plugin('\Application\Form\View\Helper\FormTestField');
return $helper($element);
}
return parent::render($element);
}
}
And in Application/config/module.config.php:
'view_helpers' => array(
'invokables' => array(
'form_element' => 'Application\Form\View\Helper\MyFormElement',
)
)
Get your hands on the FormElement view helper any way you can and addType to overwrite the view helper used. i.e. in view, just before you render your form:
<?php $this->plugin('FormElement')->addType('text', 'formcustom'); ?>
This will overwrite the view helper used in the FormRow,FormCollection helpers using your view helper by the key name:
in your config
'view_helpers' => array(
'invokables' => array(
'formcustom' => 'Application\Form\View\Helper\FormCustom',
)
),
When this question was asked the method may not have been there. But it is now.
The following is what I've done and feels like the right level of keeping things separate and neat.
Given:
A new element: MyModule\Form\MyElement which extends Zend\Form\Element
A new view helper class for MyElement: MyModule\Form\View\Helper\FormMyElement which extends Zend\Form\View\Helper\AbstractHelper
Here's how you register your view helper to be used to render your element by adding the following to module.config.php:
'view_helpers' => array(
'invokables'=> array(
'formMyElement' => 'MyModule\Form\View\Helper\FormMyElement',
),
'factories' => array(
'formElement' => function($sm) {
$helper = new \Zend\Form\View\Helper\FormElement();
$helper->addClass('MyModule\Form\MyElement', 'formMyElement');
return $helper;
}
),
),
The key is that you are providing a new factory method for FormElement that still creates the same, standard class (no need to override it), but also calls the addClass method to register your custom helper as the proper helper for your custom element. If you don't want to make the short-name for your helper, you can drop the invokables section and put the FQCN in the addClass call, but I like having the short name available.
This is the best method I've found so far. Ideally, you wouldn't have to take over the construction of the FormElement and could just modify a config that gets passed to it. The downside of this approach is that if you have multiple modules that define custom form elements they are going to clash if they all try to re-define the FormElement factory. You can't specify additions in multiple modules this way. So, if someone finds a better config that can be set that simply gets passed to the FormElement::addClass() method, please let me know.
BTW, I found this page which doesn't address the view helper side of the equation, but talks about registering new form element classes and how to over-ride the built in classes: http://framework.zend.com/manual/current/en/modules/zend.form.advanced-use-of-forms.html
----custom form element-----
namespace App\Form\View\Helper;
use Zend\Form\View\Helper\FormElement as ZendFormElement;
/**
* Description of FormElement
*/
class FormElement
extends ZendFormElement
{
public function addTypes(array $types)
{
foreach ($types as $type => $plugin) {
$this->addType($type, $plugin);
}
}
}
---- application module.config.php--------------
//..........
'view_helpers' => array(
'invokables' => array(
'formRTE' => 'App\Form\View\Helper\FormRTE',
),
'factories' => array(
'formElement' => function($sm) {
$helper = new App\Form\View\Helper\FormElement();
$helper->addTypes(array(
'rte' => 'formRTE',
));
return $helper;
}
),
),
//.........
Seems like we're both running into Form issues with Zend. I think that it could be better integrated with the whole MVC structure.
I think that your approach is sound. What I might think of doing is the following
Give your elements a variable named helper like in ZF1.
Create the custom form element renderer that will ALSO check the renderer attribute of a form element to decide on how to render it.
You could re-use the ViewHelperProviderInterface or create your own interface:
class CustomElement implements ViewHelperProviderInterface
{
public function getViewHelperConfig()
{
return array('type' => '\My\View\Helper');
}
}
or
class CustomElement implements FormHelperProviderInterface
{
public function getFormHelperConfig()
{
return '\My\View\Helper';
// or
return new My\View\Helper();
}
}
Then in your FormElement class you can do the following:
if ('week' == $type) {
$helper = $renderer->plugin('form_week');
return $helper($element);
}
if ($element instanceof THEINTERFACE) {
return $renderer->plugin($element->getFormHelperConfig());
}
$helper = $renderer->plugin('form_input');
return $helper($element);
This is probably what you had in mind anyway.
You'd probably be better off creating your own interface since the first one already has some sort of meaning behind it and it might confuse someone.
Aside from that, each module would then ONLY have to provide a helper_map key in the module configuration to have it's view helpers available during rendering with the MVC components.
I am new to Joomla, I want to know how the Joomla controller passes data to the model, model to controller and controller to view. Although this might be a silly question, I really tried to find the answer. I hope I can get some help from the stackoverflow family.
The controller picks up the view variable in the url and using these determines which view needs to be used. It then sets the view to be used. The view then calls the model to fetch the data it requires and then passes this to the tmpl to be displayed.
Below is a simple setup of how this all works together:
components/com_test/controller.php
class TestController extends JController
{
// default view
function display() {
// gets the variable some_var if it was posted or passed view GET.
$var = JRequest::getVar( 'some_var' );
// sets the view to someview.html.php
$view = & $this->getView( 'someview', 'html' );
// sets the template to someview.php
$viewLayout = JRequest::getVar( 'tmpl', 'someviewtmpl' );
// assigns the right model (someview.php) to the view
if ($model = & $this->getModel( 'someview' )) $view->setModel( $model, true );
// tell the view which tmpl to use
$view->setLayout( $viewLayout );
// go off to the view and call the displaySomeView() method, also pass in $var variable
$view->displaySomeView( $var );
}
}
components/com_test/views/someview/view.html.php
class EatViewSomeView extends JView
{
function displaySomeView($var) {
// fetch the model assigned to this view by the controller
$model = $this->getModel();
// use the model to get the data we want to use on the frontend tmpl
$data = $model->getSomeInfo($var);
// assign model results to view tmpl
$this->assignRef( 'data', $data );
// call the parent class constructor in order to display the tmpl
parent::display();
}
}
components/com_test/models/someview.php
class EatModelSomeView extends JModel
{
// fetch the info from the database
function getSomeInfo($var) {
// get the database object
$db = $this->getDBO();
// run this query
$db->setQuery("
SELECT
*
FROM #__some_table
WHERE column=$var
");
// return the results as an array of objects which represent each row in the results set from mysql select
return $db->loadObjectList();
}
}
components/com_test/views/someview/tmpl/someviewtmpl.php
// loop through the results passed to us in the tmpl
foreach($this->data as $data) {
// each step here is a row and we can access the data in this row for each column by
// using $data->[col_name] where [col_name] is the name of the column you have in your db
echo $data->column_name;
}
check out this site for detailed tutorial on how to make components and modules using Joomla's MVC. Hope it helps
https://docs.joomla.org/Developing_a_MVC_Component
Also refer official joomla doc for detailed tutorial on how to make components and modules using Joomla's MVC. Hope it helps
http://docs.joomla.org/Developing_a_Model-View-Controller_Component/1.5/Introduction
I currently have a search form in the search controller, so the only way I can get to it is through /search/. I have to refactor my code so that this search form appears not only in the Search Controller but also globally throughout the site.
( The code isnt exact as I had to retype some of it )
My class that extends Zend_Form is located in application/forms/forms/SearchForm.php:
class Form_SearchForm extends Zend_Form {
public function init() {};
}
My search controller is something like..
class SearchController extends Zend_Controller_Action
{
public function search() {
$searchForm = new Form_SearchForm();
$this->view->form = $searchForm;
}
}
In my Bootstrap.php I have an autoloader for models:
protected function _initAutoload() {
$autoLoader = Zend_Loader_Autoloader::getInstance();
$resourceLoader = new Zend_Loader_Autoloader_Resource(
array(
'basePath' => APPLICATION_PATH,
'namespace' => '',
'resourceTypes' => array(
'form' => array(
'path' => 'forms',
'namespace' => 'Form_',
),
'model' => array(
'path' => 'models/',
'namespace' => 'Model_',
),
),
)
);
return $autoLoader;
}
I'm wondering where I can store my code so that globally the search form is generated in the view.
My global layout file is located in application/layouts/scripts/layout.phtml and currently spits out a dynamic content area:
<div id="main">
<?php echo $this->layout()->content;?>
</div>
Should I just add the form to this layout.phtml or is there some generic controller I should use?
Edit: Sorry for not specifying this too, but what if for example I wanted to not include it for 1-2 special pages ( maybe an admin section ).. if I hardcoded it into layout.phtml it would still appear.. or should I serve a different layout file to say, an admin area?
Creating a searchAction() is not good for performance because it requires a brand new dispatch cycle. If, and only if, you have very complex logic that justifies a separate action, you could create a Controller Plugin and add searchAction() to the ActionStack. If you are only instantiating/assigning the form or if you don't need the search form for every request, it's not an optimal solution.
Another possibility would be to instantiate and assign the form in the bootstrap. This kind-of breaks separation of concerns, but provides better performance.
protected function _initSearchForm()
{
$this->bootstrap('view');
$view = $this->getResource('view');
$searchForm = new Form_SearchForm();
$view->searchForm = $searchForm;
return $searchForm;
}
Finally, my preferred solution would be a custom view helper:
<?php
class My_View_Helper_SearchForm extends Zend_View_Helper_Abstract
{
public function searchForm()
{
$searchForm = new Form_SearchForm();
return $searchForm;
}
}
For either of these solutions, you'd ideally output the form in your layout file to minimise duplication.
layout.phtml:
<?php echo $this->searchForm() ?>
And create an alternate layout admin.phtml for admin area pages. This gives you the flexibility to change the admin pages significantly when new requirements pop up.
You can create your Form in a Controller Plugin and add it to view vars somehow (by Zend_Controller_Front?), which are accessible in layout, too. But it's too complicated in current ZF version (or I'm too dumb)
You can make Form_SearchForm a singleton
class Form_SearchForm ... {
static function getInstance() {
static $instance;
if (!$instance)
$instance = new Form_SearchForm();
return $instance;
}
}
Now instead of creating new Form_SearchForm() just get it as
$form = Form_SearchForm::getInstance();
You can put an instance of Form_SearchForm to the registry
I probably have missed a very cool a simple way :)
I would split it into a partial and a place holder.
in layout.phtml:
<?php if($searchForm = $this->placeHolder('searchForm'): ?>
<?php echo $searchForm; ?>
<?php endif; ?>
then in your views you can call:
<?php $this->placeHolder('searchForm')->set($this->partial('search-from.phtml', 'search')); ?>
IF you wanted you could even make a search view helper that basically does the place holder call.
The Controller plugin would be better if you have more pages that dont need it than d though. I would still probably use placeholder though to accomplish it. That way you can easily override or append to it later on a view-by-view basis without calling anything on the front controller.