blaine wrote:
I hope that the other participants don't assume that it's impossible to successfully separate page designer role from Java developer (both roles are development roles), just because some people have been unsuccessful at it. It entirely depends on the personnel skill sets and app, whether it makes sense to separate these roles. If the Java or DB team document their data objects properly, the tag libs are documented properly, and the Java team documents their Java beans properly, the roles can be separated. The ability to have this separation is a documented goal of the original J2EE specifications. It's pointless to argue against it since there are plenty of people (I work with several) whose job is web page development and who do not know Java. Another writer on this has opined that every capable Web front-end developer knows Java: There are plenty of bright, artistic, and capable people who do great front end work without knowing Java, using HTML, CSS, JavaScript, JSP. This setup won't work with Java developers who don't know how to document their work properly, or are too condescending to work alongside Gui developers who don't know Java..
Regardless of people listing their opinions as "Facts", web designers' jobs do not end when mock-ups are finished, except for trivial apps. Ask any full-time, dedicated web page developer if all they do is create mock-ups.
This setup is uncommon for small apps, but it is standard operating procedure at large companies with dedicated Gui developer personnel.
blaine wrote:I would personally prefer the new JForum to keep page editing so it can be done by non-Java-programmers.
Large projects are iterative affairs where the UI concerns are not just turned over to Java developers at release 1.0.
It takes an impressive lack of insight to conclude that JSP developers need to have access to Java code and code/compile/deploy systems in order to see what they are working on. I will stay on topic and not list the methods here.
Others can argue why they imagine this system is impossible. They are just arguing from a stance of ignorance. Anybody who recognizes the business advantages can take the initiative and make it work.
blaine wrote: ...
It takes an impressive lack of insight to conclude that JSP developers need to have access to Java code and code/compile/deploy systems in order to see what they are working on. I will stay on topic and not list the methods here.
...
blaine wrote:It's hard to exaggerate how much it simplifies maintenance and upgrades if you make the delivered web app read-only. It also supports more deployment models (where app server does not explode the war file to disk, where the app files are distributed to cluster peers, etc.)
Instead of having your app write files inside the exploded web app directory branch, you read customizations (like hibernate.cfg.xml, spring-app.xml) and write files under an external location. The external location can default to a directory like ${user.home}/jforum and this location can be changed in a portable way by a system property. I know that ${user.home} isn't always writable... that's what the system property is for.
Container facilities like Tomcat's manager web app or WebSphere or WebLogic admin console can then be used to redeploy, without any risk to "data". For out-of-the-box users, upgrades can be performed without backup by just undeploying the old war and deploying the new war. For Java code customizers like myself, you can continually rebuild your war with ant and redeploy, without needing to back up and restore installation settings and runtime data.
Rafael Steil wrote:We are not going to use Struts.
Rafael
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |