So I have a project here that consists of several websites, and rather than writing functionality such as a login flow and signup flow into each project codebase I’m looking for a way to write these shared components once and include them as dependencies into all of the required codebases.
The login flow, for example, consists of:
model,
view
controller
repository
JavaScript
css
unit tests
database migrations
all other code related to the login flow
I would really like to be able to just include these shared functionalities via composer for example. Is there a way to do this?
Docker community edition, Laradock, Laravel 5.7, PHP 7.2, composer.
if you need to Share function you can make this function in helper function then put path in autoload path this link will help you for more understand
Related
I am new to Nextcloud app development and would like to create a simple app to play around. I saw that some apps are made with Vue.js, so I’m asking if there is a guide out there?
I generated an app skeleton and played around with the PHP templates but unfortunately I don’t know PHP and would like to create a Vue.js project into this existing demo app.
I found some premade Vue components for Nextcloud
https://github.com/nextcloud/nextcloud-vue
but no step by step guide on how to setup the Vue project after creating the skeleton app. I just saw that the Nextcloud app Tasks is also using Vue.js within the PHP code:
https://github.com/nextcloud/tasks
Thanks a lot for help.
I've looked at the repository you mentioned and it's fairly easy to setup, the question is what would you deserve after setup? If you clone the repository you have something like a 'working copy' of the plugin. But this Plugin needs to be build and the resulting package needs to be copied to right location at the nextcloud server (or maybe you have to install the package over frontend). This is some type of plugin and not a full web application which could run standalone, as I understood.
It's not like you said:
Nextcloud app Tasks is also using Vue.js within the PHP code
It's more like PHP is used for Backend and Vue is used for Frontend, these two 'projects' are completely independent from each other (PHP is backend and Vue is frontend there are no direct dependencies). Just create your Vue application (after build you will have an index.html and several js and css files) these files have to be available from browser. Then your applications entrypoint is the index.html. For PHP: You will just define Interfaces and Routes here which will give you the possibility to interact with the serverside. Then later to deploy your plugin, you have to package it in the format nextcloud needs. You can read from Makefile in the Tasks repository what happens if package is created.
I think a good starting point for you would be: https://docs.nextcloud.com/server/15/developer_manual/app/tutorial.html
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.
I have a legacy PHP project that I'm working on bringing some framework components into. I'm starting by bringing Laravel's standalone View package into it. I've used the following to get the Views in and functional inside my legacy project:
https://github.com/mattstauffer/Torch/blob/master/components/view/index.php
The views are working fine, but I'd like to use Laravel's Html and Form packages (https://github.com/mattstauffer/Torch/blob/master/components/view/index.php) in my views as well. I've included "laravelcollective/html" in my composer.json file, but I'm not sure how to make it work with the standalone Views package.
Eventually, I will rewrite the legacy system using a framework from the start, but for now, I'd like like to bring a couple pieces into it.
Just to reiterate, I'm not trying to bring Html and Forms into the full Laravel installation (I know how to do that). I'm just looking to bring that functionality into the standalone Views package to use with the legacy system.
Thanks in advance!
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.
I looking for some plugin structure for Laravel based applications.
For example a forum software, a cms or a e-commerce application can benefit from a plugin structure.
My question is what is the best way to implement this plugin system so that third party plugins can extend the application. The main issue is that it should be dynamically extendible and users should be able to install these plugins easily without messing with the app code.
This question also extends to themes but thats another question. Any ideas?
Laravel is a framework, not a CMS like Wordpress or Joomla, so plugin system that fits everybody may be quite hard to create as Laravel can be used in many ways, but I can really see the benefit of easy packages in some contexts.
The Packagist has been already mentioned and it doesn't solve directly your problem but how about:
Find good usable packages from Packagist for the purposes you need
Define common plugin architecture (common API for binding things together, installer, package format, migration, updates etc) on top of Packagist packages
Create installer that fetches packages via Packagist/Composer and adds sets sane default settings and configuration for the packages and integrates them into the defined plugin architecture
Document and plan this really well and the others will soon follow
I'm a little confused about the question, but I believe what you are looking for is already implemented in Laravel 4. They are just called Packages, and can be found at http://www.packagist.org and easily installed and autoloaded into your application using Composer.