[Architecture] Frameworks, tools, plugins and etc - What next

[Migrated From Jforum.net]

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.

The specs also say a lot of other things we all know are unnecessary for most shops.
Do you have someone with the sole role of being an application assembler?

Yes, the separation is possible, but yet unnecessary in most cases.
I would not hire a team of Java developers unless at least one of them is comfortable with HTML.
If nobody in your team is comfortable with HTML/JS as well as being solid with Java, then you have a bad team mix.

The key term here is "role" as opposed to person.
A person can have multiple roles and a mixture of roles is often necessary for efficiency sake.

HTML developers are good for creating mock ups.
Their creative process cannot be matched when it comes for creating appealing web templates.
However, it always requires a good application developer with good HTML knowledge to properly template the mock ups using the currently known templating engines (tiles/sitemesh/etc.).

I have yet to see or hear of a single shop where an individual has the single role of using data beans and displaying the content on the various page template fragments.

[originally posted on jforum.net by Brahim B.]

[Migrated From Jforum.net]

I am trying to hire a replacement for such a worker right now. (PM me if you have an applicant for presentation-side work). There happen to be a lot of web developers out there with light scripting experience (like CGI, PHP, Perl), who are easily taught to use EL and JavaBean notation. I am confident that others will recognize this species of web developer who is not suited for Java coding.

Yes, middle-tier developers need to know HTML. Ignoratio elenchi. This does not effect my position that dedicated page-developers do not need to know Java in some environments.

Point granted, that the specs are impractical in many instances. Point also granted that some entirely dedicated J2EE roles are very uncommon.

What is common is for mixed-role people to

have ongong (not just mock-up) web page development as one skill (incl. very basic scripting)

to not have the aptitude or desire to learn Java

yet to have the aptitude to learn to use JSP and tag libraries

I like to train these people into JSP developers when the opportunity arises. Haven't had 100% success, but when it works, they've built up their resume and I have a more productive worker. I see how if you only ever assign Java developers to do JSP work, the separation doesn't matter as much. Since my training tactic relies on the role separation of the J2EE spec, I happen to like this one .
[originally posted on jforum.net by blaine]

[Migrated From Jforum.net]

An ongoing web look and feel development is a sign of bad planning.

I am not saying that the mock ups should be written in stone, but I am saying that a good mock up is at least 95% of what's graphically needed and with the remaining 5% being ironed out as you go.
At the end of this stage, you should have all the HTML, CSS, graphics, and some JS (who does the JS depends on the application and the extent to which JavaScript is used in the application).

Again, once the mock up is templated/coded, you will need the full running application to have a view of it.
With the application being in development, that would not be the proper stage to evaluate of how things should look over all.

Once you've passed the mock up stage, there should be very little the page designer is able to do that your Java front-end developer is not able to do.
All the artistic points should have been covered by then, and all that should be left are the technical points.

I think there is greater value in training your Java developer with HTML/CSS/JS than to train your web template developer with JSP and the likes.

From my experience, the best web template developers have always been people with graphic background that have learned HTML/CSS/Web User Experience doctrines and are best kept in the static content world.
They should be easily movable in between different project platforms (J2EE, .Net, PHP, or others) without any significance.

Last, the way J2EE application projects are configured these days, giving a user access to the JSPs is also giving them access to the Java code.
It is also bringing them a world where they have to code/compile/deploy to see the rendering of what they are working on.

To that, I say no.
[originally posted on jforum.net by Brahim B.]

[Migrated From Jforum.net]

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.

[originally posted on jforum.net by blaine]

[Migrated From Jforum.net]

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.

Nobody talked exclusively of a waterfall approach.
I made my arguments fully aware of iterative processes.
Mock ups too can/do undergo an iterative process.
Yet, each iteration would look as I have described.
The mock up change requests phase would still precede the actual code development phase for the iteration.

