In a JSF page I have to display the data from an entity.
This entity has some int fields which cannot be displayed directly but need to be translated into a descriptive string.
Between them some can have a limited number of values, others have lots of possible values (such as a wordlwide Country_ID) and deserve a table on the Db with the association (ID, description).
This latter case can easily be solved navigating via relationship from the original entity to the entity corresponding to the dictionary table (ID, description) but I don't want to introduce new entities just to solve translations form ID to description.
Besides another integer field has special needs: the hundred thousand number should be changed with a letter according to a rule such as 100015 -> A00015, 301023 -> C01023.
Initially I put the translation code inside the entity itself but I know the great limits and drawbacks of this solution.
Then I created a singletone (EntityTranslator) with all the methods to translate the different fields. For cases where the field values are a lot I put them inside a table which is loaded from the singletone and transformed in a TreeMap, otherwise the descriptions are in arrays inside the class.
In the ManagedBean I wrote a getter for EntityTranslator and inside the jsf I use quite long el statements like the following:
#{myManagedBean.entityTranslator.translateCountryID(myManagedBean.selectedEntity.countryID)}
I think the problem is quite general and I'm looking for a standard way to solve it but, as already stated, I don't want to create new 'stupid' entities only to associate an ID to a description, I think it is overkill.
Another possibility is the use of converters Object(Integer) <-> String but I'm more comfortable in having all the translation needs for an Entity inside the same class.
Your question boils down to the following simple line:
How can I display a field different from id of my entity in my view and how can I morph an integer field into something more meaningful.
The answer is that it depends on a situation.
If you solely want to input/output data, you don't need id at all apart from the possible view parameter like ?id=12345. In this case you can input/output anything you want in your view: the id is always there.
If you want to create a new entity most possibly you have a way of generating ids via JPA, or database, or elsehow besides the direct input from the user. In this situation you don't need to mess with ids as well.
If you want to use information on other entities like show user a dropdown box with e.g. a list of countries, you always have the option to separate label (let it be name) and value (let it be id), or even have a unique not null column containing the country name in your database table that will serve as a natural identifier. If you'd like to get data from the user using an input text field you always can create a converter that will do the job of transforming user input strings to actual entity objects.
Regarding the transformation of your integers, you've actually got several choices: the first one is to attach a converter for these fields that will roughly do 301023 -> C01023 and C01023 -> 301023 transformations, the second one is to write a custom EL function and the third one is to prepare the right model beforehand / do the transformations on-the-fly.
Related
Since #sys.airport only exists for the default English locale, I want to create a custom entity that emulates it for other locales.
From what I've read here, you can put subentity types into the value fields, say, the system entity #sys.geo-city:city and a custom entity #usr.iata-code:iata, and it will match either one or the other.
But I don't understand how you would tell Dialogflow which city and which IATA code go together, so that Dialogflow (ES) would know to send the complete object {"city":"Amsterdam", "iata": "AMS"} to the webhook after matching either "Amsterdam" or "AMS", as it does happen with #sys.airport.
Thanks for any input!
It will be difficult to create a custom entity that works just like #sys.airport. The #sys entities are special and can do somethings custom entities can't, for instance, pairing values together.
As you pointed out, you can put multiple entities together in one single entity by using Composite Entities, but the only thing this does is allow you to recognize two values made up from other #sys or custom entities in a single entity. It doesn't give you the option to create pairs between the values of the entities.
If you would want to create something like this, you would need some code that does a look up in a dictionary or list. So when "AMS" is matched, the code fills in the missing property "Amsterdam" or vice versa.
According to the help pop up:
ID
This field's value represents the script ID, used to identify this
record for scripting purposes. It is a text field.
Internal ID
This field's value is a read-only system-generated unique identifier.
It is an integer field.
Both fields seem to uniquely identity a record type.
One is a string, one a integer.
The string ID is used for searches and
loading of records, but I've also seen Internal ID used when
referring to a record type from a lists point of view.
Can anyone provide the reasoning behind having two identifiers and when to use one versus the other when scripting?
The major difference is that you (as the creator of a custom record or script) are in complete control of the text ID. You can establish patterns and best practices for defining these IDs, and it will make it very easy for developers to identify record types just by looking at the string ID. You have no control over the numeric ID. When looking at code, it is much easier for me to determine what records I am referring to if it looks like:
nlapiSearchRecord('customrecord_product', null, filters, columns);
nlapiResolveURL('SUITELET', 'customscript_sl_orderservice', 'customdeploy_sl_orderservice')
as opposed to looking at:
nlapiSearchRecord(118, null, filters, columns);
nlapiResolveURL('SUITELET', 13, 1)
I'm not even sure the second nlapiSearchRecord actually works, but I know that nlapiResolveURL can be written that way.
That said, if you simply let NetSuite generate the text ID, you'll end up with generic IDs like customrecord1, which I find no more useful than the numeric ID. It is a good practice to explicitly specify your own IDs.
Furthermore, the numeric ID can vary between environments (e.g. Sandbox could be different than Production, until a subsequent refresh occurs). If you are following good migration practices, then the text ID should never vary between environments, so your code would not have to make any kind of decision on which ID to use based on environment.
Rarely have I found myself referencing any record, whether native or custom, by its numeric ID; scripts are always using the text ID to reference a record type.
I'm trying to figure out the best way to handle a requirement I have for an Orchard module I'm building.
I have a ContentPart that has a few fields. One field is a ContentPicker that allows for multiple items to be associated to the part. The rest are descriptive information.
The issue I have is that I actually need to be able to include more than one of this ContentPart into a ContentType. I need to create a ContentType that has exactly 3 of this part.
Should I be making this into a field instead of a part? Is it even possible to have a ContentField that has other fields in it?
Or, should I somehow use all the same models and data structures, but somehow define it as 3 distinct parts?
Just wondering what the best practice to do something like this would be.
You can only have one part of each kind on a given type. You can't have fields that have other fields in it (instead - take an existing field and extend it with custom stuff).
As I understand, the actual problem is "how to make groups of fields with some metadata for each group", right? If so, there are a few approaches to solve the problem:
Create a custom field based on Content Picker (basically - take existing Content Picker and extend it with your metadata) and use this without the need for a separate part
Create one part to hold only the metadata for each field attached to it and attach 1 or more fields to it
Create 3 distinct parts. Parts should be thought of as extensions that add some unique features to an item. If you think it's logically ok to have 3 parts then go for it.
I have a stored procedure that is run and returns a result set into a model (using EF 5).
As I'm looping through the result set, I simply want to get the name of the column in the model that is used to hold the data.
How can I achieve this?
Would it be something like below:
var myCustomers = DbContext.Database.SqlQuery<Customer>
("exec SelectCustomers").ToList();
foreach (Customer cust in myCustomers)
{
}
Displaying the value "myCustomers[0].Address1" during runtime will display the actual value inside that field, but how can I simply extract the column name?
If I try something like below, the index value is always -1 and I don't know what I'm missing. I've used it dozens of times.
int Idx = myCustomers[0].Address1.IndexOf(".").ToString();
"-1"
I don't think you can reliably do that. EF consists of 3 layers - object layer (also called O-Space - your types), conceptual layer (also called C-Space - a model in EDM terms) and store layer (also called S-Space which described the database). The mapping between O-Space and S-Space is more or less 1:1 - so a property on a class maps to an entity property in the OSpace model. However there are a few strategies of mapping C-Space to S-Space like Table Per Hierarchy (TPH), Table per Type (TPT), Table per Concrete type (TPC) and Entity Splitting (you can find more details here: http://blogs.msdn.com/b/adonet/archive/2010/10/25/inheritance-mapping-a-walkthrough-guide-for-beginners.aspx). It is also possible to use your own name for a property that will be different from the name of a corresponding column in the database. In the simplest cases property names will match column names but oftentimes it won't be the case. At runtime the information about mapping is stored types that are mostly internal and you cannot access them. The information about mapping is populated from the Msl artifact the describes mapping between C- and S- space. You could try parsing this artifact (it's an Xml file) but it's not an easy task if you need to support all different mapping strategies.
I am designing an application that will display dynamically-generated forms to the user who will then enter values into the form fields and submit those values for persistence. The form represents an employee evaluation.
One use case allows an administrator (from HR) to define the form fields. They should be able to create a new form, add/remove fields from a form and mark a form as 'deleted'.
The second use case is when a manager views the form and enters values into the form fields for a specific employee. They should be able to save the values at any time and recall the saved values when viewing the form again for the same employee.
Finally, when the manager is satisfied with the values they've entered for that employee, they can 'submit' the form data which persists the flattened data into the data warehouse for reporting purposes. When this is done, the 'working' copy of the data is removed so the form will display empty the next time they view it for that employee.
I am not concerned with the front-end at this point and working on the back-end service application that sits between the client and the data store. The application must provide a course-grained interface for all of the behavior required.
My question is how many aggregate roots do I actually have (and from that, how many repositories, etc)? Do I separate the form definition from the form data even though I need both when displaying the form to the user?
I see two main entities, 'EmployeeEvaluationSchema' and 'EmployeeEvaluation'. The 'EmployeeEvaluationSchema' entity would have a collection of 'FieldDefinition' value objects which would contain the properties that define a field, the most basic being the name of the field. The 'EmployeeEvaluation' entity would have a collection of 'FieldValue' value objects which contain the values for each field from the definition. In the simplest case, it would have a field name and value property. Next, the 'EmployeeEvaluation' could have a reference to 'EmployeeEvaluationSchema' to specify which definition the particular evaluation is based on. This can also be used to enforce the form definition in each evaluation. You would have two repositories - one for each entity. If you were to use an ORM such as NHibernate, then when you retrieve a 'EmployeeEvaluation' entity, the associated 'EmployeeEvaluationSchema' would also be retrieved even though there is a dedicated repository for it.
From your description it sounds like your objects don't have any behavior and are simple DTOs. If that is the case maybe you should not bother doing DDD. Can you imagine your entities without having getters? There are better ways to do CRUDish application than DDD. Again this is only valid if your "domain" does not have relevant behavior.