I have been looking for a way to use Laravels Blade templating engine with non PHP file extensions (instead of file_name.blade.php being able to use file_name.blade.js or file_name.blade.css) to no avail. I found a post that seems to describe how to do exactly this for Laravel 4, however it no longer seems to work in Laravel 5. The reason why I would like to do this is I have a Javascript file that looks something like this:
//JS stuff
#foreach($Model->Values as $Value)
{{ $Value->name . " = " . $Value->content . ";"}}
#endforeach
//More JS stuff
And a blade/php file that looks something like this:
//Blade stuff
<script type="text/javascript">
#include('js');
</script>
And this seems to be the nicest way of passing each value to javascript. Even if there is a nicer way of passing these values to javascript, the reason behind this question is to find if there is a way to parse a non PHP file with blade as I think that could be immensely useful.
I thought View::addExtension('blade.js', 'blade') would work in L5 as well. The method hasn't changed. But do note you'll want the blade engine, not the html one like in the post you linked to. Where to put it is a good question, though. Also, you mentioned your two files have the same name before the extensions - that might screw it up, too.
Related
I want to cleanup my php file. I really like the way how blade template use curly brace to display php variables {{ $user }} https://laravel.com/docs/5.8/blade#displaying-data
Is there a way to use a functionality like that without using blade template. Using <?php echo $user ?> get's very repetitive.
This is not possible in PHP without using a template engine because it is a different syntax. Anyway in my opinion sometimes it is not the best idea to use a template engine because PHP is already kind of a template engine.
All what you seem to care about is the short syntax of echoing a variable in blade:
{{ user }}
This is as short as the syntax the PHP template engine itself provides:
<?= $user ?>
Of course Laravel (and similar) has a good reason to use template engine like blade - in order to seperate controller, logic and view (such that the view can be made by non-programmer designers for instance).
Update (thx to comments): The codes provided above do not exactly do the same as template engines (as an additional layer) may take care of e.g. escaping variables, which adds safety to the code.
As the OPs' code has already been built with echo and he is just searching for a replacement I did not mention this, but its a notable difference that you have to take care of some things yourself if not using one.
I have been designing websites for a while now, but there is one thing that I have never been quite sure of when using PHP and HTML. Is it better to have the whole document in PHP and echo HTML like so:
<?php
doSomething();
echo "<div id=\"some_div\">Content</div>";
?>
Or have a HTML file like so and just add in the PHP:
<html>
<body>
<?php doSomething(); ?>
<div id="some_div">Content</div>
</body>
</html>
It seems tidier to echo HTML, especially if lots of PHP gets used throughout the page, but doing so loses all formatting of the HTML i.e. colors in the IDE etc.
There are varying opinions on this. I think there are two good ways:
Use a templating engine like Smarty that completely separates code and presentation.
Use your second example, but when mixing PHP into HTML, only output variables. Do all the code logic in one block before outputting anything, or a separate file. Like so:
<?php $content = doSomething();
// complex calculations
?>
<html>
<body>
<?php echo $content; ?>
<div id="some_div">Content</div>
</body>
</html>
Most full-fledged application frameworks bring their own styles of doing this; in that case, it's usually best to follow the style provided.
I think this would depend on your group's or your own decided convention. And it can and should vary depending on what type of file you're working in. If you follow the MVC pattern then your views should be the latter. If you're writing a class or some non-output script/code then you should use the former.
Try to keep a separation of display or formatting of output and the logic that provides the data. For instance let's say you need to make a quick page that runs a simple query and outputs some data. In this case (where there is no other existing infrastructure or framework) you could place the logic in an include or in the top or the bottom of the file. Example:
<?php
# define some functions here that provide data in a raw format
?>
<html>
<body>
<?php foreach($foo = data_function($some_parameter) as $key => $value): ?>
<p>
<?=$value;?>
</p>
<?php endforeach; ?>
</body>
</html>
Or you could place the logic and function definitions in an include file or at the bottom of the file.
Now if you're producing some sort of class that has output (it really shouldn't) then you would echo the HTML or return it from the method being called. Preferably return it so that it can be output whenever and however the implementer would like.
The syntax highlighting is an important benefit of the second method, as you said. But also, if you're following good practices where logic and presentation are separated, you will naturally find that your files that contain HTML are almost entirely HTML, which then, naturally, leads to your second method again. This is the standard for MVC frameworks and the like. You'll have a bunch of files that are all PHP, doing logic, and then when that's done they'll include a presentation file which is mostly HTML with a sprinkling of PHP.
Simple:
More PHP - close HTML in PHP. When you generate HTML code in PHP, when you are doing something like a class, so it is better to make it in echo.
Less PHP - close PHP in HTML. This is stuff like just putting vars into fields of HTML stuff, like forms... And such.
The best approach is to separate the HTML from the PHP using template system or at least some kind of HTML skeleton like:
<main>
<header/>
<top-nav/>
<left-col>
<body />
</left-col>
<right-col />
<footer/>
</main>
Each node represents a template file e.g. main.php, hrader.php and so on. Than you have to separate the PHP code from the templates as something like functions.php and fineally use your second approach for template files and keeping functions clean of "echos" and HTML.
If you can, use a template engine instead.
Although it is slightly easier at first to mix your HTML and PHP, separating them makes things much easier to maintain later on.
I would recommend checking out TemplateLite which is based on Smarty but is a little more light weight.
I've reached a conclusion that using views in MVC framework e.g. Laravel, Yii, CodeIgniter is the best approach even if you are not displaying the html straight away.
Inside the view do all the echoing and looping of prepared variables, don't create or call functions there, unless formatting existing data e.g. date to specific format date('Y-m-d', strtodate(123456789)). It should be used only for creating HTML, not processing it. That's what frameworks have controllers for.
If using plain PHP, create you own view function to pass 3 variables to - html file, array of variables, and if you want to get output as string or print it straight away for the browser. I don't find a need for it as using frameworks is pretty much a standard. (I might improve the answer in the future by creating the function to get view generated HTML) Please see added edit below as a sample.
Frameworks allow you to get the HTML of the view instead of displaying it. So if you need to generate separate tables or other elements, pass the variables to a view, and return HTML.
Different fremeworks may use various type of templating languages e.g. blade. They help formatting the data, and essentially make templates easier to work with. It's also not necessary to use them for displaying data, or if forced to use it by the framework, just do required processing before posting the variables, and just "print" it using something like {{ yourVariable }} or {{ yourVariable.someProperty }}
Edit: here's a plain PHP (not framework PHP) - simple-php-view repository as a sample view library that allows to generate HTML using variables. Could be suitable for school/university projects or such where frameworks may not be allowed.
The repository allows to generate HTML at any time by calling a function and passing required variables to it, similar to frameworks. Separately generated HTML can then be combined by another view.
It depends on the context. If you are outputting a lot of HTML with attributes, you're going to get sick of escaping the quotation marks in PHP strings. However, there is no need to use ?><p><? instead of echo "<p>"; either. It's really just a matter of personal taste.
The second method is what I usually use. And it was the default method for me too. It is just to handy to get php to work inside html rather than echo out the html code. But I had to modify the httpd.conf file as my server just commented out the php code.
Let's say I have a piece of jQuery javascript that binds to a div on load and dynamically defines an img in that div. Something like this:
$(document).ready(function() {
$("#container").html("<img href='/images/myimage.jpg/>');
});
If I were to use this inlined in a Laravel view, I'd be able to use HTML::image() and Blade templates to specify the location of image. Something like this:
$(document).ready(function() {
$("#container").html("{{ HTML::image('images/myimage.jpg', 'My image') }}");
});
If I were then to take that piece of javascript, and, instead of inlining it in the view, place it inside a separate .js file, say, public/js/image.js, I could have Laravel load it as an asset;
Asset::add('image.js', 'js/image.js');
However, since it's now treated only as an asset, neither the Laravel PHP nor the Blade templating code is processed, so we literally get the string {{ HTML::image('images/myimage.jpg', 'My image') }} in the resulting html, instead of the templated-in values.
Is there a good approach for something like this?
I'm doing this here. The way I found was:
1 - create a 'js' file inside the view directory tree, something like
app\views\javascript\mycustomJS.blade.php
2 - then render it wherever you need:
<script>
#include('javascript.mycustomJS')
</script>
It's blade, it will be processed as it should.
This is far from ideal, I know, but it works for me, for now. :)
I think you can put it in a php file. I've done this before with css.
Asset::add('image.php', 'js/image.php');
I need to be able to create a line that looks like this:
<script type="text/javascript" src="http://localhost/myapp/themes/testtheme/js/fancybox/jquery.fancybox.pack.js?v=2.1.2"></script>
I've tried the following:
Assets::add_js('fancybox/jquery.fancybox.pack.js?v=2.1.2');
but that fails - it doesn't add anything at all to my header.
Using:
Assets::add_js('fancybox/jquery.fancybox.pack.js');
adds a script tag, but without the version number. It just looks like this:
<script src="http://localhost/myapp/bonfire/themes/testtheme/js/fancybox/jquery.fancybox.pack.js" type="text/javascript" ></script>
Can you tell me how to add the ?v=2.1.2 to my script tag? Thanks!
I'm not too familiar with Bonfire, but I took a quick look at the source code.
I'm pretty sure the reason it's not displaying the script tag is because it's looking for a file with the literal name fancybox/jquery.fancybox.pack.js?v=2.1.2, which doesn't exist.
I think you can trick it by using a full url, so it thinks it's an external script and won't check if the file exists. Something like:
Assets::add_js(base_url().'fancybox/jquery.fancybox.pack.js?v=2.1.2');
It's never pleasant to have to use workarounds like this and can sometimes cause side effects, so I would suggest you point this out to the developer(s) of Bonfire.
Another thing to note, ?v=2.1.2 is nothing more than a cache-busting trick for when you update the file (it makes users re-download the file when the query string is changed), so consider whether or not you actually need it.
I have been designing websites for a while now, but there is one thing that I have never been quite sure of when using PHP and HTML. Is it better to have the whole document in PHP and echo HTML like so:
<?php
doSomething();
echo "<div id=\"some_div\">Content</div>";
?>
Or have a HTML file like so and just add in the PHP:
<html>
<body>
<?php doSomething(); ?>
<div id="some_div">Content</div>
</body>
</html>
It seems tidier to echo HTML, especially if lots of PHP gets used throughout the page, but doing so loses all formatting of the HTML i.e. colors in the IDE etc.
There are varying opinions on this. I think there are two good ways:
Use a templating engine like Smarty that completely separates code and presentation.
Use your second example, but when mixing PHP into HTML, only output variables. Do all the code logic in one block before outputting anything, or a separate file. Like so:
<?php $content = doSomething();
// complex calculations
?>
<html>
<body>
<?php echo $content; ?>
<div id="some_div">Content</div>
</body>
</html>
Most full-fledged application frameworks bring their own styles of doing this; in that case, it's usually best to follow the style provided.
I think this would depend on your group's or your own decided convention. And it can and should vary depending on what type of file you're working in. If you follow the MVC pattern then your views should be the latter. If you're writing a class or some non-output script/code then you should use the former.
Try to keep a separation of display or formatting of output and the logic that provides the data. For instance let's say you need to make a quick page that runs a simple query and outputs some data. In this case (where there is no other existing infrastructure or framework) you could place the logic in an include or in the top or the bottom of the file. Example:
<?php
# define some functions here that provide data in a raw format
?>
<html>
<body>
<?php foreach($foo = data_function($some_parameter) as $key => $value): ?>
<p>
<?=$value;?>
</p>
<?php endforeach; ?>
</body>
</html>
Or you could place the logic and function definitions in an include file or at the bottom of the file.
Now if you're producing some sort of class that has output (it really shouldn't) then you would echo the HTML or return it from the method being called. Preferably return it so that it can be output whenever and however the implementer would like.
The syntax highlighting is an important benefit of the second method, as you said. But also, if you're following good practices where logic and presentation are separated, you will naturally find that your files that contain HTML are almost entirely HTML, which then, naturally, leads to your second method again. This is the standard for MVC frameworks and the like. You'll have a bunch of files that are all PHP, doing logic, and then when that's done they'll include a presentation file which is mostly HTML with a sprinkling of PHP.
Simple:
More PHP - close HTML in PHP. When you generate HTML code in PHP, when you are doing something like a class, so it is better to make it in echo.
Less PHP - close PHP in HTML. This is stuff like just putting vars into fields of HTML stuff, like forms... And such.
The best approach is to separate the HTML from the PHP using template system or at least some kind of HTML skeleton like:
<main>
<header/>
<top-nav/>
<left-col>
<body />
</left-col>
<right-col />
<footer/>
</main>
Each node represents a template file e.g. main.php, hrader.php and so on. Than you have to separate the PHP code from the templates as something like functions.php and fineally use your second approach for template files and keeping functions clean of "echos" and HTML.
If you can, use a template engine instead.
Although it is slightly easier at first to mix your HTML and PHP, separating them makes things much easier to maintain later on.
I would recommend checking out TemplateLite which is based on Smarty but is a little more light weight.
I've reached a conclusion that using views in MVC framework e.g. Laravel, Yii, CodeIgniter is the best approach even if you are not displaying the html straight away.
Inside the view do all the echoing and looping of prepared variables, don't create or call functions there, unless formatting existing data e.g. date to specific format date('Y-m-d', strtodate(123456789)). It should be used only for creating HTML, not processing it. That's what frameworks have controllers for.
If using plain PHP, create you own view function to pass 3 variables to - html file, array of variables, and if you want to get output as string or print it straight away for the browser. I don't find a need for it as using frameworks is pretty much a standard. (I might improve the answer in the future by creating the function to get view generated HTML) Please see added edit below as a sample.
Frameworks allow you to get the HTML of the view instead of displaying it. So if you need to generate separate tables or other elements, pass the variables to a view, and return HTML.
Different fremeworks may use various type of templating languages e.g. blade. They help formatting the data, and essentially make templates easier to work with. It's also not necessary to use them for displaying data, or if forced to use it by the framework, just do required processing before posting the variables, and just "print" it using something like {{ yourVariable }} or {{ yourVariable.someProperty }}
Edit: here's a plain PHP (not framework PHP) - simple-php-view repository as a sample view library that allows to generate HTML using variables. Could be suitable for school/university projects or such where frameworks may not be allowed.
The repository allows to generate HTML at any time by calling a function and passing required variables to it, similar to frameworks. Separately generated HTML can then be combined by another view.
It depends on the context. If you are outputting a lot of HTML with attributes, you're going to get sick of escaping the quotation marks in PHP strings. However, there is no need to use ?><p><? instead of echo "<p>"; either. It's really just a matter of personal taste.
The second method is what I usually use. And it was the default method for me too. It is just to handy to get php to work inside html rather than echo out the html code. But I had to modify the httpd.conf file as my server just commented out the php code.