I am trying to create an alternative view and found this answer:
How to load view from alternative directory in Laravel 4
which suggested using this code
View::addLocation(app('path').'/themes/default');
View::addNamespace('theme', app('path').'/themes/default');
But cannot decide where to declare these statements . In which file can I use this code?
start.php,path.php,app.php,global.php or in another file .
If using the app/config/view.php configuration file to add view loading locations (via the paths array) is not enough for your needs, you can probably fit that into a service provider.
Laravel actually uses the View Library's Service Provider to register the view paths locations (based on the app/config/view.php config file as mentioned).
One thing you can do is add your own service provider class and add in your view logic there, in order to add a location / namespaces as you need. (You can even have your service provider read your own configuration files in order to determine locations/namespaces).
If you need help creating a service provider/don't know where to put one, read this on creating a Laravel application library.
If that's all you'll be doing, putting it inside app/start/global.php works just fine. There's really no need for a new service provider for such a simple task.
However, if after some time you realize your global.php file is starting to get too heavy and messy, then you should go for a service provider, as #fideloper mentioned.
Related
You know wordpress template system. I'm writing a simple script with Laravel. I'm very beginner at Laravel. I need to more than one template and it must be selectable at admin panel.
I created subfolders at views doc like that:
project/resources/views
defaulttemplate
othertemplate
othertemplate2
I keep template's doc name in the database when one is selected. I want to run the site selected template.
How to I can do it?
Firstly, Wordpress has a million lines of code and it's open source. You have to observe their codes from github repo if you have ever never implemented an templating engine as same as Wordpress or any kind of equivalent applications. It's not best practice however you can simply create a new namespace for the view from the app container.
You can boot your namespace definition on AppServiceProvider
app("view")->addNamespace("theme",base_path('themes/'.DEFAULT_TEMPLATE_FOLDER_NAME));
Within this way, you can pass different folders as a view. you have to call your view files via themes:: namespace.
Let's assume you have a default folder in the themes folder as a default template and there is index.blade.php inside of it. You have to call it as a return view('themes::index') in the controller. If DEFAULT_TEMPLATE_FOLDER_NAME changed, the themes:: namespace will point to changed destination due to App Service Provider. It's a simplest version of wordpress-like templating. For the best case, you have to observe different kind of open source projects.
I wrote a small library (https://github.com/dborsatto/php-giantbomb) that acts as a wrapper for an API. In order to work, the library needs 2 basic configuration options:
An API key
A file that describes the API options
What is the suggested way to handle these two files?
The API key is of course personal so it can't be added to the repository. But by doing so, I can't write a functional test for the library as a whole, thus limiting myself to only unit tests for the single parts. Do I give up the functional tests altogether or is there a way to make this work?
About the other config, basically it's a YAML file (https://github.com/dborsatto/php-giantbomb/blob/master/api_config.yml) that includes the base API endpoint, and configuration for each data repository. At the moment this is handled by a Config class that is decoupled in a way that the user must write glue code and inject data into the Config. This way it's easier to test, but as a whole I feel like it's creating a bigger disadvantage than just letting the Config class load the file, parse it and behave accordingly. What is the best way to do this? At the moment there are no tests in the repository, but I'm working on it (along with some code refactoring).
I would suggest to leave the configuration outside your library; I've done something similar for the Mandrill mailing service, where I left to the developer the management of the configuration (I was working in a Symfony 2 project). For me there is no Config class, just the service constructor that accepts the API key and an (optional) array of options:
public function __construct($api, $options = array())
{
// My code
}
When I need to use my service inside the Symfony 2 application, I take the needed parameters and configuration from a place (Symfony's config files) external to my service; this way I can decouple the library from the configuration. Of course the service contructor throws an exception if the mandatory parameters are missing.
Before using Symfony2, I used to have a common lib with a lot of simple but useful functions (for instance, a function which takes "Azè_rtï" in argument and returns "aze-rti").
So, well, I created a Bundle: CommonLibsBundle.
But.. I have only one or two php files. It does not make sense to me to use a controller / view / model in this kind of situation.
What should I do? May I erase all folders in my new bundle (Controller, DependencyInjection, Resources, Tests... + CommonLibsBundle.php) and just put my lib.php in it?
Many thanks,
Bliss
Unless you need to tap into the Symfony framework itself - for configuration or to define services, it doesn't need to be a bundle - it's just a library. Give it a reasonable namespace, and call as required as you would any other component or library.
Even if you wanted to add Symfony-specific services that you could call, there is something to be said to still have an external simple library - usable anywhere, which then is wrapped by a very thin bundle which would only add the Symfony-specific (or Laravel, or ZF, or whatever) services and configuration as required.
Is there a general place that I could put logic that can be shared between the controllers and commands in Laravel. I have functionality that will most often times be run from command line via stored procedure, but also need the same (or a subset) of the functionality via web.
Can I use controller logic within the command? Or call the command from the controller/route?
Or should I just build my own classes and include them as needed in both?
just create a app/libraries folder. In that create a custom_helpers.php file and autoload it. Store your methods that your going to be using often there. Think of it like the helper class provided by laravel by default.
I'm quite new to Laravel 4 (Laravel is my first PHP MVC framework) and need a little help structuring my project.
1/ I need to include the the json-rpc classes found here jsonrpcphp.org in my project and am not quite sure the best place to put these.
2/ Where is the best place to do my initial setup/connection to my data source? Should this be inside of my controller or should this be placed elsewhere?
require_once 'jsonRPCClient.php';
$connection = new jsonRPCClient('http://user:password#127.0.0.1');
I think and pretty sure the best way to do it is to create a Service
Put anywhere securely and can be easily accessed via composer. Look into how add autoloading to composer http://getcomposer.org/doc/01-basic-usage.md#autoloading
as I said, create a service. look into Laravel IoC Container http://laravel.com/docs/ioc and How to define Service Provider
see example: DatabaseServiceProvider
Related: optional for nice syntax create a Facade for it.