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.
Related
I have my own Admin Bundle which is being developed in time. I just put it into new project and use it. If I need a new functionality I add it and use it later in another project. I put it in src/ directory. I don't want to store in on public Git repository.
Now as Symfony 4 is bundle-less, how should I easly put it into src/ dir so that it is decoupled from other App code?
I would like to develop the App as I shoulg but I would like to have an opportunity to easly copy Admin code to use it for another project.
Bundles are still perfectly available and useful in Symfony 4. They aren't suggested to be used for the main program code, as it is a little easier to not need that structure.
3rd party bundles are still incredibly useful though, to easily connect functionality, templates and services to an application. Equally, if you have some code that can be used in multiple applications and most easily added as a bundle, you are perfectly able to write your code as its own bundle. You can initially write it within your src/ directory, and then migrate it out to be an external bundle/library that can be pulled in via Composer when it's useful to do so.
First case: i've got some script, which i've writed by myself(lets call it requests.js).
Second case: there is a big plugin TinyMCE, which i can install from bower or npm.
In first case as far as i understand, i should save my scripts in resources/assets/js. But where should i call them after this? There are 2 files in assets/js, which were installed with Laravel 5.3: app.js and bootstrap.js. Should i call my scripts in these files and then gulp them into a single one?
In second case i should use some npm or bower package manager. But, what should i do next? Where should i call this installed packages?In assets/js/ - app.js or bootstrap.js? But how, or maybe i shouldn't do it?
It's hard to put bower components in resource/assets/js only, because these components often consist of many files, js/css/others. I just use bower install inside root of the installation, bower_components dir appears and I put it into .gitignore. Anyone who pulls changes, can do bower install.
Going further, I make file, where I create json object with two values, js and css, where I put path to files I need. Then I require it inside gulp.js and I can do whatever I want with these files. Usually concat, minify, copy result to public.
Theres nothing wrong with putting frontend into same server. Maybe you work alone or in the small team, and you don't have time to manage too many things. Common practice I see all around is that people make dir angular inside root and just grab all js/html files inside this dir, and copy them to public inside gulp.
It's opinion based, but I think it is not a good practice to mix front-end and back-end.
Your Proposal
Your public (front-end) files, like bootstrap, you should store them in public/ of the Laravel installation. You can use public/assets/js, etc. The folder resources is not available in your html files (if you mean the folder of your Laravel installation).
Better Approach
A better approach is to separate totally your front-end from back-end. In that case, you need a front-end framework, like AngularJS or Ember.
Why?
You can replace one of them without troubles in the other
You can use your back-end as third party api (https://api.yourdomein.com/v1/...)
No conflicts with blade views and other template formats
Of course, separation of responsibilities
You should install your bower components in your resources/assets/js folder. Then add any of these components to your build process in your gulpfile. This way, you have total control over what gets concatenated and minified and ultimately included in your templates.
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.
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 have a PHP Platform that I've built.
I use a copy of that project for each project I do.
I add assets and configure each project with it's own content.
Configuring a project changes some of the core files which contain
the configuration defaults.
When I update core files in the library/platform itself and I want to disseminate those changes to all of the other projects using that platform, what would be the best approach?
I think it may be worth noting that I have each project as an SVN project in Eclipse.
UPDATED DETAILS:
The platform is based on AMFPHP 1.9.
AMFPHP has a services folder.
I have to put core services in the services folder as well as
implementation specific services and therefore cannot achieve
complete separation between the "library" and the "application".
Also, the default configuration files need to be in the "platform" folder
so they can be easily distributed with it, but when configuration is
changed, those files become "implementation specific" as well.
Is there a solution that will allow me to designate certain files to update?
Take a look at the use of svn:externals. Configure each secondary project with your core libraries as an external.
Excellent question, here's the way I solved this problem with my own PHP framework.
If you have all the project-specific and core files mixed together, and platform code interspersed with your project code, it's going to be really difficult to update the core code to all of your projects.
The best way to get around this is to make it easier for svn (or git, or any other versioning software) to update your files: if they're all neatly organized, with project and core files in their respective places. Let me give you an example to clarify.
Put all of the core files of your framework in this directory:
/App/FrameworkName
Here you can place core classes, functions, and other code that won't change for all of your different projects.
Then, any project-related content, settings or pages go in:
/App/Project
Here, you have all of the data that your projects use.
With this system, if you add a feature to your platform, all you have to do is svn the latest version of your framework to /App/FrameworkName, and your project will be using up-to-date code.
My programs are usually organised in two parts. the core framework folder, and the addon folders.my framework (in house) does all the initial work then loads the addon for additional functionality.
For example, the framework deals with all the user auth , the addon provide additional crud functions the each project needs.
That way, i can keep them in separate repository. and the framework can be checked out and used for other projects.