Using the (MS) Enterprise Library, Validation Application Block (VAB), you can include attributes in your code to define rule sets. I have applied the attributes to the properties of a class and I have defined two rule sets (the properties fall into two validation groups). Unfortunatly there is some overlap between the two rule sets (some properties are in both groups).
Can a validation attribute belong to multiple rule sets and what does the syntax look like? If this is not possible, is there a work-around?
The work-around is simply to duplicate every validation attribute for every rule set.
Related
In Hibernate Search 5 I had several custom bridges that populated the same field. That was handy so that I can perform a query on just one field. Now if I try to do it I receive this error:
HSEARCH600034: Duplicate index field definition: 'attributes'. Index field names must be unique. Look for two property mappings with the same field name, or two indexed-embeddeds with prefixes that lead to conflicting index field names, or two custom bridges declaring index fields with the same name.
I have not found a way to get an existing field from the PropertyBinding Context when implementing the PropertyBinder, only the documented way to add new fields:
IndexFieldReference<String> attributesField = schemaElement
.field("attributes", f -> f.asString())
.toReference();
Am I missing something or is no longer possible and I need to add new fields?
How can I reuse a field in several bridges in Hibernate Search 6?
At the moment, you cannot.
This limitation is a side effect from the (many) sanity checks that Hibernate Search 6 performs on startup, which prevent common mistakes and indirectly allow a more intuitive behavior in the Search DSL.
Your options are pretty much this:
Either you refactor your bridges to regroup all code that contributes to the same field in a single bridge (either a TypeBridge, or a PropertyBridge applied to a non-persisted getter that returns an aggregated list of all values you're interested in).
Or you change your bridges to each contribute to its own field, and change your search code to target all these fields at once; most (if not all) predicates allow targeting multiple fields in the same predicate.
The second solution is also the recommended way of indexing, since it produces more accurate relevance scores.
EDIT: If you go for solution 2, this (not yet implemented) feature might be of interest to you: https://hibernate.atlassian.net/browse/HSEARCH-3926
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'm on Enterprise Architect 14. I have a component diagram containing an interface User and two classes Employee and Customer, which both realize interface User.
Furthermore I created two instances, one of each class and specified the values of the attributes via Features & Properties > Set Run State....
Next I created a component with 2 attributes, one of type Employee and one of type Customer. Then I created an instance of the component.
Now I would like to set run state of the component instance by assigning ArbitraryUser to the Employee attribute and ArbitraryCustomer to the Customer attribute of the component instance. According documentation this should be possible (see here).
At run-time, an Object instance can have specific values for its attributes, or exist in a particular state. To model the varying behavior of Objects at run-time, use instance values selected from the 'Select ' dialog and run-time states or run-states.
However I could not figure out how to do so. Can someone help me?
AFAIK that is not possible.
I'm not sure what the quote from the help really means, but I've only ever been able to type a value for the run state.
An partial alternative would be to use associations rather than attributes to model such relations. Then you can create a link as an instance of the association to relate instances of Employee or Customer with instances of a ArbitraryComponent.
This solution doesn't work for datatypes, but it seems a bit far fetched to start modelling instances of datatypes.
Which one is better (Pros and Cons) (Maintenance, Extensibility) :
1.Has a Request entity have 3 different reference (navigation properties) to Signature:
2.Has a Request entity have collection of Signature, which each Signature has Signature Type:
Model 1
This model pretty much carves your business rules in stone. There can only be three types of signatures and there can only be one each. Any change in these rules requires a database change, which is always a pervasive change.
Apart from that, there's a potential pitfall when you work with disconnected entities that you want to re-attach to a context. If one (or two) of the Signatures are the same (business rules permitting) you must heed the exception that two entity keys are added twice.
Model 2
This gives more freedom (extensibility), but that means that you need coded business rules to enforce the rules I mentioned for Model 1. On the other hand, it would allow more people to approve a request, for example.
Maybe an even better model would be to make SignatureType a flagged enum, so a signature can have multiple types and the signatures don't have to be repeated (again: the business rules permitting). This would avoid the potential multiple key exception I mentioned with Model 1.
So I would prefer model 2 (with flagged enum), because I like to express business rules in code, not in database constraints.
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.