The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

JSP/HTML/CSS dynamically built/cached; too much good thing?

I've come into a team as a contractor.  We have a quote proposal transaction with popups designed to run in a browswer.  We use javascript.  Not sure of all details. 

The screens are built by java programs.  There are tables and tables of information on attributes of the screen elements.  This strikes me as too much of a good thing. 

Isn't the proper way to build screens to use Struts, custom tags, or JSF?

Comments are appreciated.  Feel free to ask if you need clarification and I'll do my best.
Carpe Diem Send private email
Friday, December 24, 2004
 
 
Are you saving that they're storing page markup in database tables? Are they using Java servlets?
John Topley Send private email
Friday, December 24, 2004
 
 
It sounds like they might be using a tool I know called Dynamic Client System developed by Innuvo.  All UI is developed in Java code and at deploy time is compliped into javascript to render the screen actions.  Is that what you are talking about?  Check it at http://www.innuvo.com/.
Phil Smith Send private email
Friday, December 24, 2004
 
 
I think code generation is far better if you can do the mapping. Why custom create code for everything when you can just generate it from an algorithm?
son of parnas
Friday, December 24, 2004
 
 
The markup is stored in database tables, and there are numerous java data objects, renderers, and business rule decision making.  We use SQL to retrieve from queries sometimes joining 8 or so tables.

I've been working on this team for five months, and I have yet to work on JSP page.  All I do is work on the functionality of rendering screens.

It seems like a waste of time and doesn't separate the roles of presentation, controller and model.
Carpe Diem Send private email
Friday, December 24, 2004
 
 
I also haven't worked on any servlets or EJB's, even though we nominally use them.  Is it common practice to store markup in tables?  The screens are build based on previous user choices and product values.  That seems to be the justification for using so many classes to create a screen.
Carpe Diem Send private email
Friday, December 24, 2004
 
 
Storing markup in tables sounds totally fucked up to me. This makes editing and version control a royal pain in the butt.
Egor
Saturday, December 25, 2004
 
 
Editing a database isn't hard. You can version control the load scripts along with everything else. So putting stuff in a database makes as much sense is hard coding or stuffing it one of a million xml files.
son of parnas
Saturday, December 25, 2004
 
 
I only want to say this once: keep out the foul language.  Does JoS have a TOS?
Carpe Diem Send private email
Saturday, December 25, 2004
 
 
"Is it common practice to store markup in tables?"

It's not something I've come across. It sounds like a bit of a maintenance headache.
John Topley Send private email
Sunday, December 26, 2004
 
 
Another thought: use templates instead of custom designing every page.  But seriously, it's hard to know what to do when you need to write numerous tools just to maintain your screens.  I'll have to read up on JSF?
Carpe Diem Send private email
Sunday, December 26, 2004
 
 
Storing markup in the database makes no sense unless they are strictly used as templates, with the actual dynamic content inserted later.

I agree that templates in general would have been a much more maintainable solution... but good luck rolling that in if they already are storing the pages and content in the database.

---Seeker
Seeker Send private email
Sunday, December 26, 2004
 
 
Saying something is stupid or makes no sense without specifying any actual reasons, isn't all that useful.
son of parnas
Sunday, December 26, 2004
 
 
Thanks guys, and let's keep this civil.  I read about the value of separating presentation from the controller/actions because then you could hire a web designer to do your screens.  The programming model adopted here requires extensive java/programming experience.  I would think management would direct its staff to avoid mixing programming and UI layers at all costs.  I'm learning more as I go, the people I work with are very helpful although not always working with a firm grasp of the architecture (which was outsourced).
Carpe Diem Send private email
Monday, December 27, 2004
 
 
Hey Carpe Diem - lighten up. 

Poopy asshole fucked !
Huh
Monday, December 27, 2004
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz