After some fiddling building a package for a project we've realised there's some issues with doing what we need to achieve as per Laravel 5 package development clarity
Maybe I should rather explain my goal and someone can suggest a direction to head in.
We've built a Laravel 5 application that now needs to be "re-used".
We had to modify Laravel and implement an Eloquent type base model as our data-source is actually C# Web Services. At the point the call would be made to a database we intercept this and make an "API" call to SOAP.
The major difference will be CSS, maybe some JS & content but all the routes/controllers/models will remain the same across all projects. Most configuration comes from endpoints.
Initially we considered creating multiple asset repositories for each site's styling and have a base repo which is the core Laravel project that gets included. This seemed to get quite complex as we couldn't simply just have a repo in a repo due to branching and multiple directory issues.
We then started experimenting with the idea of building the "core" as a Laravel package but we seem to constantly hit walls. The latest problem being including models in the package. For the models to be called we are using the root projects config/composer to access these models instead of just the service provider. It feels like the package is becoming to tightly coupled to the project config.
Are there any better ways of going about what we are trying to achieve?
Edit:
I forgot about the multiple branch solution on 1 repo but wouldn't this get ugly when it comes to feature development? Example:
master (core with releases that get pulled into _site*)
dev (master dev)
feedback-form (eg. master branch feature)
_site1 (root site with releases)
_site1-dev (_site1 dev)
_site1-reskin (eg. _site1 feature)
_site2 (root site with releases)
_site3 (root site with releases)
This leaving quite a bit of destructive merge power in the developers hands? Read access with pull requests maybe a solution to this?
So after some R&D it seems the best solution right now is to have 1 repo with multiple branches. Developers have read access and have each developer creates his own fork. Developers create pull requests and sync to parent repo through "upstream" remote and developers sync each others forks through additional remotes.
Seems a little clumsy but probably "cleanest" option.
Related
I regularly use Laravel to build applications. Recently, I have started using Lumen to build microservices.
One thing I notice with Lumen, is that I often only need to create 2-3 files, and edit a further 2-3 (providers, configs and routes). In total, I am editing or creating 5-6 files.
It feels to me that my git repositories for these microservices would be way cleaner if they only included the changed files, and then I merged with the Lumen framework during the CI build/deploy.
Does anyone have any experience with doing this? What are the pros/cons?
I build many API services with Lumen, and I always have the entire project on git repo, and when I make changes locally, I pushed it to GitHub and from the server i just take a pull. I wouldn't say there are necessarily pros or cons, just different ways of doing things
I have a long list of models in frontend. Some of these have functions that are required to be run in batch. For this console is fine.
I can include the models by copying over the code, however this is not a decent approach.
What Im looking for a way to import models from the frontend submodule in console command so I can make changes in one place.
To clarify,
the standard way of including
use app\models\Mymodelname;
in the console\model results in the following error
'Class 'app\models\Mymodelname' not found'
use app\models\Mymodelname;
Have not worked with this include statement before. I prefer to use the frontend/backend as is. If I had to make a wild guess though, this looks for models within console. #app is an alias for current application.
Usually, I keep anything used by more than 1 application under common. As you pointed out, maintaining two copies of the same code is not a good practice.
Try using frontend\models\Mymodelname directly if moving to common is not an option
I don't know if you have two separate applications, or could benefit from this, as you are already using submodules, but depending on your desire to separate concerns with some console commands this might be advantageous.
If you are using composer to manage your dependencies then you can create a separate repository in git, for example, and add a new dependency in your project which contains these common models.
Then, include your dependency in both projects. This introduces some troubles while developing since both apps share this dependency and it can be frustrating at times; I have shared common functionality between multiple interval laravel projects in this fashion with great success.
Currently you seem to be using submodules so this might require restructuring which could be difficult or impossible.
Another option if you want to keep to submodules is to keep common models at a higher level (not inside a submodule) so that you can import the models into both submodules and use them in both places. I shared common models between modules with yii 1.1.16 using this strategy over several years with much success.
Both options have their advantages so weigh carefully your desired outcomes. Feel free to ask for clarification.
How to add private github repository as Composer dependency
#app is an alias of current running application. It can be frontend or backend or console. If you want to access model across applications, add it to commen\models. Or change app\models to frontend\models. That way, you can access frontend models on console. Better way is moving it to common\models.
I have been developing in Codeigniter for awhile now. I have recently read that Laravel is currently the most modern and best framework. I am interested in learning it for my next project. I'm hoping that someone could help to answer some questions that I have about Laravel.
1) How would I host it? Laravel seems to rely on composer a lot and that requires a terminal. For CI, I just download a folder and load it up to my Webserver and I can run it.
2) Dev environment. I have been using Netbeans that is connected to my server and it can push updates instantly. I want to connect it to git soon for some versioning as well. Is it the same for Laravel? How would I update it?
Same here, I have been developing Applications in Codeigniter 2,3 for past 5 years and now I am learning Laravel and have starting making beginners level application in Laravel Here are my findings which might help you
Difficulties
For Codeigniter Developer, Instantly playing everything by using router is kind of difficult. Although router is used in codeigniter as well
Installing and setting up Laravel seems like a tricky and very lengthy job especially the use of composer which is an extra thing as compared to codeigniter which is just download and uncompress or copy paste installation procedure.
But Why Laravel?
Object Relation Modeling - Eloquent ORM
We can easily create relations and joins with query builder or active records in codeigniter but to enforce referential integrity in database, we have to write triggers in our database or define relations. Luckily in Laravel the relations are made with one line of code and does a lot of job. Whereas in Codeigniter that's a lot of manual code writing.
Integration of off the self Packages.
There are thousands of developed packages readily available on packagist, which is a repository composer uses to download software packages. You just have to write one or two lines of code at composer terminal and it does all the rest, create models, controllers, views. All you have to do is include them or change the styling as per your layouts.
Think of Laravel as a PHP framework for extremely lazy developers who want to write very less and re-usable code and do lot of work from it.
Learning Resources
Laravel 5.2 from Scratch that's the one I started with, excellent course and Modern Web Development with Laravel
Uploading on Shared hosting
Click here for tutorial
Why does the default laravel4 have the composer.lock file included in the .gitignore repo?
It seems to contradict composers recommendations to commit this file into VCS. I was wondering if there was something I didn't know that justified this?
According to the author of Laravel here https://github.com/laravel/framework/issues/1412:
It is recommended for your own apps, not for frameworks.
It's not clear from the question if you meant the framework or the app. Instead of asking for a clarification, I decided to write this instead for future confused users.
The problem is, it's ignored not only in the framework but in the app too. The app is what you get when you install Laravel as a project (i.e. not for the purposes of developing it and sending pull requests but for using it in a project of yours).
In contrast, the Symfony project makes a distinction here and doesn't include the lock file in the .gitignore of the the Symfony Standard Edition distribution (the app) unlike the Symfony framework.
There are already at least two issues and one pull request regarding composer.lock: issue 1696, issue 2293 and PR 2591.
I have what I believe is a tricky situation but this usually indicates I'm ignorant of something quite simple.
I currently have one php project that is in an svn repo, call it 'firstproject'. The working copy of this is an apache virtual host dir so I can happily run this project at any point of development through a browser.
I now have another project 'newproject' that I want to use some of the core code of 'firstproject' but when newproject requires me to refactor parts of the firstproject classes I would like for that to be integrated back into firstproject at some point.
Is there any way to set svn up so I can have a working copy of newproject happily in it's own apache virtual host and comprising some code from firstproject and then its own code and for svn to keep tabs on which is which or is it a case of creating a 'newproject' branch of firstproject, editing away adding the newproject code and then doing some sort of merging of code back into 'firstproject' when it seems appropriate?
Many thanks to anyone who can help me thinking about this, it feels like there should be a neat way but maybe there isn't.
It seems to me that firstproject should release some deliverable (a library). newproject can then consume this.
If that library needs to change, then the changes should be made in firstproject, and released.
That's how I'd normally manage this sort of dependency in a non-PHP world. I'm not sure that in PHP it should/would be any different. It's a bit of a headache, but you're building a reusable library that a downstream project can consume (and choose which version it consumes, note).
If there is a large part of the code that is common, then you can consider using a common repository instead of two seperate repositories for these two projects. You can then take out a branch for the code that might change within the project newproject . The workspace on the newproject apache server will have to be from this branch so that any changes can be committed back to the branch and merged back to the trunk when you are ready. This way you can incorporate the changes back to the firstproject mainline/trunk.
You can also explore svn externals for another approach to mix and match if you need a workspace with checkouts from multiple repositories. I have not implemented this myself but you may find the details here:
http://svnbook.red-bean.com/en/1.1/ch07s04.html