I have a project that uses Smarty template engine (2.6). Point is I can't have it save files locally as it would mean saving to the repository. Same with cache.
My question is - how should I implement compiling templates to, for example, memcache?
I was playing with stream wrapper for it but maybe someone has a better solution?
Every repository system has means of excluding files from tracking. Which you have to use, instead of reinventing a square wheel
I don't think this is necessary. Smarty templates are compiled to PHP files and on runtime these PHP files are included, just like native PHP scripts. You can think of caching PHP scripts with APC or similar.
You can pre-compile the templates and ship them as a part of your application as read-only files. Thus it is not a decent solution it will work on such hosting environment.
If you are using Google App Engine with PHP you can use the cloud base storage as a stream with Smarty 3 to store all your files there.
Related
I'm creating an app in Phalcon which contains a theme manager. A theme is nothing more that a collection of .scss and .volt files. Naturally, these .scss are built before being used.
I'm been testing Phalcon's assets manager. Apart from some difficulties creating custom filters, etc, I started wondering: why would someone build their files all the time? This would make each request much slower. Does Phalcon cache these assets?
Furthermore, when developing themes or doing a lot of frontend work it is useful to watch the source sass files for changes. Is this possible in Phalcon?
According to manual using ->setTargetPath() on assets collection makes it possible to save all selected files into one location. If you have some scripts you always include to your page, you can marge them to one file, and meantime minify thanks to filters filters. Code snipped would be somewhat like that:
$controller->assets->collection('jsGlobal')
->addJs('libs/jquery.js', true)
->addJs('libs/jquery-ui.js', true)
->setTargetPath('js/global.js')
->setTargetUri('js/global.js')
->join(true)
->addFilter(new \Phalcon\Assets\Filters\Jsmin());
You may want to check if script it already built under that js/global.js location to prevent from building it over and over again on production. This way, when making your deploy script you can just implement deletion of certain files on your production server.
Projects I'm working on uses less. We installed \lessc library to manage to keep in repository only .less files.
And again, in development mode we're not even checking if file was changed - we assume is was and are recompiling it just always. For production purposes, PHP is written to check if certain scripts does exist and is compiling .less only if they dont.
All the tutorials on optimizing website assets with grunt and grunt-usemin are based on the src -> dist deploy strategy. basically processing the items in your src folder and compiles them into the dist folder.
But PHP doesn't work this way. It isn't compiled and "distributed". The source and target page are the same. Which makes it a destructive process.
How do you work around this? Any tips on using Grunt in PHP project in general?
Thx.
We do something similar. We created an index.src.html with the non-minized sources, and create an index.html from this file using usemin, and we have a "proxy" php file which opens the index.html if it exists (which means we are in the production environment and the assets are built), otherwise the index.src.html if the assets haven't been built or we are in a development environment. The main idea is to separate the important parts for usemin to a different file.
The usermin plugin is for preparing static assets (concatenate, minimise,...). Static means the server gives the same content for everybody. This constraint doesn't apply to PHP...
If you would like to use this tools to optimize your php generated pages assets, you should create input files which can be parse-able by usermin. For example you can collect the javascript/css file references into a template or a different php/html, and you include/use this file where you need, and after the build you use the usermin parsed version of it.
The ideal approach would take advantage of the dynamic nature of PHP to make the "distribution" URL replacement. The process would be:
Your build tool creates some kind of manifest or machine readable file with changes applied. Some tools, as gulp-rev will do this for you.
Read the manifest from PHP and replace the resource URLs with the final ones.
I've been looking at Twig (http://twig.sensiolabs.org/). I've been wanting to make a simple open source calendar program that I can distribute (has a mini installer etc). Smarty (another template engine) wants you to install it in a non web-accessible directory for security. The only thing is I'd think that would make my installer really complicated if not impossible. Does twig require you to place its main files outside the webroot, or can I place it anywhere?
Neither Smarty nor Twig require you to store them anywhere specific. Both are recommended to be stored outside the doc-root for security reasons. not more. not less.
I am building a Flash, jQuery, and PHP based project which I would like to subversion from the get go. I have experience using Dreamweaver CS5's sub versioning capabilities. So, as far as the PHP and jQuery (the non-flash portion) goes, I'm pretty comfortable.
However, I would like some recommendations on how to subversion the Flash portion. I know Flash Builder has SVN capabilities, however, the flash portion isn't going to function as and RIA, but more, if you will, like a game. As far as my experience with Flash goes, this type of project will work best if done in Flash Professional. Here are the options, as I see them:
find an extension for Flash Professional which will enable SVN. Is there one???
create a "Flash Professional Project" in Flash Builder, built it in Flash Professional, and subversion with Flash Builder.
place my project within a defined site in Dreamweaver, and subversion from Dreamweaver.
I would like to avoid something like Tortoise SVN, as I have had more difficulty with that than I am up for for now. :)
Does anyone have any suggestions, or pointers as to how I can handle this?
Thank you for your time.
Well, any SVN client can handle any kind of file - you don't have to have an extension built into each piece of software you're using. The best way to do this is to put all of your project files into a folder somewhere and then using whatever SVN client you want just add that whole folder to your repo. Does that make sense? The front-end that you're using is more or less irrelevant.
I don't really understand what you are saying about TortoiseSVN, but since you are using different IDE's I would recommend you to use TortoiseSVN as the uniform interface to SVN. And IMO, TortoiseSVN is simple and powerful.
Man up and use the command line ;). Why SVN? Yes, I personally prefer it but there are other great alternatives, have a think about GIT, Mercurial and others too. Mercurial/Git have massive benefits for single developer projects. The flash file will be versioned just like everything else in there. Remember to set your ignore files appropriately to cut out all the os specific poop.
Soon as you get yourself a good versioning repository set up, it doesn't really matter what client you use. I like the one bundled with netbeans / versions or the cli.
I have a folder of PHP scripts, they are mostly utility scripts. How to share those scripts among different PHP applications so that reuse and deployment are easy?
I would have to package my app into an installer, and let the user install it.
I could put the lib and hardcode the include path, but that means I haven to change the PHP code every time i deploy the web application to a new customer. This is not desirable.
Another route I consider is to copy the lib to other apps, but still, since the lib is constantly updating, that means that I need to constantly do the copying, and this will introduce a lot of problems. I want an automated way to do this.
Edit: Some of the applications are Symfony, some are not.
You could create a PEAR package.
See Easy PEAR Package Creation for more information on how to do this.
This assumes that when you say anyone, you mean outside your immediate organisation.
Updated: You do not need to upload to a website to install the PEAR package. Just extract your archive into the pear folder to use in a PHP application.
Added: Why not create a new SVN repository for your library? Lets say you create a library called FOO. Inside the repostory you could use the folder heirachy of trunk\lib\foo. Your modules could then go into trunk\lib\foo\modules and have a file called trunk\lib\foo\libfoo.php. Now libfoo.php can include once or require once all the modules as required.
PHP now supports Phar archives. There's full documentation on php.net.
There's a complete tutorial on IBM website as well.
One neat thing you can do with Phar archives is package an entire application and distribute it that way.
http://php.net/phar
http://www.ibm.com/developerworks/opensource/library/os-php-5.3new4/index.html
Ahh, libraries...
There are two conflicting purposes here:
Sanity when updating scripts (ie. not breaking 10 other apps).
Keeping things in one organized logical place for developer efficiency.
I suggest you take a close look at git and git submodules
We use git submodules extensively for this very purpose. It allows the best of both worlds because shared scripts can be upgraded at will in any project, and then that change can be moved to the other projects (deliberately) when you have time to do so and test correctly.
Of course, you need to be using git to take advantage of submodules, but if you are not using git, and you start, you'll eventually wonder how you ever lived without it.
Edit: Since the original poster is using svn, consider using SVN Externals.
UPDATED:
you just have to put the lib in some place reachable by your apps (in a place where you can reach it via http or ftp or https or something else) and include it.
If you have to update it often you can package your library in a single phar file and you can then provide your client a function to pull the library from some remote path and update a parameter in their local configuration accordingly, like:
function updateLocalLibary(){
//read the remote library in a variable
$file= file_get_content($remoteLibraryRepository.$libraryPharFile);
//give it a unique name
$newLibraryName=$libraryPharFile."_".date('Ymdhsi');
//store the library it on a local file
file_put_content($localLibraryPath.$newLibraryName,$file);
//update the configuration, letting your app point to the new library
updateLatestLibraryPathInConfig($newLibraryName);
//possibly delete the old lib
}
In your include path then you don't have necesasrily to hardcode a path, you can include a parameter based on your config, like:
include( getLatestLibraryPathFromConfig() )
(you are responsible to secure the retrieval in order to let only your clients see the library)
Your conf can be in a db, so that when you call updateLibraryPathInConfig() you can perform an atomical operation and you are sure not to have client read dirty data.
The clients can then update their library as needed. They may even schedule regular updates.
There are a lot of options:
tar + ftp/scp
PEAR (see above #Wayne)
SVN
rsync
NFS
I recommend to use a continuous integration software (Atlassian Bamboo, CruiseControl); check out your repository, build a package, and then use rsync. Automatically.
You should also look into using namespace in order to avoid conflicts with other libraries you might use. pear is probably a good idea for the delivery method, however, you can just place it in the standard path /usr/share/php/, or any other place that is set as the include path in your php settings file.
Good question, and probably one that doesn't have a definite answer. You can basically pick between two different strategies for distributing your code: Either you put commonly used code in one place and let individual applications load from the same shared place, or you use a source-control-system to synchronise between local copies. They aren't mutually exclusive, so you'll often see both patterns in use at the same time.
Using the file system to share code
You can layer the include_path to create varying scopes of inclusion. The most obvious application of this pattern is a globally maintained PEAR repository and a local application. If your it-system consists of multiple applications that share a common set of libraries, you can add a layer in between these (a framework layer). If you structure the include_path such that the local paths come before the global paths, you can use this to make local overrides of files. This is a rather crude way to extend code, since it works per-file, but it can be useful in some cases.
Use source-control
Another strategy is to make a lot of local checkouts of a single shared repository. Some benefits over the layered-include-pattern is that you can make more fine grained local changes. It can be a bit of a challenge to manage the separation between application layers (infrastructure, framework, application). svn:externals can work, but has some limitations. It's also slightly more complicated to propagate global changes to all applications. An automated deployment process can help with that.