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.
Related
What is to be understood by "Fluid powered TYPO3" (as stated by http://fedext.net/) and what are its benefits for the integration?
Are there other modern templating approaches for TYPO3 6.x that would be best practice to switch to now?
I don't understand the different systems that are around at the moment and I need some clarification.
The background of the question, what I am looking for:
Don't use Templavoila
Keep it simple, little coding overhead
That's why I still use markers!
Enable Custom content items in the backend like FCEs in TV
Foment "structured content" approach in TYPO3: predefined inputs and detailed rendering vs. "Anything goes" like in css_styled_content
And what about https://github.com/Ecodev/bootstrap_package ? Is it recommendable?
Although this question is fairly old by now (I didn't see it until now) and you probably already found out more about what Fluid Powered TYPO3 offers:
The features you ask for (TV-style FCEs, low coding overhead and especially the last one which is more regarding the process than the tool) are exactly what Fluid Powered TYPO3 is all about:
We provide simple ways to get page and content templates recognised by TYPO3 and made available to use by the site's content editors.
We use a common API approach (which is built on top of TYPO3's TCA/TCEforms) which you can use in both page and content templates to add custom fields (as an example: create a field to set the color of the site's header or configure a content element to have a blue background, and so on).
We use Fluid which is (as Michael already stated) a superb rendering engine.
But this is just a small part of the possibilities you have with the extensions (currently there are 20 - no, really, 20) which all provide different feature sets: there's the ViewHelper library VHS which you can use with any type of Fluid template, there's fluidpages, fluidcontent and fluidbackend which lets you place template files in a recognised path and made available to use without further hassle, there's view which lets you use overlay paths for plugin templateRootPaths (example: override only one template file from EXT:news without having to copy all template files from EXT:news). There's builder which can generate extensions, ViewHelper unit test classes, test your Fluid templates and more. There's tool which contains a range of Extbase Service-type classes that you can use in your own Extbase plugins. There's fluidwidget which is a great base for complex Fluid Widgets. You've got side utilities like *extbase_realurl* which can generate automatic realurl rules for any Extbase plugin. And there's schemaker which can let you create your own XSD schemas for your own ViewHelpers (or any version of for example fluid itself, or VHS, or flux etc.).
And there is more than this. Simply put, we offer you every tool you need to create every type of site, template or plugin. Our tools have one primary focus: efficiency.
It sounds like a huge mouthful but it isn't as complicated as it seems. Usually you will start off by using three or four of the extensions and their purpose is quite clear: Flux allows you to add the form fields which content editors use to configure content, pages and plugin instances; VHS provides a large number of multipurpose VieWHelpers to use whenever you need more than just those included with Fluid. And then one or both of fluidcontent and fluidpages which are -very- simple in that all they do is allow you to use template files as content elements or page templates.
There is quite a bit to get used to - this is true of any framework - but we spent a lot of effort on making the API the same across the line, which means anything you learn in one context (for example page templates) you can use in others (like content templates and backend modules).
If you want to save time and be consistent when creating content, pages and plugins, Fluid Powered TYPO3 (which is the umbrella name for all those twenty-something extensions) will do exactly that for you.
I can recommend taking a few minutes to read the new tour I published on fedext.net - the URL is http://fedext.net/tour/form-api.html - it primarily speaks to developers who've touched on Extbase and Fluid earlier, but even if you're used to "just" working with TYPO3 the main points should make sense.
And if you need more details than this you are welcome to find us on Github or on IRC (#typo3 on Freenet). We're always happy to help new users.
Cheers,
Claus aka. NamelessCoder
Fluid offers a much cleaner approach of dividing template logic from display logic and controller logic. Your result will be structured much better when using the possibilities fluid and the mentioned extensions like vhs provide (like layouts and partials).
The usage is actually very simple but can still be combined with the oldschool marker approach (you can do things like <f:cObject typoscriptObjectPath="lib.marks.MAIN-MENU"/>). If you need more flexibility in the backend like in TV, you (of course) have to code some things yourself.
The easiest way is to use an extension which is created by modelling it in the backend to fit your custom needs, but you can also adjust the rendering of pages and/or default content elements by using typoscript and the fields given (like pages.layout, header_layout, section_frame and so on).
So you always have the choice between detailed inputs (extbase extension objects) and using the TYPO3 default things like page properties and RTE config in combination with some typoscript magic (css_styled_content).
So as a conclusion I strongly recommend using fluid templates and additional extensions like vhs as they provide a lot of (additional) power and reusable templates while still let you use markers if you want to. Personally, I also prefer to enhance or limit the RTE in the backend in favor of writing too much special code for an FCE-like result.
BTW: There are very good autocomplete features by using the DTDs/XSDs from fedext.net in your IDE which made my template programming much faster (like 25%).
Right now, I am using <%- assets.js() %> to include all the javascript files on all pages. So, it means all the functions will be initialized on all pages.
I am wondering how can I disable a javascript file on a specific web page? Or, if there is a way to include some of the javascript files on a specific web page but not all the javascript files.
The trouble with the auto-loading is that it's really hard to dictate the ordering of the source files in any meaningful way-- it really comes down to how you've structured the front-end.
In v0.8.x (the version you're working with, from what I can tell), you can use the config/assets.js to control the ordering of folders that get loaded in. This is not ideal, but is a decent workaround that my team used on several projects.
In v0.9, we've removed rigging/asset-rack in favor of tight integration Grunt, which has a large community and some really cool and well maintained packages for most types of asset bundling, etc.
In any case, here are the different approaches you can investigate for serving assets in the new version of Sails.js:
Treat it just like anything else
In your layout.ejs file, create <link /> and <script></script> tags to link in your css and javascript files like you would normally.
Use AMD (Require.JS)
I think lots of folks would say this is actually the best option. Require is a pretty powerful tool. And I'm mostly in agreement-- if you're working with front-end javascript that could be coming from anywhere, and is going to be extended by other developers who may be using a different framework, AMD is a great way to make sure you stay safe. If you're using Require, each js file is its own module, and declares its own dependencies, so asset dependency management becomes a thing of the past. Then in production mode, there are a couple of different options to compile and minify your CSS and JS. You can even dynamically load templates and CSS from JS with Require, which is pretty neat. AMD/RequireJS is a hands-down winner if you're interested in loading some or all of your assets asynchronously. It's also an all-client-side solution, which is pretty cool.
The only downside in my mind is the complexity. If you have control over the framework being used, you really shouldn't have to manually enter dependencies for each file-- it can figure that out itself (see https://github.com/balderdashy/mast/blob/2.x/lib/raise.js)
Use Grunt
When you make a new project with sails new foo in Sails v0.9, a file called Gruntfile.js is created. It has lots of stuff in it, a lot of which isn't being used by default. You can do almost anything with Grunt, but in particular, you'll want to look at how it's set up to copy files from assets/* to .tmp/public/.
sails new foo --linker (Sails v0.9 only)
Linker is a lot like what asset-rack/rigging does currently. It creates the same Gruntfile as #3 above, but utilizes more of the contents. It will auto-link files in the order you specify. Instead of view partials (e.g. <%= %>), the scriptlinker plugin allows you to customize the delimiters where js, css, and templates will be injected. By default, the Gruntfile is set up to use JST precompiled templates, but again, you can set it up however you like.
Hope that helps guys, and best of luck!
-Mike
PS- v0.9 is coming out very very soon, I've just been working through tests and issues to make sure we're 100% there. If you'd like to try it out, check out:
https://gist.github.com/mikermcneil/5930330
The lead for Sailsjs replied to this issue (though it was about selecting CSS files):
"For now, you can (a) bring in all styles all the time and make only the relevant ones apply (b) use another tool (like Grunt) to bundle assets like you would in a vanilla node.js project or (c) link the stylesheets manually (put them in your public folder)."
See: choosing assets sailsjs
Similar, more complex questions have been asked in the Google group:
https://groups.google.com/forum/#!topic/sailsjs/yt9EpJlfzXA
Considering the above, you may want to have a separate layout.ejs for each page. You can specify the layout.ejs you want for each page with
res.view({ layout: "different_layout" })
The layout.ejs would (a) not call assets.js() but have < script > for all the js files needed, or (b) call assets.js() to serve all the common js files in ./assets/js plus < script > to serve the page dependant ones residing elsewhere.
I have a wrapper around assets.js() that allows you to include all assets except for specified files. You can also use it to include only specific assets elsewhere. So you could load your common assets in layout and include other assets only on pages where they are required.
See my answer to How can I include javascript assets selectively in SailsJS?
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.
Now that I can navigate a Web page via WWW::Mechanize and get information via HTML::TreeBuilder::XPath by accessing an id, I am left using Firebug to read the DOM in order to discover the layout of the HTML tree. The content that Mechanize captures is unstructured HTML, not good for human eyes.
Is using Firebug to ascertain the id I am after a typical approach? Once I get the id then I'm good to go, it's just that I've got several ids and pages with more ids to chase down and I was hoping to get (dump, print, etc.) a formatted layout of the DOM in order to make that discovery easier. Though granted, Firebug makes it pretty easy, too. I'm just wondering if I am missing an easier method.
Crossposted at PerlMonks.
If you need text, xmllint --html --format (comes with libxml2) does a decent job.
If you want a tree and mess with it and test out various expressions in a GUI, then Xacobeo is your new best friend.
Note: since both those tools rely on libxml, replace HTML::TreeBuilder::XPath with HTML::TreeBuilder::LibXML for compatibility. Evaluating XPath will be faster that way, too.
If you know Javascript/JQuery, then also install FireQuery. You can then test out CSS expressions in FireBug, and use them with modules that select HTML through CSS expressions, e.g. Web::Query.
I use XML Developer from Oxygen IDE for my recent development on XPath:
http://www.oxygenxml.com/download.html
It is a 30-day trial type of tool, but you can also search for XPath visualizer
It doesn't visualize a tree for you as far as I know (maybe there's a panel doing that). But it gives you some smart complete functionally that helps you to know what nodes you have available at any point. It is pretty big for XPath because it is hard to know where the parser pivot is really pointing at.
I was wondering what is the best practice for creating forms in Wordpress? As a developer I hesitate to use a plugin like CForms, but I can understand why someone would like to use it. In the end I want to know the following:
What is the best practice for creating forms in Wordpress? (Custom HTML/CSS with Javascript and PHP validation or just using a specific aspect of the Wordpress API?)
I don't use any part of the WordPress API for forms. You could automatically grab the name and e-mail address out of the cookie WordPress creates when someone leaves a comment, if you want to try to auto-populate some fields.
An easy way to handle forms is to use Page Templates. That lets you create a new PHP file for a specific page, overriding the default page template of the theme. Then you can simply have the form post to itself and this one page template handles the processing as well.
http://codex.wordpress.org/Pages#Page_Templates
A lot of what's available for WordPress in the way of addins, and what gets a lot of attention, is stuff that I find makes little use if you have programming and general web skills. Almost always they seem to (necessarily) overgeneralize a requirement with a zillion options and configuration requirements because they are first of all designed for non- or barely-programmers.
Just learn the fundamental paradigms, scratch your head and wonder why nothing is consistently abstracted and/or encapsulated, get over it, and use what you already know about php and HTML-based forms. WordPress doesn't add much in the way of either tools or constraints.
I find the Widget feature applies usefully to most everything these days, and Forms is a candidate. But that's my own WordPress viewing prism - YMMV.
What do you mean by "in Wordpress"? Do you just mean placing the form HTML in a Wordpress template? Or storing data collected in the Wordpress DB? If you just want to create a form on your site, there's nothing Wordpress-specific to worry about. I believe there's some special Wordpress data facilities you can use if you're creating a widget or plugin or whatever they're called now. But if you're not, just create the HTML, and point it at a target URL that processes the values and puts them in a DB, Wordpress or otherwise. That target URL could be a separate PHP resource, or the same page. If it's the same page, you just need to include your PHP somewhere in the main Wordpress flow.