I have three different entity attributes which have to be "pre-parsed" before they get saved in the datebase.
Same attributes have to be "post-parsed" before being shown to users.
There are several different controllers actions which are setting/getting these attributes. Currently I preparse/postparse this attributes basicly in every of these methods.
How should I handle this? I was thinking about putting it directly into entity but that is not the place for that. Especially because I need the same pre-parse functions in a few entities.
Basically these function has to run before every setter and getter call.
if you have a t4 template that generates the model code, then it's relatively easy to change property setters/getters to do the data pre and post-processing.
You may want to look at Data Transformers - http://symfony.com/doc/current/cookbook/form/data_transformers.html
UPDATE:
Another, and probably the most appropriate, method would be to use Doctrine EventListener or EventSubscriber.
http://symfony.com/doc/current/cookbook/doctrine/event_listeners_subscribers.html
http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/events.html
In your case, you need to listen/subscribe to prePersist, preUpdate, and postLoad events.
Related
The Typo3 documentation describes #Validate annotations which can be used to validate parameters for a single controller action:
https://docs.typo3.org/m/typo3/book-extbasefluid/master/en-us/9-CrosscuttingConcerns/2-validating-domain-objects.html
However, it is only described how to add a custom validator for a single parameter. It is possible to add multiple validation annotations, but then again each of them can validate just a single parameter, not multiple parameters in combination.
First question: It is possible to add a validator which checks multiple parameters, or even all parameters, of a specific controller action?
Of course the obvious workaround is to combine multiple arguments in a single argument, using e.g. an array or an object. But this is especially annoying if the arguments themselves are already (independent) model objects.
Second question: If the answer to the first question is "it's impossible", what is the recommended way to combine the arguments of a controller action?
(e.g.: Should one use an array? That seems to be not preferred in Typo3 due to the lack of type safety and other features. Should one create a class? But which kind of class would that be? A Utility class? A Model class? But that model class would then need suppressed persistence? This seems to be all messy.)
I'm using version 9.5 of Typo3, but if things are different in version 10, that would be interesting as well.
To the best of my knowledge I suggest using a data transfer object (DTO) for this purpose.
If your models have to be validated in combination, but do not belong to any other entity, combining them in a DTO is probably the best way to go. Consequently the validation logic is then clustered in a single validator.
See also this blog post about DTOs: https://usetypo3.com/dtos-in-extbase.html
I have a problem that's probably easy to fix, but I don't find the right way to do it.
I have the following situation:
I am building a web application where I use several forms. One of the forms uses and displays two Entity Framework models that have a 1:1 relation. It's one entity for all BaseData (common Data) and one entity for AdditionalData (specific Data). The form's Model is of type AdditionalData, which has a NavigationProperty of type BaseData.
When I want to save this "form" i.e. the two entities - what is the best way to do that?
Do I call two Actions seperately, like "Save(BaseData) then Save(AdditionalData)"(how?)?
Do I redirect from one Save Action to the Other one (also how?)?
Do I need to build a new Model to accomplish what I need (maybe with a special ModelBinder) or do I only need a special ModelBinder?
Can I manually invoke the ModelBinder for the "BaseData" manually from the Save Action of the AddidionalDataController?
Am I doing it completely wrong in the first place?
Thank you for any help!
I would like to know when entities in a certain database table are either created or updated. The application is essentially a CMS, and I need to know when changes are made to the content so that I can reindex them for searches.
I know that the autogenerated LINQ to EF class has overridable methods for when certain fields change, but I need to know when the whole object is created/updated, not just a single field. I tried putting it in OnCreated, only to find that meant OnObjectInitialized and not OnObjectInsertedIntoDBTable xD
I did some searching and came across this link. The "Entity State" section looks like its what I want, but I'm not sure how to use this information. Where do I override those methods?
Or perhaps there is a another/better way?
(I also need to know this for another part of the system, which will send notifications when certain content is changed. I would prefer this code to execute automatically when the insert/update occurs instead of placing it in a controller and hoping hoping I always call that method.)
You need to get ObjectStateEntry(s) from the ObjectStateManager property of the ObjectContect.
var objectStateEntries = this.ObjectStateManager.GetObjectStateEntries();
This entries contain every object state you've pulled down per context and what kind of actions where performed on them.
If you are using EF4 you can override the SaveChanges method to include this functionality. I've used this technique to audit every change that occurs in the database instead of triggers.
A generally accepted way to pass all data to a view is to have a single data model with references to both your domain model and additional data for things like drop down lists (DDL).
However, partial views (view templates too) receive only a portion of the main model, not able to access the root of the Model sent to the original view. So if your DDL lists are not static, how do the partial views get the data?
Is there a way using [Data Annotations] to reference a method which could return the possible values of a field, then use this in the partial view's DDL? Where would this method exist, in the repository?
Links or C# code examples would be very helpful.
There is no built in Data Annotations attribute that could do what you ask.
You could create your own attribute that contains a reference to a Type and the name of a static method that you can then invoke via reflection from your partial view.
Where you would place such a method depends on what you are doing, though I still think that gathering all the inputs in your controller would be better. You can always set extra items in the ViewData collection and pass those into your partial views.
I would like to experimentally apply an aspect of encapsulation that I read about once, where an entity object includes domains for its attributes, e.g. for its CostCentre property, it contains the list of valid cost centres. This way, when I open an edit form for an Extension, I only need pass the form one Extension object, where I normally access a CostCentre object when initialising the form.
This also applies where I have a list of Extensions bound to a grid (telerik RadGrid), and I handle an edit command on the grid. I want to create an edit form and pass it an Extension object, where now I pass the edit form an ExtensionID and create my object in the form.
What I'm actually asking here is for pointers to guidance on doing this this way, or the 'proper' way of achieving something similar to what I have described here.
It would depend on your data source. If you are retrieving the list of Cost Centers from a database, that would be one approach. If it's a short list of predetermined values (like Yes/No/Maybe So) then property attributes might do the trick. If it needs to be more configurable per-environment, then IoC or the Provider pattern would be the best choice.
I think your problem is similar to a custom ad-hoc search page we did on a previous project. We decorated our entity classes and properties with attributes that contained some predetermined 'pointers' to the lookup value methods, and their relationships. Then we created a single custom UI control (like your edit page described in your post) which used these attributes to generate the drop down and auto-completion text box lists by dynamically generating a LINQ expression, then executing it at run-time based on whatever the user was doing.
This was accomplished with basically three moving parts: A) the attributes on the data access objects B) the 'attribute facade' methods at the middle-tier compiling and generation dynamic LINQ expressions and C) the custom UI control that called our middle-tier service methods.
Sometimes plans like these backfire, but in our case it worked great. Decorating our objects with attributes, then creating a single path of logic gave us just enough power to do what we needed to do while minimizing the amount of code required, and completely eliminated any boilerplate. However, this approach was not very configurable. By compiling these attributes into the code, we tightly coupled our application to the datasource. On this particular project it wasn't a big deal because it was a clients internal system and it fit the project timeline. However, on a "real product" implementing the logic with the Provider pattern or using something like the Castle Projects IoC would have allowed us the same power with a great deal more configurability. The downside of this is there is more to manage, and more that can go wrong with deployments, etc.