As I see Smarty uses caching ‘by template’.
Can I somehow provide an URL to it, so it would cache pages by the URL given?
Can I get is_cached() to work with that given URL?
And compare last_mtime of the cached file with some of my data and then say «it’s time to update the cache»?
As default Smarty uses file based caching while storing php-like files in the $cache_dir.
You can implement a custom cache function and register it, but that depends on your desire how deep you want to dive into Smarty.
A way easier approach would be to just add a bit of the urls name to the template filename, so in your template directory for example might look like.
/your/templates/url1.index.tpl
/your/templates/url2.index.tpl
...and then use Smartys caching according to your needs.
Related
I am using Umbraco 7 and I need to achieve something which I am not entirely sure of the best way to approach it.
Basically I have vacancies on a website that have URLs currently such as this:
/vacancies/a/almighty-school/live/first-year-teacher/
What I want is for the URL to NOT show the /a and /live part (which are needed for structuring in the administration area), so basically the above URL would be:
/vacancies/almighty-school/first-year-teacher
I am not entirely sure of the best way of doing this, I know about URL Rewriting but am not sure if that could do this and if it could I really am not that clued up on the regular expressions needed to create it.
Any ideas anyone??
Add a property called umbracoUrlAlias, type Textstring, to your document type. Set the value to be "/vacancies/almighty-school/first-year-teacher".
This is a "magic string" that will then allow the document to be accessed via an alternate URL.
You could also set up a ContentService.Saving event to automatically set the value of this on the given node according to some preset rules.
I think the best way to tackle this is to create your own Segment Provider:
When the URL is build up, umbraco will convert every node into a segment. Each published Content has a url segment.
The documentation for manipulating these segments can be found here: http://our.umbraco.org/documentation/Reference/Request-Pipeline/outbound-pipeline
Is there another way to view the profiling results of MiniProfiler (I'm specifically interested in EF5 version)?
Every tutorial that I've seen uses MiniProfiler.RenderIncludes(); but since my MVC app mostly returns JSON, that is not an option for me.
Is there a way to write results to file or something like that?
You can read and write results to just about anywhere by changing the MiniProfiler.Settings.Storage to a different IStorage implementation from the default (which stores to http cache). If you wanted to, this could store to and read from a file pretty easily (you would have to write your own custom implementation for that).
The files served by RenderIncludes are the html templates for displaying the results and the script to retrieve the results from the server and render them on the client (all found here). But you are by no means obliged to use this mechanism. If you want to write your own logic for retrieving and displaying results, you should base this off of the logic found in MiniProfilerHandler.GetSingleProfilerResult. This function roughly performs the following (putting in the siginificant steps for your purposes):
Gets Id of next results to retrieve (through MiniProfiler.Settings.Storage.List())
Retrieves the actual results (MiniProfiler.Settings.Storage.Load(id))
Marks the results as viewed so that they wont be retrieved again (MiniProfiler.Settings.Storage.SetViewed(user, id))
Converts these to ResultsJson and returns it
With access to MiniProfiler.Settings.Storage, you should be able to retrieve, serve and consume the profile results in any way that you want. And if you are interested in using the RenderIncludes engine but want to mess around with the html/js being served, you can provide your own custom ui templates that will replace the default behavior.
I'm trying to cache my output. I'm using Codeigniter's built-in feature $this->output->cache() but it doesn't work. My guess is because I'm using twig. Any ideas?
I found the answer, may it be useful for whoever pass here.
$output = $this->twig->render('template.html'); // use render instead of display
$this->output->set_output($output); // use CI's output (autoloaded by default) manually
$this->output->cache(5); // cache for 5 minutes, doesn't matter where this line is in the function.
As you discovered yourself, you should map output to the Output class via one of the appropriate methods in order to take advantage of its built-in caching features. Note that CI 3.0 currently in development on Github has some updates that you may like (gzipped cache files that retain all output headers, for example).
You could extend the Loader library with a customized view() method, and perform the logic there as well, rather than needing 2+ lines in each controller (if you wanted to load multiple files, you'd have to call render() then append_output() every time).
I did exactly that with the Smarty template library. Should be able to do something similar with Twig. (I've been meaning to port it over as well, but haven't had the time.)
I'm about to start coding a website, and because this is my first time writing a code for a webpage, there is something I've been wondering about.
Writing separate header.php and footer.php is probably the fastest and easiet way to do stuff.
The problem is, what if for some pages I'd like to use specific javascript files and codes and for some I would like to use others?
It would result in more HTTP request and will eventually impact the performance of the site.
I thought about using if statements in the header and just give every page exactly what it needs, and nothing more.
But which way is more efficient?:
Coding global header.php and footer.php files and separating the codes using if statements OR add the whole header+footer code to every single file (ie local header/footer)?
P.S global and local header/footer is something I just made up, didn't really know how to call it, lol.
The advantage of your "global" header and footer is that 1) they are consistent and changes are "global" and 2) they are included in the pages in server code. So there isn't a lot of HTTP traffic if you do the include on the server side.
You can (and should) do page-specific includes on the server side if at all possible using logic that determines what to load at the time of the Request.
There are other ways to accomplish this but with straight up PHP, what you are considering is the best way.
If you are using a framework like Yii, you can do this sort of thing in layouts but with simple PHP, you are on the right track.
Defining the header and footer in each page (local), causes you to repeat a lot of code and causes maintenance headaches going forward. You have a lot of pages to update for simple header/footer changes.
In my application, I have both html and JSP files.
I need them both to pass through the controller.
But it is not possible to use multiple internalViewResolvers in an application . Chaining is not possible in the case of internalViewResolvers since even if specify the "Order" values, this will be ignored and this resolver will always come up last.
There are two options:
1)To use a ResourceBundleViewResolver and have a properties file explicitly mapping each of the request. This involves the overhead of reading from properties file.
2)Rename the html files as ".jsp" (i.e) though they are simple HTML pages rename it as .jsp to fix this. - This will involve the overhead of "JSP" to servlet conversion . Though pages does not have dynamic content, marking them as "JSP" seems an overhead for me
Please advise which is going to be a better solution.
Actually, you don't need to run both through the controller if the HTML files are static. If that is the case, you can use the mvs:resources tag to optimize retrievel. See my post on this topic. In your case, you would just add *.html to the resources list.
I wouldn't worry about the overhead. Neither of these options would take a lot of cpu or memory.
I would go with the second option as then you won't have to keep the resourcebundle updated when adding new html files.