How do I include a haml file in haml? - sinatra

How do I include a haml file in haml? It isn't described in the docs.
(This question talks about inserting parameterized templates but that isn't what I'm looking for.)
I'm using Sinatra but I should hope it doesn't matter.
Is inserting plain HTML any easier?

It seems that what you want is a layout template. I made this myself a while ago with sinatra and it is really handy. Put the common stuff you want in views/layout.haml - this will likely be a full HTML document with head and body and all the things that will be the same on a given page.
%head
-# some head tags here
%body
-# header menu here
= yield
-# a bit footer here
The yield part is where you want to have the things that differ between pages. (It uses the built in Ruby method yield to execute a block that has been passed in. If you are familiar with Ruby you know what that means - owtherwise don't think about it too much until you have something that works.)
Then in your sinatra code wher you call haml you just do as you normally do and sinatra will pick up the layout file for you.
haml :specific_page
If you want to be more specific about where your layout is you can pass in a named layout:
haml :specific_page, layout: :other_layout
and it will look for other_layout.haml instead of layout. You can also turn off layouting with:
haml :specific_page, layout: false
I think this it what you are after. It actually is in the sinatra docs but not in the section about haml. It works like this regardless of what templating engine you use.

Related

Which template system should I use in Typo3?

Up to now, I used to use template auto-parser. I like the fact I can modify any element of the template using typoscript, without altering the initial HTML file. I also like the fact that I can render the html template directly in a web browser, filling it with dummy elements to see examples of menus and content elements. Finally, with the new backend templates, i now can place content elements anywhere on a grid, in a way that mimics the real aspect of the website.
I know there is also TemplaVoila. I never took the time to learn it. My feeling is that it is less compatible with some extensions, but maybe I am wrong.
Now, there is fluid, that will be used in the next version of Typo3. While it is clear that it is better using it that using template markers, I don't really understand why I should be better using Fluid than using template auto-parser or TemplaVoila. What I dislike is the fact it requires to modify the html template with special tags, meaning that either the web designer has to know Fluid, or the Typo3 integrator has to modify templates from the designer each time a modification is performed.
My question is: should I migrate form template auto-parser to Fluid for my website template? What are the benefits of using Fluid? Why should it be better? What template system should I use with Typo3?
As long as TypoScript does not support objects, the benefits of FLUIDTEMPLATE over template auto-parser are only a few. So there is no need to migrate.
But IMHO there are some arguments to switch to fluid:
more and more extensions will use fluid, so it will help you to learn fluid
you can use an ide with code-completion for fluid (it is just XML!)
fluid is really powerfull, you can have f.e. if statements which checks for empty content
some day TypoScript will support objects as well
But for extension developement, it is totally different. In an Extension, i would allways prefere using FLUID. You do not have to deal with template things inside your extension anymore. Just pass the data to fluid and things which concern the view will be done in your template.
Whever you choose, it should be something based on Fluid - this will allow you to be extremely versatile and it makes the implementation less important than the template, which is quite good.
I myself am the creator of the "Fluid Powered TYPO3" framework (formerly known as FED) and would of course recommend that you take a look at what this framework can do for you - it's capable of great things, not the least of which is saving you a lot of time while at the same time allowing you to create even more consistent templating for pages and content - and even backend modules.
And we're always happy to help new users. We are currently in the process of improving our documentation, but you can already find many fully up-to-date guides on our Github page - https://github.com/FluidTYPO3 - the repository called "documentation" is the place we will store all the documentation.
You may want to have a look at http://fedext.net http://fluidtypo3.org - especially the "Tour of features" which tries to explain the point of Fluid Powered TYPO3 in as few words as possible. After that, the examples from the documentation will give you a much clearer picture of what Fluid Powered TYPO3 can do for you.
We focus on efficiency always - we've tried to do all the heavy lifting so that you really can just sit down and begin creating page templates. We took a lot of inspiration from TemplaVoila but there is no more re-mapping of content and things like this: when you change your templates, that change is immediately reflected, which makes it very nice to work with in iterations and do things like continuous delivery and -integration.
Hopefully this helps!
Cheers,
Claus aka. NamelessCoder
You could also argue, that adding special tags like
<f:section name="typo-content">
<div id="content">This is where the designer intended content to go</<div>
</f:section>
Could assist your designer while doing a redesign to know where you "mapped" your content elements to. This is neither the case with autoparser nor with TemplaVoila. So if the designer moves stuff around you probably get your templates back and they still work without any modifications.

Zend Framework contextually load stylesheets

Is it possible in Zend Framework to contextually autoload a stylesheet based on a unique identifier?
I'd like to load css based on the layout and the action name by first checking if the stylesheet exists then loading it.
Is that possible?
Yes it is possible and surprisingly simple to implement. I have just started trying this for myself in a small project I am working on.
See Andy Baird's blog on this, which also includes the code you need to get you started. He continues it in a second blog which takes the concept slightly further.
He uses the same technique for both CSS and javascript files, so you may want to try it with both too.

Node/Express/Mongo: How do I render HTML attributes from dynamic content?

I have made a simple blog using Node/Express/Mongo/Jade (and/or HAML.js). I used (and slightly updated) the blog app from this tutorial, which itself an update of one from howtonode.org
I can render attributes such as links, etc., with the template engine just fine, but when I pass data from the db, none of the html renders. I get plain text print-outs of the HTML. I figure I need some other node packages/modules to render the 'dynamic' content, but I don't know where to start.
In jade, when you're passing content you DON'T want to be escaped, be sure you pass it along as != instead of =
BE EXTREMELY CAREFUL THOUGH! If you don't manually parse out the bad stuff, you could make your website extremely vulnerable.
You can read some more jade documentation here

separate layout from templates in perl cgi::application

I am building a perl cgi::application using html::template.
I am using 7-8 different templates having the same layout - header, footer, left column etc.
How can I separate this html out of the template files into a single layout file. What perl modules do I need in addition to cgi::app and html::template.
Thanks
I agee that Template-Tookit is better.
If you absolutely have to use HTML::Template you can use the TMPL_INCLUDE directive. It'll search your defined template paths or you can specify a full path to another template. It'll process the variables in it as well.
You can create seperate template files for the header, footer and such and in your page templates just TMPL_INCLUDE them. It's less elegant and more repetative than Template Toolkit's WRAPPER (You'll have to TMPL_INCLUDE in each page several times for all shared elements) but it'll get the job done.
If you can, invest the time and use Template Toolkit.
I'd switch out HTML::Template for Template-Toolkit and make use of it's WRAPPER directive.
I don't know about Template-Toolkit. So i won't discuss about which solution is the most convenient.
I can just give you another solution, which is dependant of the server your running your cgi's on.
With Apache server, you can use includes in your html :
<!--#include virtual="/includes/header/header.htm"-->
you may call htm (static pages) as well as dynamic pages :
<!--#include virtual="/perl/includes/dynamic.pl"-->
but you have to do some apache tweaking. see Apache Tutorial: Introduction to Server Side Includes
Hope this will help, or at least give some ideas
Can the people who don't like HTML::Template please say why? While the Wrapper idea seems helpful to this particular poster, there's nothing wrong with the idea of includes: they're more flexible, and many web developers will already be familiar with the concept from non-dynamic publishing.

Tool to diff webpage semantic structure rather than content

Does anyone know of any tools that allow diff'ing between two web pages semantic markup rather than content?
Cheers.
No, but you might have more success if you break it down into two steps:
Remove content
Diff
You could try using Pretty Diff tool. It would require a minor customization to the markup beautification component so that content components are set to empty strings.
Look at http://prettydiff.com/markup_beauty.js
Change lines 554, 557, and 560 to:
build.push("know text");
These change would actually need to occur in the larger prettydiff.com/prettydiff.js, but now you know where to look. Once done you can run all this off your local.
All you will need is:
HTML of http://prettydiff.com/
prettydiff.com/diffview.css
prettydiff.com/pd.js - this is the DOM interface between the application and the HTML
prettydiff.com/prettydiff.js - this is the actual application code.
I may write this concept of ignoring content into the tool as an option.