Imagine I've got a class defining an entity, such as a Product.
My framework is structured in toggable modules, such that some modules may extend the default class, i.e:
Module1 lets me define a ColoredProduct
Module2 lets me define a ShapedProduct
How would I define the relations between ColoredProduct, ShapedProduct and Product? How can I make sure that I can get a dynamic relation (toggle one or another without code intervention)?
Do I extend the class product? Do I refer to it on each subclass?
I'm using PHP. Thanks for your input.
This sounds like you are looking for a class hierarchy:
Product is the superclass
ColoredProduct and ShapedProduct are subclasses.
You need no additional code since the subclasses inherit methods and properties from the Product superclass.
Depending on how you implement modules this could also be solved using Interfaces or traits.
If your question is more about designing application modules that are related this may be of interest: what is the difference between loose coupling and tight coupling in object oriented paradigm?.
For a very good example of how independend modules can be designed in PHP you have to look at the Modules in Yii2 Framework.
Related
I'm extending the functionality of an existing Symfony-based application and have found that additional bundles and using bundle inheritance has worked well to customise the functionality.
I've now found myself wanting to inherit from an existing bundle to customise its functionality but I also need to add some additional entities and extend the existing ones. The documentation suggests it might not be possible to extend an existing one since the entity is not a mapped superclass.
Is there anything I can do in this case? I basically want to retain the vast majority of the functionality of the existing bundle, but be able to collect more data.
EDIT:
I've looked into Doctrine inheritance and everything seems to require I have access to the top-level class in order to extend it. Which isn't ideal, as I'd like to keep that class the same.
I'm trying to get to grips with the power behind Joomla (3.x)'s framework.
I've noticed that there are multiple types of model that can be used in a component:
JModelAdmin
Prototype admin model. Acts as a Factory class for application specific objects and provides many supporting API functions.
JModelLegacy
Base class for a Joomla Model
Acts as a Factory class for application specific objects and provides many supporting API functions.
JModelList
Model class for handling lists of items.
Acts as a Factory class for application specific objects and provides many supporting API functions.
JModelForm
Prototype form model.
Acts as a Factory class for application specific objects and provides many supporting API functions.
JModelItem
Prototype item model.
I understand that JModelLegacy seems to be the foundation class. My models have been extending JModelLegacy by default, however, I was wondering if I could be potentially using the benefits from the other classes.
If there was someone who knows about these models, I would appreciate having an explanation about what the differences are between these model classes, and an intended scenario where you would use one over others.
First of all all the classes are available for code study under:
\libraries\legacy\model\
It's also important to understand that these classes should be used (generally speaking) in connection with the corresponding controllers: JControllerLegacy, JControllerForm and JControllerAdmin.
JModelLegacy - is the base class for the Joomla model (model as in MVC). It will basically work as a Factory class by initializing the database driver object and the table object.
You may want to extend this class if you just want to do some basic SQL queries (any work with JDatabase) and write other business logic.
All models will extend JModelLegacy.
JModelList - is a class for handling lists of items. It provides pagination and filtering. Basically everywhere you display a list of items, you can use JModelList. All core components rely on JModelList.
JModelForm and JModelAdmin are generally associated with forms. Forms can be the the User registration form or creating and editing a record. Forms in Joomla are defined in XML files. JModelForm will load this files as JForm objects, will load form data, preprocess the form and validate it.
This is one of the most powerful classes that you can use. They will do the heavy lifting. When you don't like a specific behaviour you can override it by implementing your own code.
JModelAdmin adds some extra admin functionalities to the form:
perform batch operations on records.
will do ACL checks on records.
JModelAdmin will generally be used when editing a record or for batch operations, especially in backend.
JModelItem - very unlikely you will need it. It exposes just a method getStoreId() and two properties. You won't need this class, unless for as a naming thing, instead of using JModelLegacy you want to extend it when doing something basic, such as displaying a record. (my personal understanding of things).
Conclusion: Above is a general introduction to this classes, as I see them. My suggestion is to look into detail how Joomla uses them, what methods are exposed and how to use them. They are very powerful classes, and especially for CRUD operations they will help you do all the heavy lifting. After you understand what they do, you can use them and override them when needed.
If you read the documentation for CakePHP on creating PlugIns. It clearly states that the PluginAppModel and PluginAppController base classes extend from the AppModel and AppController classes. Which are implemented in the application using the plugin.
This seems very risky to me.
A plugin doesn't have control over what callbacks, components, helpers, etc.. that an application may have configured in those base classes.
Is there any problems in having your PluginAppModel/PluginAppController extend just the base classes from the CakePHP lib. Like Model and Controller?
Can someone explain the logic in why a plugin should extend these application specific classes?
Not matter what you do, exclude the App* classes from the inheritage chain or if you include them. There will be always points of possible failure because it is not predictable what people do in these classes.
The less likely scenario is that things break in your plugin if you extend the App* base classes than when you would not extend them.
Auth and Session Component are in the case of a Controller a good reason why you should extend the App* classes. Behaviours in an AppModel another one.
If your plugin depends on a certain - unchanged - state of a property of the Controller or Model class you did something wrong while building that plugin in my opinion. It is better to keep your plugin flexible by providing configuration options or check the states of inherited properties and attached components and behaviours.
If there is really a pitfall in your plugin - I still think it's done wrong then - you should document it so that it can be integrated properly by people who read the documentation.
I am using Zend framework and doctrine in this app
In my web application i have various individual modules like events, conferences, case studies.. so i am making controller design at this moment. In the below image regulatory document is the controller and its sub are its actions. So regulatory doc, videos, podcasts all are having almost the same kind of functionality. so is this design appropriate...?
In mvc for each action i will be having a separate view. And on user type i may have to put access levels on this modules. so i have kept separate controller so that i can easily control the module for each user type. But this is resulting in duplicate code.
Now i am thinking to make one parent class and in that i will have all the common methods. eg. I will have common class Resources and in that i will keep list, search, suggest, addFavorite etc. And that will be the parent to the above given controllers.
So than how will i manage my view for all these different modules if i go with this approach..? if i go with this than my code will be bit messy..?
I would suggest to keep all the controllers to have nice URLs and clear structure in the modules, however keep the controllers thin. Put your domain logic into Services or Entities, hence no (or just less) code duplication is required.
More in:
Is MVC + Service Layer common in zend or PHP?
How to implement service layer in Zend Framework?
From DDD:
http://domaindrivendesign.org/node/118
controllers belong to application layer / domain logic belongs to domain layer
If I understand you correctly you have a set of common behaviors among your regulatory documents, videos and podcasts.
In this case you should probably try to abstract the commonalities out into a parent class from which these three areas inherit.
As an example, I have my own MVC framework where I define a superclass tnh_controller from which my other controllers (eg: venue_controller, group_controller) inherit. In the parent controller I define the header() and footer() and delete() methods. I can then use those unchanged in the child classes and save myself some effort.
You can likewise do some of the common work for your models (CRUD) in a model superclass, only overriding it as needed. Most of the logic for different models comes from class variables (table names, column names, etc).
I wouldn't worry too much about being "strict" MVC. Instead try to work out what will save you time and keep your code organized. It sounds like you're on the right track putting similar behaviors at a parent level.
You can still have a separate controller to contain suggest, addFavorite actions without having to make it the parent class for all the controllers. Basically the UI elements related to these you can render as partial views and call on to the actions in the relevant controller. That way you can get rid of the problem with the views.
MVC designing means that for each view, you have a controller and a model. However, the models don't need to be classes at all, nor having a different model for each MVC. Usually you will share a model between some MVCs, or your model might just be an integer value which you define in the own controller. Usually, you might even want to share data between them, then you will have a singleton mode:
http://www.galloway.me.uk/tutorials/singleton-classes/
I am a 4 days old yii fan and I like it so much.
I have a special database table that can't be used by CActiveRecord directly. My solution is to subclass CModel to have my own logic for listing, creating, saving and deleting records. My new CModel subclass cant not instantiated; it seems that CModel requires more methods to be defined to allow creating an instance from it.
My question is: Is this the right approach to go or there are better ways? If yes, what are the missing methods to define to make my new class complete; not abstract
Thanks
I usually create my own classes to handle the so called 'logic' of the webapp that I'm building.
I place it in another folder (usually the logics folder) and auto import the directory from the config. The logic classes doesn't subclass from any Model
public class ProfitLogic { ... }
where inside the class(es) I implement functions that instantiates and use any ActiveRecord(s) that I need.
The reasoning for this is that when prototyping I often refine my database design, and I need to regenerate the ActiveRecords again :p
Your approach is fine generally speaking, and would be fine even if you were not "forced" to adopt it. I use a CActiveRecord subclass as the base for my models to provide additional custom functionality.
As for your other question, you only need to implement attributeNames() to be able to instantiate objects of your class.
However, why do you not subclass CActiveRecord directly instead of CModel? You can still override any and all methods you choose to. Is your database so dramatically different from the usual schemas that you won't be able to reuse any of the logic?
I'm fairly new to Yii as well, but have found that extending CForm, as in the default ContactForm model can be useful.
Not the best for having lots of heavy business logic, but it touches on your point of breaking out of the typical workflow.