So we have an ITEM, TV, LCD and PROJECTOR.
We have DAO and Service object for TV, LCD and PROJECTOR that also are ITEM objects. Meaning that those tables all extends the ITEM table.
You can access these items through an UI and an API service.
Right now, I am in the need to put specific UI configurations that are not related at all with the API. Lets say that I need in the UI a configuration for each item to display or not display an image of the item on it, lets call it showImageFlag. This value can be modified from the Item's UI, this is a checkbox.
I've been thinking about a few options here:
Add a column SHOW_IMAGE_FLAG to the ITEM table and it's DAO and service object. On the service object put a #JSonIgnore flag so it is ignored on the API side, but we can use it normally in the UI. ------- My concern with this approach is that in the future we might need more configuration for these items or maybe others than tv, lcd and projector. So this will always will push us to add a new column to the table. Another concern is that we might be migrating all form post ui to use the REST API, so we are going to have to do something about that JsonIgnored property.
A ITEM_CONFIG (id, item_id, configuration, value) table FKed to the ITEM.id with a key/value approach to save N configuration related to specific items. So on every web controller I will be passing a ItemConfig object with all configurations related to the requested ITEM. -------- My concern with this one, is how should I map this to the form (using spring mvc) and how should I persist when the configuration changes on the UI.
Please free to comment and suggest any new option for this.
Second point is more feasible.
Also,you can have another service layer which will be responsible for saving mapping part and below service layer there will be UI controller layer which will actually map the changes to its undergoing presentation i.e. UI layer.
I would think about adding Item(id)--ItemUI(item_id) as 1:1.
Then you can add all your UI specific about an item to the ItemUI attributes.
Also you could request UI configuration with a second call to another service.
From the two options I'll go for number one. The only problem that comes up is when the UI is migrated to use the API. In that case you won't be using #JsonIgnore, instead you will be using Json Views.
You can create classes representing specific views on your data and use them to tag your attributes with #JsonView(MyView.class). Finally, you can serialize your beans using objectMapper.writeValueUsingView(out, beanInstance, MyView.class);
In your case you could create an view class MyAPIView and annotate all fields but SHOW_IMAGE_FLAG with #JsonView(MyAPIView.class) (Note MyAPIView is an empty class used for tagging purposes, with no logic nor attributes).
If you call objectMapper.writeValueUsingView(out, beanInstance, MyAPIView.class); you wont serialize the SHOW_IMAGE_FLAG attribute. If you call objectMapper.writeValue(out, beanInstance) you will serialize the attribute.
You must determine at runtime the view to be used. If you are using OAuth you could select view depending on the connected client.
Eventually, you can create several views and apply inheritance. Take a look at jacksons doc.
I ended up with a config table for items called ITEM_CONFIG (ITEM_ID, UI_PROPERTIES)
On the UI_Properties I save a JSON string, which is mapped to a String propertie on the DAO model, but as a HashMap<String, Object> on the service model.
I have a converter that maps the value from the dao model to the hasmap on the service object, "automatically".
On the controller (in the BaseController, parent of every WebController [not rest]), I added a method to get the config from the ItemConfigService and then set the value on the response (Model in SpringMVC) using the hasmap key as the parameter and the value as the parameter value.
This is working very clean and we haven't had any issues since last week.
Related
I'm creating a REST api specifically for serving my android application requests. Some of the operations exposed by the API just queries the database and returns data to be displayed by the app.
However, I would like these operations to return a generic REST response, so that the data queried from the database are displayed on the UI without the need to create a response attribute for each field.
For example, i have an api operation which returns a list of transactions from the database which are displayed inside a list view.The attributes shown inside each list view item depends on the type of the transaction.
So i thought of two approaches for constructing my ResponseTransaction class:
1- Just create an attribute for each database field which needs to be displayed: id, description, amount, time, date, type ... and based on the type , android would detect which attributes to display inside each item.
2- Second approach is to tell android what to display through returning a generic response holding: HashMap(Label, Value) where values represents necessary database fields.
By using the first approach, I should update apk each time i add a new transaction type.However this is not the case in the second approach which just requires a new service deployment.
So do you think that the second approach is the best way to go for creating generic REST responses for the database operations and is it a good practice to couple REST responses to the client if we are sure that the service is only used internally by our android or web application.
Please advise.
My problem is that I know description of some process and want to search some standard technology implementing such approach, but don't know the correct name. In short, I need "objects-templating" engine. In details, I need to automate the following process:
Admin/operator declares object description: fields, types, such as a
programmer declares a class, but not in the code, but in the web
interface.
Created in web-interface entity forces automatic change of the DB structure - a table is created or existing table updated.
Another person (user) presses presses add button and see automatically generated view-form for creating or updating an entity.
Sum up- I'm looking for a technology which allows to create new objects with UI,automatically change DB structure, create view-forms for rendering/saving entity. If possible, form-action handler must also be created automatically, ie it generates a servlet / request mapping in controller, which inserts to DB/loads from DB.
I'm interested in Java technologies/frameworks as my question is asked in Java Web-App context.
It seems Spring Roo is what I need.
I have list view with let's say four columns: id, name, description and value. Then I want to redirect to item details view. I'm using angular-ui ui-router. What is better practice:
Use shared service where I can store selected object on list view (ex. call setSelectedItem) and on details page I should call getSelectedItem.
Pass in URL selected item id (ex. my_app/#/details/SELECTED_ITEM_ID) and on details view call REST service for item details ex. POST my_app/services/getItemDetails
you can use both of them...
it is a common way to share object between controllers via services but it should be managed carefully.
passing id of and object and get data from server is a trusted way, but if you have already full object in your list view and you are sure that there will be not change on the object then you maybe do not want to make an extra call to server...
as I mentioned in the second argument if you just want to share object without making a call you use resolve attribute of angular-ui router as well... you can find detailed information in here...
but do you have a guarantee that object will not change at this time ?
In a controller I can get model by declaring Model/ModelMap typed parameter. In handler interceptors and in view rendering I get the same. But how do I get the model from the arbitrary class, which can get hold of ApplicationContext or web request? I just don't want to use model.addAttribute() all the time and would like my service automatically put objects into model.
The idea is that you shouldn't. Your controllers are the entry point of your application, so you get them there, and pass them as arguments to the layers below.
I am using jquery/jsp/java ejb3.0/sql server.
The User interface requirement (a jsp page) is a grid of checkboxes, ~10 rows high and up to about ~30 rows wide (this varies), it represents a linker table for a many-to-many table relationship.
The checkboxes will be populated from the database (if row present in linker table, then checkbox is checked).
The user can then check/uncheck whichever, as many times as possible. On submit any changes should be saved to db.
The changes will consist of deleting a row if unchecked(and if checked/row present before), and inserting a row if checked (and unchecked/no row present before).
My problem is, what is the best way to implement this ? Using ajax to update database using checkbox onchange event is not appropriate. I want it to be a submit form event.
I'd try and decomplexify the situation by taking a step back and introducing a simple bean to represent the "metadata" - i.e. the 300-or-so true/false values.
Actually, when dealing with that many fields, you'd probably use a mother-bean containing child beans which hold conceptually-related fields together. e.g.:
public class MotherBean {
private UserSettingBean userSettingBean;
private UserRelationshipBean userRelationshipBean;
private UserPreferencesBean userPreferencesBean;
...
}
So your "web tier" becomes a straightforward CRUD controller for the MotherBean; the sort of thing that gets done every day. You could even use something like Spring Roo to build up the scaffolding for that.
Then, when you pass that bean down into your lower layer(s) (you may or may not have a traditional "service" or "business logic" layer in this design), you have a DAO that translates the relationship metadata into the actual many-to-many relationships. Given the number of fields we're talking about, I'd again suggest to delegate out this work into sub-DAOs (for want of a better term) that deal with related links.
Obviously, the "get" path is the same thing in reverse. You ask the MotherBeanDAO for the metadata related to user 1234, it asks its delegate DAOs for the child beans, wraps them up and the resultant MotherBean gets passed all the way up to the web front end.