Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Given a .JSP, would there be any reason to store static text in a .properties file, pull the key/value pair, and display it? Is that the best practice / standardized way? If so, why? Or can you "hard code" the static text into the .JSP? Are there benefits (performance, code readability, etc.) with each way?
My response could differ depending on what you are referring to as static text? Storing the values within a properties file is one way of approaching it, but I would advise that you store these types of key value pairs in a database that you could later retrieve and cache at start-up.
This depends on what the "text" is. If it's user-visible, such as form labels, then storing it in a properties file allows you to make use of the built-in i18n capabilities of JSP and similar technologies, and it also permits easy updates in case of typos or such. Externalizing user-visible text is always a good best practice.
If the text is something that's "static" but likely to change on a reasonably frequent basis, then it belongs in a persistent store such as the database you're using for your other persistence, or a document database like MongoDB.
Or you can store your text in the database. I think this is most preferrable way.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
While working on a Java web application I was wondering if my model layer was written as it should be. For instance, let's say we have a table USER in our SQL database which consists of 15 columns. Now, when we SELECT all of the columns with SQL we map it to a Java class, serialize via JSON and send it via network to some View and show it on screen.
In a second scenario, we want to select only 2 columns on screen so we do SELECT c1,c2 FROM USER. Thats where my question comes in... am I supposed to map those columns to a same Java model class? Or should i create a new mapper and class to fit it? Both of the approaches seem to have drawbacks, separate class for each query is more work, but it makes sure you always know what data it contains, rather than checking for nulls or working with optionals, also it prevents you from mapping columns you actually don't need.
What is your opinion? Thanks a lot!
Technically you could reuse the same User class for full 15-attribute as well as partial 2-attribute entity. But that will come with a price. Every time you'll see an instance of User class in the code your will have to think if it's the full entity or the partial? Which fields may or may not be null? This will make it much harder to reason about code.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have just had a not let me sleep doubt about how to name a local variable which stores the text entered by an user (in a text box).
Should I name it 'enteredText' or 'textEntered'?
My main concern is about what comes first? participleSubject or subjectParticiple.
There are some accepted patterns as in events, where it is always onSubjectVerb, e.g. onItemClick ...
I am not sure which is the styling rule for my case (entering text in a TextBox'
I have made some searches on different code repositories and both names are used?
Any idea?
Thanks!
Miguel Ángel
This problem is one of the two hardest problems in computer science, naming things. I think that both are equally non descriptive of what the text that has been entered describes.
For example: what does this text field provide the use the ability to enter? Their name? Then call it userName
More of a matter of taste, I think.
Anyway for me it is a matter of context: if I'm writing a complex class or method with lots of variables and where e.g. there's text entered, text computed and text fixed (i.e. a label), I tend to name them textEntered, textComputed and textFixed, so when I need to access some kind of text the IDE auto completion features easily show me all texts available.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
So I have this app, a Java servlet. It uses a dictionary object that reads words from a file specified as a constructor parameter on instantiation and then serves queries.
I can do basically the same on PHP, but it's my understanding the class will be instantiated on each and every request, and the file will be read again every time. In fact, I did it and it works, but it collapses my humble amazon EC2 micro instance at the ridiculous amount of 11 requests per second or more.
My question is: Shouldn't some kind of compiler/file system optimization be kicking in and making the performance impact insignificant when the file does not change at all?
If the answer is no, I guess my design is quite poor and I should try to improve it. In that case, my second question is: What would be the best approach to improve it?
Building a servlet-like service so the code is properly reused?
Using memcached to keep the words file content in memory?
Using a RDBMS instead of a plain text file and have my dictionary querying it?
(despite the dictionary being only a few KB of static data and despite having to perform some complex queries such as selecting a
(cryptographically safe) random word from those having a length
higher than some per-request user setting and such?)
Something else?
Your best bet is to generate a PHP file which contains the final structure of the dictionary in PHP code. You could then include() that cache file into your code or write a new one when the file changes. You should store it on the filesystem, no databases. You could cache it in memory as well. But I don't think this is really needed at this point.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am trying to figure out whether it is a better idea to keep String Constants as static value or in a properties file. If i keep in properties file, will it be costly to read always from properties file.
What will be better in-terms of performance.
Performance is not the key... Design is the one.
Is your String a property of your application or not?
But the answer of your question is: of course, reading a static field is faster than reading from a file. 'seems obvious
it depends on what you want ?
if you want the property to be accessed by all class and can be changed you use static
if you don't want your property to be changed you can use a constant one
Depends what you mean by constant.
If it is actually a constant then it is best stored in an enum.
If it is some sort of property - i.e. something that might be changed then a properties file is best.
Performance shouldn't be a concern here.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm fairly new to android programming and have a couple years of university experience in Java. I am planning on writing an app for android that will require me to see what category an item entered belongs.
As an example, if a user inputs 'apple', that data must be placed under a 'fruit' category. So in other words I require a data file that will be able to tell me what category the item is in or alternatively the user can add an item to a category if it is not yet categorised.
I am wondering what would be the best way to store this data. Should I use an xml file, database file, text file or what? It would be necessary to perform look-ups and also insertions.
Thanks in advance
I think this question is more of a personal preference, but I would use XML in this case. You can have the structure predefined with distribution of your app, and modify/write the file at runtime. Its easy to read and understand, and just as easily modified. Simply universal.
Sqlite has its positives in large forms of data, but can be much more complex for something that doesn't need much detail.
<index>
<category name="fruit">
<item>apple</item>
.....
</category>
......
</index>
A simple for loop through the categories, and see if the item is present, else add it.
Hope this helps, happy coding!
Android has SQLite built in...for your purposes I'd go with that.
http://developer.android.com/guide/topics/data/data-storage.html
http://developer.android.com/training/basics/data-storage/index.html