I am new to Laravel, so still getting used to the concepts, however I have around 10 years of experience using Smarty. So I wish to capitalize on that (apart from the fact that Blade seems to lack too many features I find useful and ready out of the box in Smarty, but anyway besides the point of this question).
I have been looking around to find the right way of using Smarty in Laravel, and although on a few forums such as here it seems to be possible its not clear what I need to do to use it properly within the framework. More concretely my questions are:
Which Composer package should I include in my composer.json? There seems to be this which includes Smarty itself, because it was modified (not too keen about that). And here they also suggest http://bundles.laravel.com/bundle/SmartyView. Not sure if it is the same, because the bundles sub-domain of laravel.com isn't even coming up. It used to come up a few days ago, but I don't know if they turned it off because bundles are now obsolete and replaced by packages... not sure. There is also this
How should I configure Laravel to use Smarty views instead of Blade views?
Given that Laravel uses REST style pretty URLs, how should I include CSS and JS files from Smarty
views, such that the path to them is dynamically set by Laravel? In Blade you do something like: {{ HTML::style('css/style.css') }}. Can I use something similar? Or better still set a template variable from the code by calling the HTML class? (I don't really like calling PHP code within templates that should just be doing presentation logic.)
Sorry if some questions are a bit trivial.
OK so after some more research, I managed to painlessly integrate Smarty 3 within Laravel 4. I am not sure if it is the best way, but its working perfectly, so open to comments or further suggestions.
I installed this Smarty View for Laravel and followed the instructions to add it in the list of providers in app/config/app.php. After running the php artisan config:publish latrell/smarty command the configuration was automatically created and I was ready to go. This package also seems to use the proper Smarty libraries rather than some modified templates.
I then just created a plain old HTML file, with a .tpl extension in the app/views directory, and a corresponding controller in the app/controllers directory, together with the corresponding route in routes.php and hey presto, it worked without a hitch.
I even modified the BaseController to maintain a common list of template variables (such as the CSS styles etc.) to inject in the HTML without putting ugly PHP code in the template. (I don't know if there's a better way to set them directly into the View from the BaseController rather than expecting the sub-class to pass them in the call to the make method, but I guess thats a different question.)
Code below for who might need it:
HelloWorld.tpl
<!doctype html>
<html lang="en">
<head>
<title>Hello World</title>
<meta charset="UTF-8">
{$style}
</head>
<body>
<div>
<h1>Hello {$name}</h1>
</div>
</body>
</html>
BaseController.php
class BaseController extends Controller {
protected $template_vars = array();
protected function addTemplateVar($key, $value)
{
$this->template_vars[$key] = $value;
}
/**
* Setup the layout used by the controller.
*
* #return void
*/
protected function setupLayout()
{
//not sure if I need this any more since I am using Smarty
if ( ! is_null($this->layout))
{
$this->layout = View::make($this->layout);
}
$this->addTemplateVar("style", HTML::style("css/bootstrap.css"));
}
}
HelloWorldController.php
class HelloWorldController extends BaseController
{
public function showHelloWorld()
{
$this->addTemplateVar('name', 'World!');
return View::make('helloworld', $this->template_vars);
}
}
In routes.php:
Route::get('helloworld', 'HelloWorldController#showHelloWorld');
Hope its useful for someone else.
Related
I started not long ago with building my own mvc structure in PHP.
I have seen many people include in home.php page the header.php and footer.
I am currently stuck in finding a solid way to render my views.
I would like to know if it is even possible the way I am combining the header.php, home.php, and footer.php because this is not working for me which made me curious if there is even a native clean way of working with PHP layout structures?
any info would be appreciated. I try my best to explain the code below.
now working with this MVC structure. the router currently checks the req url and gives the controller
example of very basic router:
2 parameters: first the route, second the controller witch should render the view.
public function get($route, $controller) {
if($_SERVER['REQUEST_METHOD'] !== 'GET') {
return false;
}
$uri = $_SERVER['REQUEST_URI'];
if($uri === $route) {
$this->handled = true;
return include (controllers . $controller);
}
}
the routes that are being called:
$router = new Router();
$router->get('/', 'home.contr.php');
$router->get('/home', 'home.contr.php');
$router->get('/about', 'about.contr.php');
$router->get('/portfolio', 'projects.contr.php');
the router calls the controller and in my controller I render the view. with CreateView function
Home.contr.php:
class Home extends Controller {
public function __construct() {
Home::CreateView('home');
}
}
$home = new Home();
the extend controller that should implement the views/layout:
class Controller {
public static function CreateView($viewName) {
require_once views . 'components/header.php';
require_once views . "$viewName.php";
require_once views . "components/footer.php";
}
}
thank you in advance.
Limitations
MVC is a very broad topic with much different understanding so that by the term alone this is hard to answer properly - even in context of a PHP application. You normally refer to an existing implementation of MVC which is not the case here as you want to do it your own (Hint: Read code of existing implementations that is available and about you want to learn more).
Discussion
With that being said, you can find some practical "first next steps" suggestions at the end of the answer.
But I read your question as well that you're concerned about the HTML templates and perhaps also what this has to do with how you wrote your example. So I start a non-binding discussion about the View and then go over to Route and Controller. The Model layer I've kept out of the discussion mainly, at least for that you have to face third-party libraries as otherwise your application structure would not be a good host for broad functionality, this is touched by autoloading.
I have no authority in MVC, I just used some of the early implementations in PHP and applications influenced by them but never implemented it fully. So don't read out any suggestion from the discussion regarding it, it is merely about your example and what came to my mind in specific to PHP. At the end of the day it is you who will find the answer to your own programming questions.
Let's go.
A suggestion/assumption first: You certainly don't want to implement the view creation with the Controller class but with a View class. It would not change much just that the controller does not "care" about it (MVC = Model View Controller).
You can refactor (change) your code by introducing a View class and move the Controller::createView() to View::create() (compare: extract/move method).
Then using require_once - while it may work - it would only work if the template file is only used once. This is certainly not what you want to express here (and later in the discussion we'll see that with the existing example this can also more easily happen than perhaps intentionally thought), instead use require (or include depending on how you want to handle errors) as they will always execute the code in the file (for potential problems redefining controllers, see later in the discussion first routing and then second autoloading).
Apart from obvious code errors (typos) you'd need to address to get it to run (which is a good opportunity to explore PHP error handling and monitoring for your application) you still need to pass the output data of the controller to the view.
This can be so called view models or just objects (in the broader sense) holding the data to be viewed (rendered by the view). Just require/include-ing the (HTML layout) template files won't suffice as they may contain the HTML structure but not the controllers' output data. On the level of the templates this is typically in variables, e.g. the title of the hypertext document:
<title>
<?= htmlspecialchars($title, ENT_QUOTES | ENT_HTML5) ?>
</title>
If this would be the body of a function, the function definition would be:
function outputHeader(string $title): void {
# ...
}
As we don't have a function by requiring the template files, this is just exemplary. However we could create a generic function that handles requiring a template file and passing the variables to the template (compare include_helper()). In that layer you can also do some ground level error handling (try {} catch (Throwable $throwable) {} etc.). For starters you could collect and group such code in the View class.
What you also likely want to prevent is to bind the view within the controllers' constructor method (Controller::__construct(), ctor in short). It forces you to have a named view - and always the same - makes the controller dependent on that view.
That would mean you couldn't configure any view to any controller. While it wouldn't make sense in most cases to allow an any-to-any relationship here in the concrete practice, it allows you to actually have layer boundaries and to not couple things too tightly (compare: Spaghetti Code 1) and to write code on a higher level (in grade of abstraction, compare Layer of Indirection).
An example in a HTTP application would be to do content negotiation. This would happen on the level of request processing (more in the Router in your example), e.g. a HTTP client requests JSON instead of HTML. Now the HTML templates wouldn't fit here. But the Controller could still do the work if not the view template would be hard-encoded.
To keep things more flexible (so you can use it to a greater extend), one benefit of the MVC model is to use (and to a certain degree somehow pass the result of) the Model by the Controller to the View. It helps you define clear boundaries between those three and keep them more apart from each other (less coupled).
The routing then could negotiate and decide what to bring together, similar as in your example for the Controller already but extended with the View (template), each route could be assigned a layout/template.
As this would work quite the same as with the controller - just for the view - let's see where the current Controller not only is standing in the way for the view but already for the routing (if you find a flaw or bug, look around, often they are not in a single place and alone).
While you already configure the routes in the router, the actual routing you've put in the Controller base-class (Controller::get($route, $controller)). Similar to the __construct() method, this makes the Controller implementation dependent on the Route and even implements the routing. This is pretty convoluted and will certainly become awkward. There is also the problem when you add more routes you loose control which one matches as the matching is done within each Controller etc. . In short, while the code may be functional, it just seems to me it can benefit to be at a different place. As it's about the routing, first place that comes into my mind would be the Router itself. The Router then could do the actual work, "do the routing":
$router = new Router(); # <-- bootstrap
$router->get('/', 'home.contr.php'); # <-- prepare
$router->get('/home', 'home.contr.php'); # <-- prepare
$router->get('/about', 'about.contr.php'); # <-- prepare
$router->get('/portfolio', 'projects.contr.php'); # <-- prepare
$router->route(); # <-- do the work here
The Routers get() method then could stay the same from the outside but you would just store the routes inside and when you invoke the route() method, that configuration is matched against your request implementation.
You could then extend the router configuration with the view name.
It would be then that you still have bound a route to a controller and a view, however you have a central location where this is done (configured/parameterized). Controller and View are more independent to each other and you can concentrate more with their own implementation than the overall wiring which now moved into the router.
Finally while being here, what your example also shows is its dependence on the file-system, you have a certain file-naming convention for the controllers and also the view templates. While it is implicitly necessary to place the code into files, at least in your example on the level of the controllers you can already rely on PHP autoloading. While you want to write everything yourself (e.g. not using a ready-made MVC library), I'd still suggest to make use of some standards, like Autoloader (PSR-4) and as being inherently lazy, make the app a Composer project (it has a composer.json file) as Composer allows you to configure the autoloader and there is a well-defined process developing with it (you can also bring in more easily third-party libraries which you'll certainly need within your application logic, so this is just forward-thinking in a good sense, just start without any requirements just using the Composer autoloader).
So instead of hard-linking controller PHP file-paths, you could say instead that a controller basically is a class definition with at least a single method that the router is able to call. With the autoloader in action, the routing configuration would only need to reference that class/method and PHP then would take care to load the class. This could be done as strings (lazy-loading) or more explicit with the First class callable syntax (PHP 8.1). A good middle-ground for starters perhaps is to have one Controller per class and require to have it an interface so that you have a contract (compare: programming against interfaces 1, 2, 3, 4, 5, 6, 7 etc.). You can then simply pass the class-name and handle the instantiation in the route() method.
$router->get(
/* route */ '/',
/* $controller */ MyApp\MVC\Crontroller\Home::class,
/* $viewName */ 'home'
);
<?php
namespace MyApp\MVC\Controller;
class Home implements Interface {
# ...
}
<?php
namespace MyApp\MVC\Controller;
interface Interface {
public function invoke(InputParameter $params): InvocationResult
}
The route() then could check for the interface to verify some class can be used as a controller (instanceof) and would know how to invoke() the controller by passing the input parameters to receive the result that can be further delegated to the template layer.
This is made possible by also introducing the InputParameter and InvocationResult implementations (classes/interfaces) that help to define the layer boundary of the Controller part.
You can then do something similar for the View layer however the output comes relatively late and you're perhaps not yet settled with it (and you may have different template "engines" depending on use-case) so I would leave it more thin and less engineered and try with the Controllers first and do the delegation in the routing until you learn more about your actual requirements (Session handling, Authentication, Content-Negotiation, Redirects etc.).
At the end of the day you have to make your own decisions here.
Next Steps Suggestions
Add at least one test-script that you can run from your development environment "with a single key-press / click" and simple OK/Fail result (e.g. a simple PHP script that you execute in the shell)
Think about how to improve the error handling so you learn about defects faster (e.g. introduce exception and
Fix the bugs first, your code should actually run first of all (it might not produce the intended results in full but it should at least run - your example does not)
Init Composer / add composer.json to your project
Then change the code to your liking which can benefit having it under test first (compare Unit Tests)
I have been running into this very weird issue with Laravel.
I had a problem where one of my component views was not able to read the variables defined in its class.
It was kind of strange because I have several components running in my project and they all worked fine, except for this one.
So I created a fresh Laravel project to test some things out (Wanted to check if the problem was on my end, maybe I somehow messed up the project files).
I created a new component on a blank project using php artisan make:component Test
Then I simply added a test variable to the class component like so:
<?php
namespace App\View\Components;
use Illuminate\View\Component;
class Test extends Component
{
public $test;
/**
* Create a new component instance.
*
* #return void
*/
public function __construct()
{
$this->test = "testing";
}
/**
* Get the view / contents that represent the component.
*
* #return \Illuminate\View\View|string
*/
public function render()
{
return view('components.test');
}
}
And tried to access it over in the view like so:
<div>
<p> {{$test}} </p>
</div>
For some reason, this is not working and I can't figure out why. It just says that $test is undefined.
Perhaps I should point out, I am a beginner in Laravel, so excuse me if I am making some obvious mistake. It just seemed weird that this is not working on a blank project.
Thank you in advance.
In fact, all of the answers are misleading. The $test property is already public, and as such available to the template. Please don't go and manually add parameters to the view.
I just encountered a similar issue, and while I can say for sure that it has to do with the component class name, I could not trace it down, because it started working again magically.
What I can say about it is:
I had a class with the same base classname but a different namespace, deleted the non-component class, and then suddenly the component was rendered as an anonymous component, by-passing the component class completely. (You can easily verify that by putting a dd() in your component class constructor.)
My first thought was that the autoloader needed a refresh, but composer dump did not change anything.
renaming the component class and template to something else solved the issue.
when I wanted to track down the bug, I renamed the class and template back to the original name, but now it suddenly worked...
my guess is that the view cache was causing the issue. It worked from the moment when I was changing the x-blade (<x-component-name ... />) in the template that was including the component. So it is plausible that the issue magically went away because the cached view was replaced due to the template change.
So based on this, your best options to solve the issue are:
Verify that your properties are public, they will not be available in your template if they are protected or private.
Clear caches, esp. the view cache (php artisan view:clear).
Dump the autoloader (composer dump).
Verify that your class is actually used. Put a dd() in your constructor. If you still get errors from the template, Blade is by-passing your class and trying to use your template as an anonymous component.
Rename the component to something else to see if the class name clashes.
Hope that helps anyone who experiences this confusing issue.
In my case It was because of cached view so php artisan view:clear did the job
so what is wrong?
The problem happens when you already have a view component and in some point you want to add a dedicated class to provide some data to your component and because laravel already cached your component the "dedicated class" wont be triggered
You need to send variable to the view. Some ways
In an array
$test = 'Hi';
return view('components.test', ['test' => $this->test]);
Using with
$test = 'Hi';
return view('components.test')->with('test', $test);
The last one, i like it this one.
$test = 'Hi';
return view('components.test', compact('test'));
Let me know how it works, regards.
within the render() function, instead of return view('components.test');, do return view('components.test', ['test' => $this->test])
I was wondering if yii components are also supporting the theme feature? In my environment right now a component is only considering files within the component/views/ folder.
Now that I am also using themes it would be nice to tell the component to look for the view under the themes/themeName/ folder.
Using the method below I can work around this but it certainly doesn't feel like this is the yii-way to do it.
protected function renderContent()
{
$view = './../../../themes/'.Yii::app()->theme->name.'/views/viewName';
$this->render($view);
}
Do you know of a more elegant solution to achieve this?
There isn't any theming on components. Mainly because they're not intended to be rendering content for anything. Nothing wrong with that though, sometimes it's required.
Easiest solution is probably to just make it more readable, using path aliases always helps:
protected function renderContent()
{
$view = 'webroot.themes.'.Yii::app()->theme->name.'.views.viewName';
$this->render($view);
}
Or you could add a method the component, or extend CComponent to get it across all components if you want it:
public function getViewsPath(){
return 'webroot.themes.'.Yii::app()->theme->name.'.views';
}
Or you could set a path alias:
Yii::setPathOfAlias('theme','webroot.themes.'.Yii::app()->theme->name);
Then you could use that anywhere in your application provided you run it at an early enough point in the process.
I am learning how to use the Zend Framework. I come from a codeigniter background.
What I want to do is define a function somewhere that performs a very simple yet useful function. I am predominantly going to use the function within view scripts. I don;t really want to make a whole class for such a simple thing, so my question is, is there anywhere were can I put a file containg all of my general functions and how do I go about using it?
Thanks
John
What you are looking for are view helpers.
A view helper however is a function in a helper class. Therefore only one view helper can be put in a single class.
If you are using the project setup as used in the quick start tutorial or as generated by Zend_Tool, your view helpers should be put in the application/views/helpers directory.
Declaring a view helper is pretty simple, and is explained in great detail on this page of the zend framework documentation (i must say it's a bit hidden in the docs):
http://framework.zend.com/manual/en/zend.view.helpers.html#zend.view.helpers.custom
Some background information on view helpers as well as some standard included ones can be found on this page: http://framework.zend.com/manual/en/zend.view.helpers.html
Hope this helped you in the right direction.
If you realy whant to use a function you can make a library class with a static method , make a folder like this Application/Library/MyLib , then at bootstrap register MyLib namespace like this
$autoloader = Zend_Loader_Autoloader::getInstance();
$autoloader->registerNamespace('MyLib'); , then inside MyLib folder you can make a filename MyClass , with a class name MyLib_MyClass , then inside you're view you can call MyLib_MyClass::staticMethod().
Tough i suggest you make a view helper for this . You don't realy use functions in ZF like you where used to in CI ( i was in you're exact situation a few months ago ) , ZF is all about OOP .
I am currently using CodeIgniter to support one site, whose main purpose is to display multiple editable tablekit tables, and handle the AJAX that arrives when you edit them. A kind of PHPMyAdmin [VERY] Lite. It has a number of core helpers and controllers, which run the main workings of the site, mixed in with some site specific controllers and helpers.
I would like to restructure my site so that I can reuse the core code-base in another site. However, I would still like to be have some default controller functions and some cutsom functions in the same controller; i.e. in a system file somewhere:
class My_core extends Controller{
/*
Lots of base functions
*/
}
and on one site:
class site_1 extends My_Core{
/*
Site specific functions
*/
}
Then on the other site:
class site_2 extends My_Core{
/*
Site specific functions
*/
}
Does anyone have any guidance on how I can do this?
Thanks,
Lemiant
If you are using CodeIgniter 2.0 you can achieve most of this with with packages. They will let you load helpers, libraries and models from anywhere, so in each application simply configure a package to be loaded from that shared folder.
As for core libraries (which MY_Controller will be) you will have to implement your own __autoload() function:
http://php.net/manual/en/language.oop5.autoload.php
You can put an autoloader at the bottom of config.php. As long as it is checking the correct folders (local first, then the shared folder structure) it should all work pretty nicely.
I don't know if this is still helpful to you but heres what I've done.
say I have 2 websites, palladium.com and osmium.com.
my file tree looks like this
/var/www/system/ (the CI system folder)
/var/www/palladium/application
/var/www/palladium/public/index.php
/var/www/osmium/application
/var/www/osmium/public/index.php
inside those index.php files are lines that define where /system/ is stored. I've got that set to
$system_folder = "../../system";
Now inside /var/www/system/libraries i have a file named MY_TestClass
<?php
class MY_TestClass {
public function MY_TestClass() {
echo "this is a test of the emergency broadcast system";
}
}
From anywhere inside BOTH palladium.com and osmium.com i can call
$this->load->library('MY_TestClass');
and "this is a test of the emergency broadcast system" will show up.