Using the Enterprise Library 4.1 Validation Application Block, how can I validate that a collection property contains at least one item?
I'm assuming you mean out of the box. If so, then I don't think there is way to validate directly the number of items in a collection.
These are some other ways that you could try:
Decree that you only deal with null collections and not empty collections and use a Not Null Validator. Not practical, though.
Use self validation and have the object validate in code that the collection(s) have the correct number of items. Will work but it's nice to have the validation in the configuration file.
Expose the collection count as a property. This could be done, assuming an employee collection for example, with an EmployeeCount property on your object that contains the collection or you could create your own custom collections that expose a count property. Then you could use a Range Validator to validate on the Count property.
Create a custom validator that can validate the number of items in a collection -- something like CollectionCountRangeValidator.
If I wanted to develop something quickly, I would probably go with option 3. However, option 4 fits in well with the Enterprise Library approach and also allows your class design to be independent of the validation requirements. Plus you could always reuse it on your next project. :) And does anyone really miss creating their own collections when a List will do nicely?
This is already implemented in the EntLib Contrib.
This is called CollectionCountValidator.
Related
What is the best way to test in JUnit that a collection contains two complex objects?
I know that there is containsInAnyOrder(), but I have no control over the objects, as they are created via a REST API and stored in a database. I need them to be compared by equals, not by reference.
Alternatively, it would be sufficient if I can test whether some of their attributes equal, but since the method the test covers involves AsyncCircuitBreakers, I'm not sure of the order.
How can I make sure, the two objects are created in the database with the data I have in mind?
assertThat(Arrays.asList(array), hasItems(yourItem1, yourItem2));
Don't forget to add equals and hashCode methods to implement in your item class. hasItem is a hamcrest method.
I have a dropdown in wicket 1.4 (part of a form) which shows choices for numbers. Now when a number is selected, I change the status of that number to reserved in database using onUpdate method of dropdown.
Now, I want to create a validator which checks whether selected number is already reserved in database or not (by some other parallel process). But this validator should validate only on value change before onUpdate as the number will get reserved in onUpdate method.
So basically what I want to do is to manually invoke validator when I need and prevent it from getting invoked at other times
Or simply, how to make validate and update event work together
Just curious; why you would want a validator to do this job when you could potentially add a database call method inside onUpdate itself?
You could still create a reusable method to call it from different places and use it. Validator is something you want to use for format/range kind of validations ( This is my choice - not necessarily best one ) and have business logic validations either in service layer or close to DAO layer if I don't have 'service' layer.
I think this will never work. As you validate before the update, there is still a chance that the value was changed by another process.
I would use a nice feedback message telling the user that we were unable to update the number because someone else just did it before you.
I have this idea of generating an array of user-links that will depend on user-roles.
The user can be a student or an admin.
What I have in mind is use a foreach loop to generate a list of links that is only available for certain users.
My problem is, I created a helper class called Navigation, but I am so certain that I MUST NOT hard-code the links in there, instead I want that helper class to just read an object sent from somewhere, and then will return the desired navigation array to a page.
Follow up questions, where do you think should i keep the links that will only be available for students, for admins. Should i just keep them in a text-file?
or if it is possible to create a controller that passes an array of links, for example
a method in nav_controller class -> studentLinks(){} that will send an array of links to the helper class, the the helper class will then send it to the view..
Sorry if I'm quite crazy at explaining. Do you have any related resources?
From your description it seems that you are building some education-related system. It would make sense to create implementation in such way, that you can later expand the project. Seems reasonable to expect addition of "lectors" as a role later.
Then again .. I am not sure how extensive your knowledge about MVC design pattern is.
That said, in this situation I would consider two ways to solve this:
View requests current user's status from model layer and, based on the response, requests additional data. Then view uses either admin or user templates and creates the response.
You can either hardcode the specific navigation items in the templates, from which you build the response, or the lit of available navigation items can be a part of the additional information that you requested from model layer.
The downside for this method is, that every time you need, when you need to add another group, you will have to rewrite some (if not all) view classes.
Wrap the structures from model layer in a containment object (the basis of implementation available in this post), which would let you restrict, what data is returned.
When using this approach, the views aways request all the available information from model layer, but some of it will return null, in which case the template would not be applied. To implement this, the list of available navigation items would have to be provided by model layer.
P.S. As you might have noticed from this description, view is not a template and model is not a class.
It really depends on what you're already using and the scale of your project. If you're using a db - stick it there. If you're using xml/json/yaml/whatever - store it in a file with corresponding format. If you have neither - hardcode it. What I mean - avoid using multiple technologies to store data. Also, if the links won't be updated frequently and the users won't be able to customize them I'd hardcode them. There's no point in creating something very complex for the sake of dynamics if the app will be mostly static.
Note that this question doesn't quite fit in stackoverflow. programmers.stackexchange.com would probably be a better fit
We're looking for a way to document Core Data entities. So far the only real options I've come up with are:
Document externally using UML or some other standard
Create NSManagedObject subclasses for every entity and use code comments
Use the User Info dictionary to create a key value pair that holds a string comment
Option 1 feels like too much extra work and something that will almost certainly be out of date 99% of the time.
Option 2 feels natural and more correct than option 1. The biggest con here is that those comments could potentially be lost if this model class is regenerated using Xcode.
Option 3 feels a little less correct than option 2, but has the added advantage of adding automation possibilities with regards to meta data extraction. For instance, in one of our apps we need to keep a real close eye on what we're storing locally on the device as well as syncing to iCloud. Using the user info dictionary it's pretty easy to automate the creation of some form of artefact which can be checked both internally and externally (by the client) for compliance
So my question is whether it would be inappropriate to use the user info dictionary for this purpose? And are there any other options I'm missing?
Option 2 is what I use every time. If you look at your core data model (something.xcdatamodeld or something.xcdatamodel) you will see something like the picture below.
You can tie your entity to whatever class you want and then put the comments in there. It helps if you keep your entity name the same as your class name to make it obvious what you've done.
Additionally this also gives you the ability to add automation. You can do this by creating custom getters and setters (accessor methods) and a custom description method.
I use option 2 and categories. I'll let XCode generate the NSManagedObject subclasses and use a categorie on each of these subclasses. With the categories I do not loose my changes made in the categories, can document, make custom getter and setters and I am still able to use generated subclasses.
If we speak only about documenting (i.e. writing more or less large amounts of text which is intended to be read by humans) your classes, I'd use the option 2.
If you are concerned with the possibility of Xcode overwriting your classes in the option 2, you may consider creating two classes for each entity: one which is generated by Xcode and always could be replaced (you generally do not touch this file) and one other which inherits from the generated one and in which you put all your customizations and comments.
This two-class approach is proposed by the mogenerator.
Although if you need to store some metadata with the entities which will be processed programmatically, the userInfo is perfectly suitable for this.
I have an dropdown attribute that I am creating during my module setup.
I want to pre-populate this attribute with some values while my module is installing. I can do this no problem, currently by simply storing the values in an array and then creating adding the options to the attribute in the install script.
Where would be the correct place to store these values - in a model? If so would it be a source model utilizing the toOptionArray method? This is technically used for forms so it doesnt seem right. But neither does just storing the values in the setup script.
Any ideas?
Yes, the toOptionArray method would be in line with standard Magento practices.
Typically the toOptionArray() is found in Helpers, if that is what you are asking. Helpers extend far fewer classes, and therefore inherit far fewer methods than models. This makes them much lighter weight for simple tasks like setting up an array of options, provided that they are static.
If the values are stored in a new DB table, and can be expanded upon by the user, it may make more sense to put this in a Model that has direct access to your DB table.