I found this snippet in my Shopify template, with a single set of tags demarking multiple liquid statements. I'm excited to not have to wrap all of my liquid code in individual {% %} tags. Why is style this not used more often?
Is it just preference, or is there a technical reason to avoid it?
{%- liquid
assign isModal = false
if template == 'product.modal'
assign isModal = true
endif
-%}
Liquid has evolved and continues to evolve as a template language. When it was first released, one could only do certain patterns. As it evolved, it became easier to do new patterns as new keywords and supporting parsers were released. Liquid is open source and so many have adopted it and enhanced it too. When Shopify sees others doing something nice, they often adopt it for their Liquid. Anyway, long story short, you can indeed open up a Liquid block, write some statements, and then close it off. We also had a long and varied debate on making comments nicer. You can take advantage of nicer comment structures now too. Progress!
There is no technical reason to avoid perfectly legit tag usage. At the end of the day, the Shopify machine compresses and parses all that Liquid into a single huge string of HTML and dumps it all to the browser, no worries about you issuing as one block or a bunch of smaller ones to get something done.
Related
I would like to know if it is possible to use the django-allauth app with jinja2 templates instead of DTL templates.
There does not appear to be any clear information about this, or usable examples available. I am unsure if this is because its easy and therefore doesn't warrant its own explanation, or because its impossible.
I am aware of this feature request, but it is 3 years old.
Yes, it is. You'll need to use crispy forms in jinja templates though.
Why Neto/Shopify use their own templating language instead using any popular popular language ?
When you have your own templating language you have full freedom to implement or limit the logic of the language to meet your needs.
You don't need to wait for a third party update in order to implement new stuff or objects.
Why do you think Samsung creates clones of google apps on their phones? To create an experience that they can control in some way and if they like to change or add something to do so and not to wait for google to do so. ( and some other things but that is outside the scope of this question )
Since liquid was a Tobias Lütke creation ( co-founder and CEO at Shopify ) and now is an Open Source project it was written in specific fashion in order to meet specific needs and those needs seems to be fitting for Shopify and other platforms as well.
Being popular doesn't mean being better! This is the wrong way to go.
WordPress is the most popular platform, but is it the best one - NO! There are a lot of hole provided by plugins, poorly written themes and some times core issues. While it's easy to use and extendable it opens a lot of doors for issues if you don't manage it properly.
Beats by Dre is the most popular headphones and quite expensive, does they sound as good as the price tag put on them - NO! You can buy the same quality headphones ( even better ) for less, but you are paying for the brand.
Creating new languages in the coding world is ALWAYS a good thing It might be a chore to learn it if it becomes a standard but that means that it provided something that the other popular languages didn't and this pushes the coding world forward. It's a much better alternative than to be in a standstill like when we had only jQuery and there were no new stuffs to excite the developers.
Now we have so much different things that you can choose the direction you like to go and you won't be able to learn all of them even if you try, which is a great thing to a developer who likes to grow.
Conclusion:
Being different is OK as long as that fits your needs and you are not doing it just because it's popular to be different. ( so true IRL now too :D )
This reasoning from their Github Wiki lists some of the reasons. Why Liquid Templating Engine ?
Liquid is a template engine which was crafted for very specific
requirements
It has to have simple markup and beautiful results. Template engines which don't produce good looking results are no fun to use.
It needs to be non-evaling and secure. Liquid templates are made so that users can edit them. You don't want your server running code
that your users wrote.
It has to be stateless. The compile and render steps have to be separate, so that the expensive parsing and compiling can be done
once; later on, you can just render it by passing in a hash with local
variables and objects.
It needs to be able to style emails as well as HTML.
I do not understand why a developer would use Phalcon's Volt template engine.
In the end, after the compilation, the same PHP files are produced, that I would have to write manually in the first place. To me, it looks only to be detrimental to the performance.
Is the answer "so you could pass .volt files to a front-end guy"?
The answer lies in the development of your application. Why do you use a framework instead of pure PHP? Why bother with object oriented programming when procedural/straight PHP is faster?
There are many reasons of course and it is a long discussion. The summary is ease of use and maintainability.
The same goes with Volt. You can use the volt templates to do what it will take you a lot longer if creating plain phtml files (HTML with PHP tags in there). Examples I can give you are template inheritance, partials, calculations within the template (for/each loops) etc.
As far as performance is concerned, there is always a performance hit when using a template engine. Volt luckily is part of Phalcon so the performance hit is minimal since Phalcon does all the hard work in memory instead of using included files here and there to offer its functionality.
The decision is up to you. Volt, Smarty, Twig and others are there to help with development of your application. Your decision is what makes you use the template engine or not.
This is an old question, but I want add some insights.
You asked why you should use Volt, the Phalcon template engine, but in your explanation you want know, more generically, why you should use a template engine. The short answer to your question is: you must use a template engine to avoid mixing PHP with HTML.
But I want answer to the main question also. Why Volt? Volt overload is minimum compared to every other template engines out there and it's not because is written in C, but because it generates a unique PHP file for your view.
Twig is probably the most complete template engine out there. Twig has many more features compared to Volt, it's more stable and older. Twig, anyway, doesn't generate a unique PHP file, but a bunch of PHP classes with methods that call each others. Doesn't matter if you are using the Twig C Extension, Twig is gonna be slow anyway.
Twig is really really slow when compared to Volt and even to the good old Smarty. So, if you are using Phalcon is probably because you want achieve the best performances, serving a lot of page requests; in this case Volt is your friend.
When history of PHP starts, it was standard, that HTML was generated directly inside PHP scripts. But it happen to generate some problems when it grown to one of most popular ever web programming languages.
To keep people working in huge projects comfortable with their tasks ie. when developing web services, where was an MVC architectural pattern invented. M for Model is used to store data and handle them in a maintainable and repeatable manner. V for View as an part, that is responsible to generate proper output. C for Controller that are responsible for sending commands to models etc., being a core logic of application.
When user send a command to service, Controller is handling it and understanding. Triggering changes on proper Models and maybe forwarding actions to other Controllers as long as View Controller is reached. View controller takes a proper view, injects into it generated data and executes it to create output that is send back to user. If template for view is not yet generates, it triggers template engine to do it.
Proper implementation of full MVC greatly helps both programmers, system architects, front-end devs etc. But when on one side it happen difficult to maintain databases (so ORM were developed), on other side of system it was difficult to maintain views.
One of principles of MVC is that Logic (with huge "L") is only in controllers. So there is no logic in views. Using template engine enforces easiness of achieving that because of poor support of logic by them self. It is not a secret, that programmers are "lazy" - so if they have an occasion to put some more advanced logic into view, they would do it.
I guess that all frontend devs have programming skills. Problem is to make them stay with you. Working on huge project with lots of views (and so hudge templates) with PHP mixed into them will drive them crazy. It is much easier to read code written for template engine.
Idea of template engines is to add one more part to system, that offers possibly simple language allowing to use basic logic like loops and if statements. On one side template engine receives kind of a textual file to transform it into PHP file with mixed into it hyper dose of all important HTML.
If you are alone developer, it is important to nobody that you are using files that mixes PHP with HTML. It looks probably close to this:
<html>
<head>
<title><?=$title?></title>
<? foreach($metas as $meta) { ?>
<meta name="<?=$meta['name']?>" content="<?=$meta['content']?>"/>
<? } ?>
But any frontend developer would rather like to work on file looking this way:
<html>
<head>
<title>{{ title }}</title>
{% for meta in metas %}
<meta name="{{ meta.name }}" content="{{ meta.content }}" />
{% endfor %}
for it higher readability. It happens extremely handy when template includes some kind of javascript inlined. After all, you end up with same file you can create by hand, but this file is generated for you and stored, so it is no more generated as long, as core file is not changed. We are generating our templates during deploy what has 0 hit on performance, especially now, when Volt engine is written in C.
Another handy thing about template engines is that (with some your effort) it is possible to generate templates minified on the fly. You wont ever minify your hand-crafted template, except when planning to commit suicide.
So globally, it is a case of:
so you could pass .volt files to a front-end guy
but it is an effect of working in MVC pattern. And Phalcon is made to fulfill MVC principles. I'm not even trying to guess, how you managed to work with this piece of software for ~2.5 years not using template engine. Maybe you are working alone.
Every person has different taste, but i tell you my vision.
I think volt is useful because:
As all phalcon framework, Volt has excelent performance.
Benefits from template engines (i dont wanna repeat that already other answers says)
Hierarchical rendering: More info -> https://docs.phalconphp.com/en/3.0.2/reference/views.html#hierarchical-rendering
I love the phalcon hierarchical rendering, because is clean, easy, and any person can understand where can find the view of something, ideal for a designer, or other non technical person
And to add value, i modify some phalcon parts to apply that hierarchical rendering using app modules, thats all i need.
Wondering what would be better for SEO and a spider,
which is better for seo, a div with a style set to hidden or an title tag for a jquery tooltip
I am hesitant to put a div with a style set to hidden because a google spider might discard these types of divs and their content.
Thoughts?
-- Another note: Another option could be to find each div for the tooltip content and with jquery hide them on page load.
SEO is quite an elusive subject, as you may know. Meaning, you can not draw a conclusion by simply asserting hiding content is bad for SEO, while things that is informative to users are good for SEO, since at least Google claims so. One simple example is images, a good images is more informative than several lines of words, but Good simply can not get.
My experience of SEO is that when you do not know whether something is good for bad for SEO, you need to consider at least two elements. One, whether Google is smart enough to index it. Second, is it good for your end users.
Hiding one div is not so horrible in SEO wise, I did it for a long time (almost 2 years) and I have not experienced any negative result. I added a learn more button though, just FYI. I think giving your users an option to see the whole content should you decide to hide it, then it is not a big deal. A caveat however, this is just my opinion backed by my past experience, I can not guarantee it will be true in the future.
In terms of JQuery tool tip, I am not sure since I am barely use it. However, it is widely hold that Google still does not crawl JavaScript, you'd better give JQuery a second thought. If possible, Ajax is a good choice though, anyway it is another story. hope this helps
Title tags are useful ways of adding information about a link to the user. Therefore, this is also good for SEO, because Google likes pages that are informative to users.
Hiding information in hidden divs will probably be picked up by google, but might cost you penalty points, as hiding information is considered bad form in SEO..
So to answer your question, I'd go for the title tag.
I just came across few articles, while selecting a wiki for my personal site. I am confused, as i am setting a personal wiki for my personal projects, i think a flat file system is good, even to maintain revisions of the design documents, design decisions, and comments/feedbacks from peers.
But the internet gives a mixed bag of responses, mostly irrelevant information. Can anyone please shed some light on the selection. It will be nice if some can share his experience for a wiki selection for this personal/small business site.
You're asking more about Search Engine Optimization (SEO), which has nothing much to do with how you store your content in the server. Whether in static HTML or as a DB-driven application, search engines will still index your pages by trawling from link to link.
Some factors that do affect search engines' ability to index your site:
Over-dependency on Javascript to
drive dynamic content. If certain
blocks on information can't even be
rendered on the page without
invoking use of Javascript, it will
be a problem. Search engines
typically don't execute the JS on
your page. They just take the
content as-is.
Not making use of proper HTML tags
to represent varying classes of
data. A <h1> tag is given more
emphasis by search engines than a
<p> tag. Basically, you just need
to have a proper grasp of what HTML
element to tag your content with.
URLs. Strictly speaking, I don't
think having complicated dynamic
URLs represent a problem for search
engines. However, I've seen some
weird content management systems
that expose several different URL
mappings just to point to the same
content. It would be logical that
the search engines deem this same
content as separate pages, which can
dilute your ranking.
There are other factors. I suggest you look up on "accessible web content" as your Google search key.
As for flat files vs DB-driven content, think about how you're going to manage the system. At the end of the day, it's your own labor (or your subordinates'). I, for one, sure don't want to spend my time managing content manually. So, a convenient content management system is pretty much mandatory. I know that there are a couple of Wiki implementations that write directly to flat files. As long as the management part of it is good enough, I'm sure they'd be fine for your purposes.