I want to add a field for all my users as I do with Data Object Classes.
Is this possible?
yes, you can add a new field as per your requirement to the user class which will be reflected to the whole user data object class.
Related
How to configure User entity, to have OneToOne() relation with Profile entity with a extra condition. ie
if the User type is TYPE_A, then the User entity should have relation with ProfileA
or
if the User type is TYPE_B, then the User entity should have a relation with ProfileB
and so on...
Is it possible to achieve something like this?
I am trying to pre define and possibly pre populate a field in CouchDB every time a new document is created by the user. That is until a user enters a different value the initial value that I created will stay.
According to this article it is not possible to do so: (CouchDB: Pre-filled fields when adding new documents?)
I was just wondering if there was an update to this. Or is there an easier way to do this?
I'm working on a project based on Jhipster,and i will update update user entity; i will add external field to user entity for example add birthday field to my user entity.
how i can do it?
thanks
There's nothing in JHipster to help you doing so.
It's up to you to modify the generated code for your needs:
add your field to the User entity and UserDTO
create a new Liquibase changelog to add a new column in user table
modify html form and controller
I am using Liferay 6 for portal Development .
During Creating Users under Liferay , i need to add some extra Fields also ??
Please let me know if this is ppossible or not ??
Please see the screen shot attached here , and also please let me know in which table this will be stored in Database ??
Yes, you can use Custom Attributes functionality for liferay entities (in your case, User) and can add as many extra fields as necessary for each liferay entity.
Custom field for the user-entity can be created through:
Control Panel -> Portal -> Custom Fields -> User.
And programmatically can be created as follows:
user.getExpandoBridge().addAttribute("yourCustomFieldKey");
Then set the value as:
user.getExpandoBridge().setAttribute("yourCustomFieldKey", "valueForCustomField");
If your custom field is already present you can check like this:
if (user.getExpandoBridge().hasAttribute("yourCustomFieldKey")) { ... };
The data is stored in tables prefixed with "EXPANDO":
EXPANDOCOLUMN: stores the custom field key and other settings
(contains the tableId refrences)
EXPANDODATA: stores the custom field value for the key (contains the
columnId and tableId refrences)
EXPANDOTABLE: stores for which liferay entity (user) are you adding
the custom field
EXPANDOROW: stores linking information between a user and its values
(contains tableId and userId refrences)
Hope this helps.
yes, you can add custom fields to user-entity and add them the field-values to user:
user.getExpandoBridge().addAttribute(...);
Custim field for the user-entity you can create by Control Panel Portal->Custom Fields or programmaticaly at liferay start.
The data will be stored in ExpandoValue tables.
Just in case somebody try to retrieve the values from the custom fields and is having problems with null values returned by the method user.getExpandoBridge().getAttribute("yourCustomFieldKey") (even when you followed the threads about permissions), I found other way to retrieve the Custom Fields values:
ExpandoTable table = ExpandoTableLocalServiceUtil.getDefaultTable(user.getCompanyId(), User.class.getName() );
ExpandoColumn column = ExpandoColumnLocalServiceUtil.getColumn(table.getTableId(), "yourCustomFieldKey");
ExpandoValue expandoValue = ExpandoValueLocalServiceUtil.getValue(table.getTableId(), column.getColumnId(), user.getUserId());
Then you can do a simple (if the field is text) expandoValue.getString();
Not so pretty, but do the work.
User creation page in liferay can be customized. You can infact decide which fields to be present in the user creation page. More about this in here.
Use the following commands if you get the permission problem in adding or setting attribute.
user.getExpandoBridge().addAttribute("yourCustomFieldKey",false);
user.getExpandoBridge().setAttribute("yourCustomFieldKey", "valueForCustomField",false);
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.