The Laravel Lang class provides a convenient way of retrieving strings in various languages, allowing us to easily support multiple languages. e.g. Lang::get() can be used to retrieve localized message.
But according to API documentation (and sources), class Lang doesn't have get() method or other methods like setLocale() for example. Class Lang extends Facade but Facade doesn't have that methods too.
Instead class Illuminate\Translation\Translator contains all methods we used for localization like get()
Why then we don't use Translator::get() or Translator::setLocale() but Lang::get() ??? How these two classes are connected ?
How can we invoke non-existent methods for the class ?
Your answer is here:
http://laravel.com/docs/4.2/facades
The Laravel documentation is pretty comprehensive. If you really want to understand how things work in Laravel, please take some time and read it all.
Related
I created a model in Laravel. I always noticed the default would be use HasFactory. May I know what exactly does it work. In my understanding from reading documentation, it is for linking to database (I guess?) But I still don't understand how it works exactly.
HasFactory is not to link to the database.
It is a trait that links a Eloquent model to a model factory.
Factories are normally used in testing when wanted test-data for a specific model.
You can read more about factories in Laravel here: https://laravel.com/docs/9.x/database-testing#model-factories and here:
https://laravel.com/docs/9.x/eloquent-factories
The trait ensures that you can instantiate a factory like this:
User::factory()->create();
In older versions of Laravel the trait was not used, and instead a factory had to be instantiated by the global factory helper like this factory(User::class)->create(); but that caused a lot of problems with intellisense in IDE's.
I'm in need of some clarification on how why it is more recommeded to use dynmaic classes rather than static ones. Laravel's documentation uses a lot of examples which use DI to inject objects... But sometimes Laravel uses static methods or classes.
My question is, for every request, everything is reset, right? So using static classes is just as good as dynamic in that case? - I know this is probably wrong but I am failing to understand why...
For example, Laravel allows you to pass in an object inside the constructor but why not just use a static class instead? Why use a dynamic class when you only use it once for the request in the Controller example? I am just trying to understand why, I am not trying to justify my understanding.
I have a number of Soap Server classes most of which will need to implement 3 methods:
ping() // something to bounce a signal off to prove it has been reached
getCredentials($creds) // credentials to check sets session value
getCaller() // for logging, uses session value
As they form part of the WSDL defn they need to be public.
I am fairly sure this (I have christened it a Soaplogin) would need to be an abstract class (because it must never be instantiated on its own)
The concrete classes which extend then this core then have their own methods, none of which are shared.
I am searching for the best type of Pattern to use and am getting a bit confused, though I think a Template Method just about fits the bill - but I could just plain extend the SoapLogin class.
What advice can you give me on the best pattern to use, and maybe a preferred name for this class.
(while this uses ZF1 components it does not use full blown MVC - in case that was of importance)
Prefer composition over inheritance.
What you really do is you create completely independent interfaces that only by chance happen to have the same methods.
Fine. Generic methods that always do the same - that should be in a class of it's own. But not ONE class for all these methods! One class per method!
You can then add all these method classes to your server classes, and also add all the special functions the same way.
That way you can combine any of the generic functions in any way, and add another only to one API if needed.
This pattern could be a good solution if you just want to create several soap connect.
An other one could be to use interface. It will tell your program that every class that implements SoapItf (for example, rename it if you want) are able to perform soap method.
If you look for an evolutive application, maybe you'll need to connect with Rest webservice after so you can create an abstract class Werbservice, two class Soap and Rest that extends it and this two class implements interface SoapItf ans RestItf respectively.
This method helps using polymorphism, an important concept in OOP.
In this case I can add method to Soap or Rest without changing both.
After that if you have specificity with Soap like in your example, you could extends Soap class. It will be easier to evolve the application and using package architecture (interesting if you work with namespaces)
In my opinion, you can use template pattern to manage a common resource that is spreadable in sub-classes. For instance, you have a soaplogin common abstract class and that might have some resource that can be used by most of the sub-classes. Then it's better to manage that resource in super-class and pass the callback in subclass to use the resource of the super-class. Advantage is that you are managing resource at a single place.
For example, I have a common resource in my super-class. I can create a callback passing resource as a parameter.
interface ResourceCallback {
T call(Resource resource);
}
Then can define a abstract method in super-class like as doWithResource(ResourceCallback callback) and all the subclass can now use the resource with their own implementation of their methods.
I've been told to use some ORM library to make storage easier.
I've read about Doctrine, RedBeans and some other ones. I'm giving RedBeans a try because it's quite simple and requires no configuration.
I already tried some basic code to store beans and so.
If I want to have a model class (a bean?), to add some basic behaviour and functions.
What class do I need to extend? What methods do I need to override and then how should I get an instance of them?
Example: a Blog class which contains a User and Posts
The answer to my question was a feature of RedBean called 'Fuse'.
It was as simple as extending RedBean_SimpleModel class and implementing delete and update methods.
The downside of RedBean is the lack of tutorials/documentations (their wiki is really poor)
Because of other answers (like this), I'm just wanting to clarify what should be used in CakePHP 1.3.
Specifically, I have a situation that calls for a Model to depend on another, so from a method in that Model I'd like to load another, do some stuff with the info, etc.
The documentation for the App Class says:
In previous versions there were different functions for loading a needed class based on the type of class you wanted to load. These functions have been deprecated, all class and library loading should be done through App::import() now.
I'm assuming this covers the use of ClassRegistry, etc, but I just want to it to be clear, and certain:
Should I use App::import('Model', ...) to utilize one Model from another, or something else? If something else, what?
It appears that, even two years since 2008, the best method is to use ClassRegistry::init(), despite the cited documentation.
This is made evident in the actual API/documentation for the specific classes/methods.
App::import()
Finds classes based on $name or specific file(s) to search. Calling App::import() will not construct any classes contained in the files. It will only find and require() the file.
ClassRegistry::init()
Loads a class, registers the object in the registry and returns instance of the object.
Examples Simple Use: Get a Post model instance ClassRegistry::init('Post');
As you can see, even the API Documentation points out examples of using ClassRegistry to load models, instantiating them for you, as opposed to App::import (which does much less), and despite the changed wording in the CakePHP "Book" documentation.
If you can relate the models then the best way is to Dynamically bind the relations using
$this->bindModel("hasOne" => array("Model2")).
If you can't relate the model and you want to use the second model in just one occurrence then you can use
ClassRegistry::init('Model2')->find('allThatIWant');
if you want to use it in several occurrence then you must try
$this->model2 = & ClassRegistry::init('Model2')
$this->model2->find('allThatIWant');
As of 2.6.x of course it is ClassRegistry::init() still.
There is a major difference. App::import will just include/require it. On the other hand ClassRegistry::init() will instantiate it and fetch you a fully loaded object of the model.
So to say, for example you loaded a model in beforeFilter of your AppController. You add some custom properties to it using $this->Model->__something. Now you do call ClassRegistry::init('Model') somewhere where you do not have $controller object available, for example, in a behavior. The object returned by ClassRegistry::init('Model') will have your custom property $this->Model->__something in tact.
Btw, $controller->loadModel() seems the ideal way to load model where you have a $controller object available, for example in your components.
$this->loadModel('model name') will do unless u need it for the entire controller, Then just define the relationship in the model such as hasone, belongsto... and call $this->model->model2.