I have been researching online but can't really figure out the best way to integrate a less or sass compiler into a zend 2 environment.
I have visited few pages but it is not clear step by step.
I am not aware of which package to download and how to make it useful.
Can anyone help please?
Are you sure you need a real integration?
These days, I just use something like gulp to compile/concat/minify front-end assets and dump them into my webroot.
In a typical ZF2 project, you'd end up with a structure like:
MyProject/
MyProject/src
MyProject/view
MyProject/public/css
MyProject/public/js
MyProject/frontend/sass
MyProject/frontend/js
MyProject/bower_components
src, view and public are your typical top-level directories.
frontend holds your sources, which gulp processes, dropping artifacts like public/css/styles.css.
bower_components assumes you're using bower to manage frontend dependencies.
None of the above really cares that it's associated with a ZF2 project; it's completely orthogonal, but lives along side the PHP stuff in your VCS repository.
Related
Thanks for your attention, this is a question of organization, I work with PHP and GIT for version control. I use Netbeans IDE to program, GIT integrated (although I am still a rookie).
Normally, I follow the approach that Symfony2 specifies for organize the project files, but I use my own framework for my projects.
The (main) question is: Any component or code part which has its own version control must be located under the /vendor/directory?
For example:
I have my project files in src\Acme\ProjectX\, also the utility package which use all my projects: src\Acme\Util\, and it is under the version control too (GIT).
and now let's remember the basic skeleton of a project based on Symfony or similar:
/app (application related elements)
/src (source code of the project)
/vendor (third party libraries)
/web (front end controller, the web directory, assets resources etc...)
So, Must be 'Acme\Util' included in the vendor directory? And, is necessary to use composer to declare the dependences?
In addition, the Utility package has a lot of classes but only few are used in projects. Must I remove those are not using by the project.
Summarizing, It will be nice if someone can contribute his knowledge for help me to represent an scenario like this.
I hope I could explained...
Thanks in advance!
Vendor directory
It's a good practice to separate external dependencies and the application code. If you are using Composer you can change it to something else.
Unused classes
Unused classes shouldn't matter if they aren't being loaded. They'll just take a bit of extra disc space.
It might be a good idea to separate the Utility package into multiple packages if you find yourself frequently using only a small part of it.
Dependency managers
It isn't necessary to use a dependency manager, but it sure does help. Having to install, configure and maintain everything manually (especially with many dependencies and sub-dependencies) would be a horror.
I am working on an application that was built in Zend framework 1. I want to install simpleSAMLphp as a service provider for it and trying to figure how best to do this.
I'm considering a couple of options:
Install it outside the application
(e.g. /var/www/myapp/simplesamlphp where my app's files are at /var/www/myapp/simplesamlphp). This is how it seems it's done in the installation tutorials. I guess this would work with some adjustments to the autoloading so it can pickup the SimpleSamlphp classes. I'm using composer to install dependencies so I can perhaps add the SimpleSAML folder to the class tree - not tried this yet. Or should I use the SimpleSAMLphp autoload file?
simplesamlphp-composer
I sees there is an option install with composer? So, if so, it will go within my application folder and files. However, I've tried this and not sure how to get composer to pick up the SimpleSAML classes. Anyone had much use of this method? I tried doing composer dump-autoload but it didn't add them. I guess I need to do more.
Can anyone give me some advice on how to use simpleSAMLphp with ZF1. Even just a point in the correct direction regarding where best to put files. We want to role this installation out to all our websites eventually so something that is easy to setup would be best I guess. I do like the composer approach but didn't have much luck with it. Previously the project used CAS with a phpCAS client - that was installed using composer which was quite convenient.
Any help would be much appreciated, thanks
I used ZF 1 and had following structure
/lib/Zend/ -- ZF
/lib/Zend.php
/lib/MyCompany/ -- my classes that supports ZF autolaod
/lib/ANyOtherZFCompatible
/lib/external/ -- any other libs that don't support ZF convention
I would put SimpleSAML into /lib/external/simpleSAML/
and at the beginning of your main file
require_once('/lib/external/simpleSAML/lib/_autoload.php'); and try to use init some SAML classes.
I'm wondering what the best way (if there is a way) for an application to auto-discover [relevant] PHP "packages" installed by Composer.
My use case specific scenario:
I have a PHP app that includes my "framework" (for lack of a better word). This framework brings some basic functionality (routing, admin etc).
I'm slowly building in more advanced functionality, say, a blog module. This module is entirely self contained in it's own directory (but obviously has dependencies on the framework).
I'd like this blog module to be a self contained Composer package, so that I can selectively require the package in my app's root composer.json file.
Now, I need for the framework to know that it's there so that it can, for example, set the routing correctly and load up any admin functionality that the module requires.
What I've thought so far:
I'm relatively experienced in PHP, but "proper" OOP and autoloading is a little bit beyond my knowledge at the moment, so please forgive if there are inbuilt functions to do this. I don't even know what terms to Google!
I have thought I could maybe read the installed.json file which composer puts at vendor/composer/installed.php but I'm not sure how to set up my packages (e.g. blog) so they announce what they are. I'd like to future proof it so that I'm not looking for known module names (or regexing vendor or package names), but rather looking for packages to say "hey framework, I know you! You can use me!"
Maybe I can somehow instruct Composer (through the package's composer.json file) to stick in an arbitrary key/value pair in installed.json?
Any suggestions welcome, or directions as to what sort of Googling I should be doing.
Oh welcome to the world of managing dependencies on your framework.
I have some experience with auraphp, where we dealt with similar issue. You can read the blog post Composer-Assisted Two-Stage Configuration .
So what we finally ended-up adding https://github.com/auraphp/Aura.Web/blob/a3870d1a16ecd3ab6c4807165ac5196384da62cd/composer.json#L26-L36 these lines in the packages that need to understand to load by the framework.
You can also see how this bundle can also get autoloaded with the configurations.
in your composer.json
https://github.com/harikt/Aura.Asset_Bundle/blob/6ea787979390e69bf6ecb1e33ce00ed90f306e2f/composer.json#L21-L27
and the config/Common.php ( https://github.com/harikt/Aura.Asset_Bundle/blob/223126cedb460e486c4f0b242719c96c14be5385/config/Common.php ) , note we have other development modes also. For a detailed look check https://github.com/auraphp/Aura.Web_Project or https://github.com/auraphp/Aura.Framework_Project
Hope that helps a bit to look into the code and work on your own solution.
i'm building a new project on top of CodeIgniter MVC framework, but now that i'm looking at the design, i will actually not use most of the framework features except for 1.form validation, 2.router and 3.session/cookie/input handling, and 4.views generation
even for database i will use Redbeans php ORM.
So my question
how can i glue these components that i fetched with composer from other frameworks so i can inject them into my project and be good to go without other extra stuff that i don't need ?
would it be a wise decision ? or is there any risks of depending on components rather than whole framework ?
i have googled a lot but it seems like i'm using the wrong keywords or something, i could not find any tutorial except for this one -which dictate symphony- that teach you how to do this and what are the risks of doing it
You can take a look at Packagist to explore which components Composer offers, RedBeanDB is definitely in there. However, in contrast to Symfony, CodeIgniter is not really Composer-friendly. So if you are looking for a proper way to just load these few CodeIgniter components as a dependency, I guess you're out of luck.
To keep from digressing, I'm simply going to answer your two main questions:
1) There are plenty of tutorials out there on how to use composer to grab your packages, so I wont do a full writeup, but basically what you need to do is download composer, create a composer.json file, then run composer to have it download all those packages and their dependancies. All you then need to do is in one of the already loaded codeigniter files, autoload the autoload.php file
`require 'vendor/autoload.php';`
Check the composer documentation here on how to download composer and setup your json file.
2) Definitely. The Laravel framework is actually built this way under the hood, instead of writing everything themselves, they use composer to pull in packages from other projects like Symfony to do certain tasks.
TL;DR: what is the best way to arrange files, package managers and build tools for Laravel 4 + Zurb Foundation 5 combo (with Compass) as one consistent repository with clean public (static) section?
I wanted to start a fresh project, based on latest Laravel on the backend side and using Foundation for the frontend. I am new to both of these and apparently I missed some of the tooling that was developed meanwhile when I wasn't doing PHP for some time.
My confusion:
Laravel uses Composer for installation and dependency/module management. (Ok, I'm new to Composer)
Foundation is available as a Composer module (but then what?), but generally also as a CLI tool that creates a new project and uses bower for module/dependency management. But then I have two repositories.
Is it required for me to expose all my .scss files, or maybe even put the whole Foundation project into laravel's public dir to make all work?
How do people usually approach using these frameworks together? They shouldn't interfere, but they still have totally different tooling.
Where do I put my foundation files? Keep it as composer module or inside public? How to refer to them? How to have one build everything command?
I have the same issue as using Bootstrap SCSS version for Admin & Foundation SCSS for the frontend. I noticed also that both css frameworks come as composer packages however the issue you have with this approach is that you generally use other Javascript files in a development that will be merged also so using the composer versions just adds to the confusion.
The best solution i found was using either gulp or grunt with bower at the top level of your Laravel build. Rather that go through the configuration for you there is a good article at http://blog.elenakolevska.com/using-grunt-with-laravel-and-bootstrap/ that goes over a bootstrap integration but this can be tweaked for Foundation. This solution is good as grunt has many of the other popular javascript libraries that you may use in your project also..
Alternatively you could use an application like codekit and create a compass project to manage the merging & compiling of your assets into the public folder. As a side note if using git again your would need to exclude additional folders from your project.
If you think of your SCSS framework files as development assets there is no real need for them to be in the project as you only really need one version of Foundation on your development machine.
Your custom SCSS changes can be added to your Laravel project as modules ie a navigation module, via a private composer repo for the project or just added to the Compass project at development time. Your public folder should only be referencing the final merged style.css & java.js files for example. Any images from the framework can then just be copied over to the public folder ie icons etc.. Hope that helps..
Personally I have a "static" directory which houses static files. That is where I use SASS watchers, grunt tasks and basically the entire front-end workflow. The results of that front-end build process gets added to a "production" Laravel public directory after getting built, etc.
A pro of this is that everything (static assets and laravel application) is separate.
A con is that updating Laravel views with any updates in HTML templates you may build in the static directory. If you update the templates, you may also need to update the view files, which becomes more tedious as you add more templating logic around the HTML in the views.
Just one suggestion.