In compiling, I mean compiling the JSPs and not necessarily the Java code.
Yes, you will just give them jar files... and deal with jar versionning issues... fine....
Yes, all app servers will auto compile the JSPs for you if you did not pre-compile them... fine...
The point here being that your page developers will need a running version of the application (app server, DB, etc.) to render and view their changes if we use your approach.

I am very curious of the techniques you know of that would enable the page developer to render the pages without deploying the application.
I am also hoping you are not just referring to the WYSIWYG preview feature of some IDEs (mostly commercial too).
You need more than that to fully evaluate the user experience.

Just because you can go to some great length to make something work does not mean you should.

I personally think there would be a great value in making JForum easily skinnable.
Art is still and will always be a matter of personal taste.

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.
...

Please, do share your knowledge.
That list the methods would be very much on-topic.
[originally posted on jforum.net by Brahim B.]

[Migrated From Jforum.net]

Re: Brahim B.

FYI, you're welcome to keep making up straw men to argue with, to re-define "compiling" to mean running an app server, and to deny that the well-worn practices below work, but I won't be wasting any more time on this argument. If anybody wants to know any details, and you are not starting with the assumption

(You haven't thought of it) == (It is impossible OR not worth the effort)

, PM me.

A:

1. The least demanding on the JSPers is a shared dev or integration app server with content on a network drive. For example, at ICF Consulting, the content dev team would just edit the existing, live files on their M: drive. These content developers aren't even aware when we switch the dev server from one host to another, and from Tomcat to JBoss and back, and most of them have never deployed a web app.

3. More confident JSP developers can and do copy a pre-configged App server to their PC and do the same editing locally. They need to know how to run the start and stop script and use the Gui to deploy war files-- they do not ever work with Java code and they never do anything that would qualify as "compiling" to anybody who understands the word. They certainly do go to the developers occasionally with app server problems, but that is no different than any other technical problem with their PC or work.

4... Other variants, all of which I have participated with, are for the content developers to edit remote content using remote shells, Webdav, and Gui tools.

Every team project I've worked on for many years has had a shared dev site available, whether using this strategy or not. People who know the technologies discussed will recognize that they are easy to set up. (Obviously not those who concluded it's not worth the effort before they had a clue about how it could be accomplished).

