Good day, citizens!

I would be very interested to know how you solve a completely classical problem about storing directories in a system that uses Spring MVC 3 + JSP as a view .

Namely:

(1, simple case): there is a certain set of lines that need to be stored, shown and somehow used. Example: the usual directory of cities.

(2, difficult case): there is a certain set of entities, each of which has fields that are used in a similar way; that is, it is not just a reference book, but also an entity that will be used in business logic. Example: a class containing external web service settings: address, passwords, attribute names, etc. There are many such services, the user chooses what to use.

How to organize the display and storage of this in the system?

I see such options:

1) ENUM
convenient to show in JSP:

 <form:select path="webservice"> <c:forEach items="${enumList}" var="enum"> <form:option value="${enum.name}"><spring:message code="${enum.label}"/> </form:option> </c:forEach> </form:select>

- essentially hardcoded

2) Keep everything in the table and read.
+ easy to change through the interface
- it is not clear how to show in JSP . Where can I get resource names to use as option names in selects? Unless to put in the table the names of spring-resources, but it looks strange.

3) Union: count such entities from the base and inject them into ENUM . Is it too?

Where is the perfect option?

  • As I understand it, do you want to load all reference books into objects of classes, and then somehow use them? (this is for the second version) - Anton Mukhin
  • Yes, that is right. But I don’t know how beautiful it is to pick up signatures for the interface to them (that which usually clings through <spring:message code="myparam.name"/> ). Do not push these myparam.name into the table. Although on the other hand than this worse hardcoded parameter names. - KutaBeach
  • And I wonder how you can inject database data into ENUM? - Anton Mukhin
  • Well, enum can have fields, something can be entered into them. But whether it is not ugly, I'm not sure. - KutaBeach

1 answer 1

You can refer to the good old principles of the PLO, and think and act objects. Those. for each specific task its own object, which is responsible only for itself.
For one task, one object, for the second task - the second. This gives the advantage that if the customer once again wants to bother you and change some functionality, it will be easier and safer. Storage, it seems to me, should not be done in the system. That's why it is a database that stores data and issues it when necessary. In the same place, in a DB, all system on the most fast and productive search / insert is constructed.

You can add a brief example. Here, you have several tables. And it is necessary to make a sample of them and the data, beautiful and without all the excess, send no jsp . Decision:
create an object некотораяВыборка sort in which all this is created and the getData() method getData() ready for sending to the page (or in Spring , and then to the page).

As for spring:message (some messages on the page, interface elements, as I understand it), I think that we should not save these explanations / messages in the database. This applies only to the interface part, and it should be with the interface part, and not with the Java software code. Those. I want to say if you, the programmer, send it to the database, and somehow programmatically retrieve all these messages, when the designer comes, he will not do anything with your message . And at least it’s easy to get into the .properties file.

  • Thanks for the reply, Anton! This is what I don't like about this scheme: let's say there is a certain list box where I list options from the directory. If you do not store spring: message in the database, I can’t easily add items to this list box. In fact, I will have to hardcode: if so, then show this message, otherwise it will be different. This is of course not very good. To get around you can only store the codes of messages in the database or in enume. - KutaBeach
  • Well, if there are so many different messages that will be displayed in a list, then maybe it’s good to put them in the database. But in ENUM , as far as I know, you cannot dynamically add fields. If possible, I will be very surprised and ask to show how to do it. In principle, there are examples when entire HTML pages are stored in the database (for example, DLE , PHP engine). - Anton Mukhin