Hello,
Please excuse this slightly off topic message, but I felt that this
discussion could be valuable to the group. Please ignore if you find it too
OT. I don't mind suggestions for other forums for this question.
My questions are listed at the end of this email, the rest is background.
We utilize struts on a number of projects. As a user of struts, I am trying
to come up with a good process for developing web apps that helps us manage
the hand-offs between:
(1) Graphic designers (responsible for branding, look and feel, color
schemes, etc.),
(2) Front-end engineers (responsible for realizing the UI using the graphic
designers' guidelines),
(3) Back-end engineers (know struts, java, J2EE, etc.)
In our current process, the graphics designers design the branding, look and
feel, and other graphic elements that make up the user interface. From this
HTML templates are created for the different types of pages in our site.
The front-end engineers then take the page templates and the site map and
create the pages for the entire site. At this point, we have static HTML
pages with hard coded 'place holder' values.
The 'static site' is then passed on to the back-end engineers. They fill in
the dynamic portion of the pages: populating data and other content.
I have a couple of problems with this:
(1) The back-end engineers have to know a lot about HTML. Often they have
to make minor tweeks in the HTML that breaks the page for one browser or
another. I don't think they should have to know all this.
(2) Once the front-end engineers hand off the pages, they consider
themselves done and out of the loop. Global look and feel changes become
very hard to do because the front-end engineers no longer recognize the
pages.
(3) No matter how hard I try, system engineers _still_ put in java code in
the JSP pages.
****
I would like to come up with a solution where:
(1) The front-end engineers to deliver pages that have been unit tested with
test data (not hard coded HTML).
(2) The front-end engineers own or are responsible for the pages through the
lifetime of the system.
****
Ok, the first step is to train our front-end engineers to use JSP and our
custom tags (struts and otherwise).
The second step is to enable the front-end engineers to be able to unit test
each page under a variety of different data inputs. That would require a
number of things:
(1) First, the data the page makes use of needs to be well defined. This
would make the job of interfacing between the front-end engineers and the
back-end engineers easier. However, I don't think there is any standard way
of doing this and no way at all of doing this within the JSP page.
(2) The front-end engineer needs to know how to create the holders for the
data to be rendered within the page. Using struts, this would involve
writing java beans or ActionForm beans. (How are these beans configuration
managed along with the JSP they apply to?)
(3) The front-end engineer needs to compile and deploy the JSP.
(4) The front-end engineer needs a test harness that helps/supports building
data objects, storing them in the appropriate scope (page, request, session,
...), and then forwarding to the page to be tested.
Using XML/XSLT makes some of these steps easier because there is a well
defined way to define the model, the front-end engineer does not need to
create java beans, and the test harness is easier to setup because there are
no data beans to populate.
My questions are:
(1) Does it sound reasonable for front-end engineers to know how to do?
(2) Are there tools that support this activity?
(3) Could a servlet (or some other test harness) be written to help the
front-end engineer unit test their pages?
(4) Is unit testing page rendering something that is automated or
eye-balled?
Any comments will be appreciated.
Sincerely,
James Couball
