I have in Symfony a Entity of Post. That project has translations, stored in PostTranslation.
Each Post has a slug that is different for each language.
The code looks looks like:
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\ParamConverter;
/**
* #I18nDoctrine
* #Route("/blog/{slug}")
* #ParamConverter("post", class="SensioBlogBundle:Post")
*/
public function showAction(Post $post)
{
}
But how can I do a findOneBy('slug') kind of search? Because it is stored in the related Entity.
I guess besides slug property your PostTranslation entity stores some sort of language/locale, e.g. locale property, am I right? I also guess that your website is interlocalized based on some parameter stored in URL (different (sub)domain, query string parameter, path prefix - it's irrelevant), right?
There are at least three solutions that solve your problem:
Abandon the use of ParamConverter and do everything by yourself.
Override DoctrineParamConverter from SensionFrameworkExtraBundle and add support for finding by slug and locale for Post class. I would also suggest creating a little bit more robust solution:
Create Translatable interface that defines getTranslations() and setTranslations() methods and apply it to your Post class.
In your CustomDoctrineParamConverter check whether requested class implements this interface, if so, it means that you're going to search entity based on its translation, that is locale and some locale-unique property.
Now you need some way, to get the name of this locale-unique property. You could create another interface for your PostTranslation class that will define a single method, something like getLocaleIdentifier/UniqueProperty that for PostTranslation will return "slug".
If you know, that you need to find a Post property, based on locale and slug property from its translations assocation you can quite easily create DQL query to do that.
ParamConverter annotation has repository_method property that allows you to use custom method from PostRepository which should retrieve Post entity. The only problem is that built-in DoctrineParamConverter will pass only slug parameter to this method. Your repository will have to informed about current locale in some way. This could be achieved in many different ways, here's one of them:
Create LocaleAware interface with a single method setLocale($locale).
Implement that interface in PostRepository
Create event listener that listens for kernel.request event:
Iterate through all Doctrine's repositories.
Check if given repository implements LocaleAware interface.
Inject request's _locale attribute into repository.
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 would like logic like the following:
-> controller- > call to Model class (that extend model with the entity,manager)- > the function in model will call to getRepository() and use funcion that dealing with the DB.
How can I do that? When I call to Repository I must have an entity, and if I have an empty entity the error is that I must have primary column with id.
As the first comment says, you should not call the repository directly from the entity class. You have several options here (descending by the code quality)
Refine the logic to invert the control flow
Define a service, which accepts the entity, the repository and does the stuff
$service = new EntityStuffService($repository);
$service->doTheStuff($entity);
Declare a relation
Just declare a realtion within your class and filter it manually. Doctrine PersistentCollection implements Selectable, so you can just filter it using the ->matching($criteria) call.
http://doctrine-orm.readthedocs.io/en/latest/reference/working-with-associations.html#filtering-collections
The ugliest way
Doctrine has the ObjectManagerAware interface, which allows you to inject the object manager into the entity on hydation completion. This will allow you to implement and kind of AR patters and other spaghetti-code and I strongly recommend you not to do this.
https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Persistence/ObjectManagerAware.php
You can implement this interface and store the ObjectManager inside the entity to do any kind of operations with it.
I am using DDD now for quiet some time, it took some time to get used to and separate everything. But am now stuck at updating my entity ...
Setup
Now I have a repo interface that defines the following methods
/**
* #param AccountEntity $account
* #return AccountEntity
*/
public function create(AccountEntity $account);
/**
* #param AccountEntity $account
* #return mixed
*/
public function update(AccountEntity $account);
My repo does exactly 0 in the function because it passes it to the mapper, which in turn creates/updates the data. So far so good.
The application service has the method create which accepts an array, the array is validated and if valid it will use an EntityBuilder to create the entity. (Entity requires the data by __construct). If the data is invalid it will throw an exception.
Now my issue is how to handle my update in the application service.
I get an array of data, just like the create, in the update and an id of the entity.
Should I use an hydrator to loop over the array and update the fields in the entity and then throw it to my repo.
cons, I then have an entity hydrator and builder.
pros, it is easy in use
Should I just validate the data and throw the array + id to the repo and let him figure out what to do
cons, just looks wrong
pros, again easy to make
Should I do toArray or something similar on my entity, merge that with the form data & then use the entity builder to build the entity again and throw the entity then to the repo
cons, don't think an entity should have a toArray function
pros, sounds like it encapsulates the task of building the entity in one place so that seems right.
?
So in short, how to convert an array with data to an entity, or how to save it. I am not using Doctrine in any way, and not planning to
First of all, your input data (array) should be validated somewhere at the controller level, to ensure is in the correct format (we're not talking about business rules, just formatting).
Then your entity can have something like this
class MyEntity
{
public function update($data)
{
//update properties, enforce the relevant business rules
//perhaps events are generated
}
}
The controller will probably use a service method to do the updating. The service will ask the repository for the entity, eventually creates the input format the entity expects it (if there is a difference) then calls the update method .
Then you send the entity to the repository which takes care of persisting it. Remember that the Repository is there to save/restore your entities not to change them.
This should probably have been a comment, but that requires 50 rep...
You should have a look at this article about datamappers: http://www.sitepoint.com/integrating-the-data-mappers/
I have been exactly in your situation, and the articles by that writer (Alejandro Gervasio) helped me immensely.
I have a Yii application with two separate models, Domain and Page. Domain has a unique field, so I set up a rule ('domain', 'unique') and also create an action that creates a new record if the field is new, otherwise uses the existing record, and returns the ID:
$domain_model=new Domain();
$domain_model->domain=$domain;
if(!$domain_model->save()){
$atts = array('domain'=>$domain);
$domain_model=Domain::model()->findByAttributes($atts);
}
return $domain_model->id;
This works fine, but within a Page controller I want to call this same function during a page insertion action. I can't figure out the best DRY method to do this with Yii. I can't access other model controllers, so I don't know where to put this function to make it accessible both within and outside of the Domain MVC.
Define a behaviour that does this stuff, and attach to any class you want to use it.
Use of Component Behavior
A component supports the mixin pattern and can be attached with one or several behaviors. A behavior is an object whose methods can be 'inherited' by its attached component through the means of collecting functionality instead of specialization (i.e., normal class inheritance). A component can be attached with several behaviors and thus achieve 'multiple inheritance'.
Behavior classes must implement the IBehavior interface. Most behaviors can extend from the CBehavior base class. If a behavior needs to be attached to a model, it may also extend from CModelBehavior or CActiveRecordBehavior which implements additional features specifc for models.
To use a behavior, it must be attached to a component first by calling the behavior's attach() method. Then we can call a behavior method via the component:
// $name uniquely identifies the behavior in the component
$component->attachBehavior($name,$behavior);
// test() is a method of $behavior
$component->test();
An attached behavior can be accessed like a normal property of the component. For example, if a behavior named tree is attached to a component, we can obtain the reference to this behavior object using:
$behavior=$component->tree;
// equivalent to the following:
// $behavior=$component->asa('tree');
A behavior can be temporarily disabled so that its methods are not available via the component. For example,
$component->disableBehavior($name);
// the following statement will throw an exception
$component->test();
$component->enableBehavior($name);
// it works now
$component->test();
It is possible that two behaviors attached to the same component have methods of the same name. In this case, the method of the first attached behavior will take precedence.
When used together with events, behaviors are even more powerful. A behavior, when being attached to a component, can attach some of its methods to some events of the component. By doing so, the behavior gets a chance to observe or change the normal execution flow of the component.
A behavior's properties can also be accessed via the component it is attached to. The properties include both the public member variables and the properties defined via getters and/or setters of the behavior. For example, if a behavior has a property named xyz and the behavior is attached to a component $a. Then we can use the expression $a->xyz to access the behavior's property.
More reading:
http://www.yiiframework.com/wiki/44/behaviors-events
http://www.ramirezcobos.com/2010/11/19/how-to-create-a-yii-behavior/
I don't remember Yii exactly, but I believe there's a "beforeSave" callback that you can use for your Domain model. That way no matter what, when you save a domain model, it will always call the "Check if this id already exists before saving the model."
Then afterwards you'll simply do $domain->save();, followed by $domain->id, whether or not it previously existed.
We have an Yii-based PHP application which does some generic actions (like "Share" with social networks or "Buy" in internal web shop) on different types of objects.
Right now developers use the class constants to separate objects of different types. Like so:
in model:
class Referral extends CActiveRecord {
//... a lot more stuff here...
const ITEM_TYPE_PRODUCT = 'product';
const ITEM_TYPE_DESIGN = 'design';
const ITEM_TYPE_BRAND = 'brand';
const ITEM_TYPE_INVITE = 'invite';
const ITEM_TYPE_DESIGNER = 'designer';
//... a lot more stuff here...
}
then later in some controller:
// calling static method of Referral and pass a type IDs to change it's behavior
$referral_params = Referral::buildReferallParams(
Referral::TYPE_PINTEREST,
Referral::ITEM_TYPE_PRODUCT
)
This usage of class constants has led to major code duplication which I want to move away.
I personally think we should really add a lookup table for types, like so:
CREATE TABLE `item_type` (
id int primary key auto_increment,
name varchar(255)
);
And make a Yii model class named ItemType to extract IDs from the table with.
But it leads to another problem: we need to use this type IDs in the code anyway and will need to do so for a long time. We need to make a symbolic names for IDs somehow. Right now the call like Referral::ITEM_TYPE_PRODUCT is very convenient, and to change it to Yii-flavored ItemType::model()->findByAttributes(array('name' => 'Product')) is totally unacceptable.
I want to avoid maintaining the same list of class constants (which is duplicated now through our codebase) in the ItemType because each addition of new type will require addition of new constants and it's just a out-of-sync problem waiting to occur.
So, the question is as follows: how to make an ActiveRecord for a lookup table equally useful as the 'enum'-like set of numeric constants?
I came with the following somewhat beautiful solution, using the subclasses of ItemType:
ProductItemType::id(); // returns lazy-loaded ID for 'Product' item type
BrandItemType::id(); // the same for 'Brand' item type
// ... and so on
But if requires five subclasses of single base class right now and maybe another half of dozen more later. Is there any viable architectural solution?
EDIT
Problem with duplication is this: class constants declaring type IDs become redefined in every class which needs to somehow differentiate between different item types. I know that the most "true" solution would be to invert this inside out and move the features which depends on the type of object to the objects itself, but we have legacy code without any test coverage and this solution is just a dream right now. Right now all I want to do is remove this duplication. And constants, too.
Well if you want all these defined one time, and to take from the database. That means you need to do a behaviour, have static like methods to retrieve these (so constants will become functions), you will need to create the proper magic method __call to override these non existent functions to call your database, and you can attach this behavior to any yii class you are using.
Use of Component Behavior
A component supports the mixin pattern and can be attached with one or several behaviors. A behavior is an object whose methods can be 'inherited' by its attached component through the means of collecting functionality instead of specialization (i.e., normal class inheritance). A component can be attached with several behaviors and thus achieve 'multiple inheritance'.
Behavior classes must implement the IBehavior interface. Most behaviors can extend from the CBehavior base class. If a behavior needs to be attached to a model, it may also extend from CModelBehavior or CActiveRecordBehavior which implements additional features specifc for models.
To use a behavior, it must be attached to a component first by calling the behavior's attach() method. Then we can call a behavior method via the component:
// $name uniquely identifies the behavior in the component
$component->attachBehavior($name,$behavior);
// test() is a method of $behavior
$component->test();
An attached behavior can be accessed like a normal property of the component. For example, if a behavior named tree is attached to a component, we can obtain the reference to this behavior object using:
$behavior=$component->tree;
// equivalent to the following:
// $behavior=$component->asa('tree');
A behavior can be temporarily disabled so that its methods are not available via the component. For example,
$component->disableBehavior($name);
// the following statement will throw an exception
$component->test();
$component->enableBehavior($name);
// it works now
$component->test();
It is possible that two behaviors attached to the same component have methods of the same name. In this case, the method of the first attached behavior will take precedence.
When used together with events, behaviors are even more powerful. A behavior, when being attached to a component, can attach some of its methods to some events of the component. By doing so, the behavior gets a chance to observe or change the normal execution flow of the component.
A behavior's properties can also be accessed via the component it is attached to. The properties include both the public member variables and the properties defined via getters and/or setters of the behavior. For example, if a behavior has a property named xyz and the behavior is attached to a component $a. Then we can use the expression $a->xyz to access the behavior's property.
More reading:
http://www.yiiframework.com/wiki/44/behaviors-events
http://www.ramirezcobos.com/2010/11/19/how-to-create-a-yii-behavior/