Sometimes the coders throw up stub JSPs (even zero files), sometimes they set up something so the JSP developers can make arbitrary JSPs driven by a single controler (e.g. with Spring MVC's UrlFilenameViewController).

[originally posted on jforum.net by blaine]

[Migrated From Jforum.net]

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.

I got sick of implementing this pattern over and over on my projects, and just made a generic/pluggable implementation of it, for Spring web apps, in the form of a XmlWebApplicationContext subclass. It works on any app server (including those that don't explode war files), and allows for runtime settings under a container-level-configurable directory (hereafter called runtime config dir, defaulting to ${user.home}/<APPNAME>):

Spring PropertyPlaceholderConfigurer property files

Switching between Spring bean files in the war itself

Merging in of custom Spring bean files

A ProperytPlaceholder entry is automatically added for the generated runtime config dir path,so that spring bean files (both provided and custom) can easily load additional resources/configs/customized-pages from there.

Does support multiple instances of the same web app on single app server instance (e.g. jforum1, jforum2).

A limitation is that I'm not supporting reading of resources by classpath in this way, only as files/urls. (Due to classloader idiosyncrasies across app servers, it would be impossible to implement reading of external resources by classpath in a reliable and portable way). This is no problem for new apps, since it's just as easy to load either way from Spring, but could make difficulties for legacy apps.

Hooking this system into an existing Spring web app consists of setting 2 to 4 new context-params in the web.xml:

  <context-param>
    <param-name>contextClass</param-name>
    <param-value>com.admc.web.ExtConfiggableAppContext</param-value>
  </context-param>
  <context-param>
    <param-name>defaultRtAppName</param-name>
    <param-value>exim-webapp</param-value>
  </context-param>
  <context-param>
    <param-name>requiredMetaPropKeys</param-name>
    <param-value>option.configs</param-value>
  </context-param>
  <context-param>
    <param-name>requiredSpringPropKeys</param-name>
    <param-value>lcn, other</param-value>
  </context-param>[

The default runtime config directory is generated from ${user.home}/ + the defaultRtAppName, by default.

If Rafael or anybody else wants to look at the class for ideas, or use it, drop me a line.
[originally posted on jforum.net by blaine]

[Migrated From Jforum.net]

I say, stay freemarker. It layers itself in nicely for customization.

Surprised no one said Struts 2.0. It works well with Spring, and works well with all the view technologies (jsf, velocity, freemarker, jsp etc).

Its not the same old animal it was with Struts 1.x
[originally posted on jforum.net by sutter2k]

[Migrated From Jforum.net]

Has there been any final decision on the decision of the frameworks? I see a lot of back and forth, but no answers. There are multiple frameworks that can be used to achieve the same end result and any one chosen will help to standardize the current heavily-custom-written version.
[originally posted on jforum.net by Studlow]

[Migrated From Jforum.net]

We are using JSP 2.1, Spring 2.5, Hibernate 3.3 and VRaptor.

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Hi Rafael:

I think you looking good on the back end, but you may want to consider a view technology that is more likely to be around in 5 years than VRaptor.

After looking through the thread it looks like you are looking for a good templating technology which is easy to hook to your back end. Have you looked at using Sun's Facelets? Very wide usage, has a very nice templating system, and would allow you to use Ajax enabled JSF controls like Apache MyFaces, or Suns JSF web controls. That front end would definately add some longevity to the code.

Let me know and I can show you a little more.
[originally posted on jforum.net by MarkHanfland]

[Migrated From Jforum.net]

Rafael Steil wrote:We are not going to use Struts.

Rafael

I saw in the official new version of Struts 2X had many good features such as

http://struts.apache.org/2.1.2/index.html

Build! Deploy! Maintain!
Build!
Easy startup - Jumpstart new projects with our bootstrap tutorial and template application or Maven archetype.
Improved Design - Code clean against HTTP-independant framework interfaces.
Enhanced Tags - Code less with stylesheet-driven form tags that provide their own markup.
Stateful Checkboxes - Avoid special handling with smart checkboxes that know when they are toggled.
Flexible Cancel Buttons - Go directly to a different action on cancel.
First-class AJAX support - Add interactivity and flexibility with AJAX tags that look and feel just like standard Struts tags.
Easy Spring integration - Inject dependencies into Actions using Spring without glue code or red tape. (Plexus support also available.)
Enhanced Results - Do more with speciality results for JasperReports, JFreeChart, Action chaining, and file downloading.
POJO forms - No more ActionForms! Use any JavaBean to capture form input or put properties directly on an Action class. Use both binary and String properties!
POJO Actions - Use any class as an Action class -- even the interface is optional!
Deploy!
Easy plugins - Add framework extensions by dropping in a JAR. No manual configuration required! Bundled plugins add support for JavaServer Faces, JasperReports, JFreeChart, Tiles, and more ...
Integrated profiling - Peek inside Struts2 to find where the cycles are going!
Precise Error Reporting - Flip directly to the location and line of an error.
Maintain!
Easy-to-test Actions - Test Struts2 Actions directly, without resorting to mock HTTP objects.
Intelligent Defaults - Skip obvious and redundant settings. Most framework configuration elements have a default value that we can set and forget. Say it once!
Easy-to-customize controller - Customize the request handling per action, if desired. Struts2 only does what you want it to do!
Integrating Debugging - Research problem reports with built-in debugging tools.
Easy-to-tweak tags - Customize tag markup by editing a FreeMarker template. No need to grok the taglib API! JSP, FreeMarker, and Velocity tags are fully supported.



[originally posted on jforum.net by dnybz]