I'm new to Kohana and I'm trying to build an application using the ORM module. I created my own user module containing stuff like login, account creating etc. The problem however is that I can't seem to create a user model in my own user module extending the ORM one. If I understand kohana correctly I should name my user model: Model_User. The problem is, the ORM model I'm trying to extend is also called Model_User.
The reason I'm trying to create my own model is so I can add some extra methods and checks without modifying with the ORM user model.
So my question is:
How do I create a user model in my own module that extends the ORM user model?
You can extend pretty much everything in Kohana via the transparent class extensions: http://kohanaframework.org/3.2/guide/kohana/extension
In this case, the default ORM Model_User class is an empty (transparent) class that extends Model_Auth_User.
So if you want to add new methods to this model, just create a new Model_User model class that extends Model_Auth_User, in your module.
Due to Kohana's cascading file system, the model stored in your module will be used. http://kohanaframework.org/3.2/guide/kohana/files
[edit] Important to note, the order in which you enable the modules is important, see http://kohanaframework.org/3.2/guide/kohana/modules
Related
I would like to extend Query class in order to create function customContain() available in every Table model. How should I do it?
I want to use that BleMethod() in all table models in cakephp. Where I have to add code of that function? Where I have to implements BleMethod?
Unlike Cake2 Cake3 does not feature an application level class like AppModel from where all other classes inherit from. So you have two options:
Trait
Behavior
The behavior can be loaded globally to all models by using the Model.initialize event. And then loading the behavior inside the events callback. Read these pages:
Creating a behavior
Event system
Model / Table callbacks
But that's not what you want
customContain() indicates for me that you want to setup some contains very often. Well, use finders.
Finders can be combined:
$this->Table->find('foo')->find('myContains')->all();
Each custom find will add something to the query object. You can add your custom contains this way.
Read Custom Finder Methods.
I am developing a PrestaShop module, which will have it's own database tables. Let's say database table name is 'cat'. So I wanted to have a model class named Cat to keep track of it's properties and related operations. So where should it?
For example, there are prestashop core model classes inside classes directory. Is it ok to create a classes directory inside my module directory for that purpose? will it work?
The standard used is to place the model class in /module/model/YourModelClass.php, you can see this module and in your installation module class you should call it
require_once(_PS_MODULE_DIR_ . 'example/models/YourModelClass.php');
you have not a strict naming standard to your class model, like it does it the controller class and installation class.
Hope that it helps.
Cordially.
PrestaShop model structure is pretty free-flowing. You can decide what structure you want to use.
The only few constraints imposed on you are
having your module class which extends the PrestaShop module class;
registering the appropriate hook and their respective handlers;
My question was about where to place ObjectModel subclasses in prestashop. Above accepted answer is answering that question. But that's not enough to work the module correctly. You will have to include your model class where ever you want to use inside the module.
for example
include_once(_PS_MODULE_DIR_.'mymodule/classes/Cat.php');
class mymoduledisplayModuleFrontController extends ModuleFrontController {
// Other code goes here
}
If you are overriding existing model class, you can put your class inside /modules/your_module/override/classes directory. I have noticed while installing module, your overridden classes will be copied to the prestashop_root/override/classes directory.
http://doc.prestashop.com/display/PS16/Overriding+default+behaviors#Overridingdefaultbehaviors-Overridingaclass
My business case has a hierarchy above the user class (e.g. a contact only or a member without logins). But now I'm worried how the BaseUser which I have to extend from the FOSUserBundle can extend my Member class?
I don't really understand what is Your member class but in FOS docs its written
Your first job, then, is to create the
User class for your application. This class can look and act however
you want: add any properties or methods you find useful. This is your
User class.
The bundle provides base classes which are already mapped for most
fields to make it easier to create your entity.
You don't have to extend BaseUser, it is provided just to make installation easier. it should work if You copy it to Your own bundle and make it extend Your member class.
Does anyone know if their exists a bundle that supports multiple user types?
In my example I want a generic User class (e.g. FOSUser) that I will extend from to use for my CompanyUser class and EmployeeUser class, so those 2 classes will have all the features of a User but with their own class properties and methods.
From what I read it looks like FOSUser only supports a single type.
There is no Bundle. You should use Groups or if there is no other ways UserEntities extending the UserBaseModel. These should be available through a custom UserProvider
you can use RollerworksMultiUserBundle
I'm looking for advice on how to tackle a design problem I've came up with. I'm currently using Symfony framework so I'll be using the names of Symfony classes.
When a user becomes "authenticated" or their "credentials" change in the Symfony user class, a regenerate() gets called on the currently used storage class. The store class extends sfStorage.
Now, when this regenerate() command is ran, we need to do some business logic. The following are options I've came up with so far:
Modify the three functions that addCredential, removeCredential, setAuthenticated and tell them to dispatch an event (setAuthenticated already does) so we know to do our business logic.
Second option would be to extend the sfSessionStorage class and tell it to throw an event on each regenerate. The problem I have with this is that sfUser asks for the interface sfStorage. Unless we modify sfStorage then if someone passed any kind of class that extends sfStorage that didn't know to add the event, it wouldn't work.
The third option would be the second option, but we would still extend the user object to say that we require the interface of a custom sfStorage abstract class that sends out a notification on regenerate. Then we would know for sure that any class that passes through would follow this notification method.
Anyone have any suggestions?
I would go with the second option and extend the sfSessionStorage class, and then use the class by inserting it into the factories.yml.
This shouldn't cause any issues with the sfUser though as your custom storage class will extend from sfStorage by proxy.