Printable View
Two ideas:Quote:
Originally Posted by ramoq
1) If you want some fields to not be updateable, but ok to be viewed then annotate the field with @Column(updateable=false)
2) If you want different fields or some subset to be displayed then you need to have a different object as the forrm backing bean and map to the domain object. You can create a reflective utility to automate the mappings.
I often see recomendations along these lines for directory/package structurues. Is this a good idea???? see below:
core
---- src
---- ---- main
---- ---- test
web <-- i'm assuming all controller releated items go in here?
---- src
---- ---- main
---- ---- test
webapp
---- src
---- ---- resources
---- ---- ---- images
---- ---- ---- css
---- ---- ---- js
---- ---- war
---- ---- ---- WEB-INF
---- ---- ---- ---- jsp
---- ---- ---- META-INF
Yes, this ("main/test", "src/resources/webapp" approach) is actually the de facto standard for the directory structure for modules - originally introduced by the Maven project. Except , instead of your "core" and "web" modules you should have any reusable modules with the functionality that should not be built into your [web] application but rather externalized. In other words, each module - in addition to your web application module - should represent a distinct functional domain, not just some core, UI, or persistence. Each such module should define its own model. service, and persistence classes, which would allow it to be fully independent and distributable with various applications, if necessary. Among these "external" modules there normally would be some kind of "commons" or "core" module that contains common interfaces, classes and utilities that may be used by any other modules. Each specific application is just another separate module in the project, and it will use other modules as dependencies (e.g. packaged as jars in the web app's war file.) This also allows you to have different project configurations, e.g. loading sources for some modules and using the others as jar dependencies, while other developers are working on updates to those modules. You will avoid the necessity of having a huge monolithic project with thousands of classes where nothing can be taken out and worked on independently. (That happens all the time!) I have tried to explain all that in some of my earlier posts.Quote:
Originally Posted by ramoq
Your controllers and other web-app related java classes must live under the web application's modu;e's java/src/main tree. Also, you got it wrong with the contents of the resources folder of your webapp.
The structure for a web application module should look like this:
yourappname
-----src
--------main
-------------java
------------------com.yourcompany.yourappname
-------------------------------------------------your java packages here (including controllers, form classes, etc.)
-------------resources (properties files, templates, etc)
-------------webapp
---------------------css
---------------------js
---------------------images
---------------------WEB_INF
--------------------------config
--------------------------jsp
--------------------------tags
--------------------------tld
------------------------web.xml
---------------------index.jsp
--------test
-----pom.xml
-----target (build artifacts such as .war file will be placed here...)
I would highly recommend to follow these guidelines, and, most importantly, to use Maven for your project/build configuration and management. It is a very powerful and flexible tool. It is 100% IDE agnostic, and all major IDEs fully support Maven. This means, you will be able to install a Maven-configured project in any such IDE in minutes by pointing the IDE to the Maven configuration files (POMs) instead of using the IDE-specific project settings. Take a look at the Maven site, it is worth spending some time getting familiar with Maven.
http://maven.apache.org/guides/getti...ted/index.html