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.
Related
So I am working on two different applications using laravel and both of them need a lot of the migrations, seeds, models, controllers, routes and so on similar to each other. In fact in most cases, they are absolutely same. What is the best solution to avoid redundancy in such a case.
The best solution I came up with was to extract a package and then use that package in both the applications but there are drawbacks. Every time I need to add a new feature which needs to be added to both of the laravel application, the package needs to updated. Once the package is updated, the main applications are updated. Sometimes small syntactical changes make me change something in the package and then update the packages again to see if it is working. But soon it becomes painful like this.
I have also tried using symlinks in composer file so that the package gets updated as I am working inside an application which uses them, but I still have to update the other application. Moreover, I still have to remove the symlinks before I push because the symlinks break in CI. They need the direct cloud URL for the repository.
Has anyone else gone into a similar problem with laravel and has an idea of how to resolve it? Or the best solution regarding the same.
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.
I am developing web application using the laravel. I would like to 'package' some of the functions, which is re-usable. For example, I got a UserController, with database setup, and view, etc. The UserController is expected to re-use in most of the web development in the future, but some UserController may have different behavior, for example, some application's user may have a field rewardPoint, some may not. But they all have some similar behaviors, for example: register, login, forgetPassword, etc. So, can I package out a common UserController with all the basic database setup into one file or script to reduce the development work load? Thanks.
You've hit the nail on the head already - since your requirements are likely to change between projects you will struggle to create a single solution that works everywhere. You have a few options, including:
Copy the useful classes from your last project and update them to fit.
Create a package or bundle of base classes that include common and reusable code, then extend these into your project and modify the extensions as needed.
Attempt to create a "one solution for all" that you can drop in to all of your projects.
I would steer away from 3; it's likely to add the most bloat for the least gain. 1 is useful whilst you get used to the framework, especially if you tend not to revisit old projects; over time you will refine your code and develop patterns of work. Eventually you will probably end up doing 2; you can store these in git, use bundles or composer packages, and you can continue to improve them over time.
I am looking to reduce redundancies in code shared across entire web sites. I have tinkered with several frameworks but cannot think of any that allow you to EASILY separate the framework code from the site code while sharing it to multiple sites at the same time.
What PHP frameworks can do this easily?
EDIT - I am trying to determine which frameworks are the easiest to share.. I was already guessing that nearly all could be shared, but which frameworks are geared towards sharing? It sounds like Yii recommends placing the framework code outside the site code, that is a good start.
If someone is sharing the same framework code across sites already, I would love to know about that.
It's pretty easy to do that with Fuel (http://fuelphp.com).
Each website has an index.php where some paths are defined:
/**
* Set all the paths here
*/
$app_path = '../fuel/app/';
$package_path = '../fuel/packages/';
$core_path = '../fuel/core/';
As you can see, you may share the core and packages in a central repository and create a single app and public folders to each web site.
You may even share an app with different web sites customizing stuff (let's say, the site title or the database used) by just setting a different environment in the .htaccess. That works out-of-the-box for development/stage/production sites, for example, but may be extended to anything. You may also setup central packages to use in multiple apps. Powerful, easy and just works.
Many can do this. For instance YII is supposed to be installed OUTSIDE of your www-root directory (httpdocs, /var/www/ or something like that). You can use several sites to point to that base dir.
Any framework (or part) that does not need specific settings for your site can be shared among multiple sites I guess.
I believe Zend can do what you ask, possibly even Symfony and Fuel, and I'm sure many other frameworks that allow you to pick what parts of it to use will let you do this.
However, doing so will require you to do a little more configuring to get it all running. Which is kind of why I ended up creating my own framework.
Symfony does. I love the Symfony framework, and it comes with some great frameworks. You might like the Routing and YAML ones. A person I know calls Symfony the best php framework.
Symfony components
Some of the components have their own specific sites
You can find a really good documentation here.
Symfony2 is suitable for your needs. It's a full stack framework with a lot of standalone components. It works with "bundles", a bundle is a kind of container with a complete logic (controllers, model objects, views, assets, configuration, ...). That means you write one bundle and you can reuse it without any problem.
But you can also consider symfony 1.4. One project can handles many applications so your model is shared across these applications and the same code can be reused in all applications. Note an application can be a complete website.
I can't think of any frameworks that do this natively, but you could use several SVN (or hg, etc) repositories to accomplish this. Example using CakePHP:
1 repo has the CakePHP default files. If you wish to update CakePHP,
you update this repo in the future.
1 repo per website that stores everything inside your app folder.
It's not built in functionality, but it isn't very difficult to setup either.
I'm starting to familiarize myself with using the module-based architecture for zend framework projects. My real reason behind being interested in the module architecture is to be able to take a module from one project and just drop it into another project. Maybe I'm not getting it right..
But what I'm noticing right off the bat is that controllers within each module cannot have the same name as any other controller in the main application (or in any other module, though I haven't tested this). This leads me to think that modules are not really independent self-contained units, so I wonder how this affects their ease of distribution from one project to another.
The other issue is what if I were to take a module and drop it into another project. Do I have to update the .zfproject.xml manually? and wouldn't that be a bit too cumbersome to be done manually?
Maybe I'm not clear on how modules should be used in zend, so I'd like to know when you decide it's best to use them, and when do you decide not to use them, or do you use them all the time, or do you never use them?
I always used module based architecture so far in my projects, because I like to separate concepts. For example I have always an ADMIN module whose classes and controllers dont mix with the rest of the application. Using modules you can reuse modules for other applications, for example if you create a BLOG module.
The names of your controllers will be something like Admin_IndexController for the admin module even if the file is named IndexController.php.
Another concept that is nice and help you reuse resources is the plugins. Use them for authentication or to check validity of the requests.
You need to setup namespaces for your modules so that they are easily moved into a new project without renaming.
If you are using Zend Tool then you will have to edit the zfproject.xml. I haven't spent a lot of time using this so I'm not sure if there is another way without manually editing.