[thelist] force a human intervention requirement for signu ps oraccess to resources

david.landy at somerfield.co.uk david.landy at somerfield.co.uk
Thu Feb 12 04:18:12 CST 2004

Hi Guys,

Does anyone know how to divide up website functionality in an MVC-compliant
site? I'm building a database front-end in jsp, and my plan so far is to
have a single controller jsp page (the Controller) which receives all
requests, updates the database as neccessary via javabeans (the Model), then
routes requests to various different display-type jsp's (the View). Is this
the way to go, or am I missing something? :-) The corporate standard here is
Struts, but I think it'll take me too long to learn to get up and running
quickly... (I've only just learned Java and jsp ;-S) 

My theory is that at least if I make it MVC-compliant it'll be upgradable
later to Struts without ripping the whole app apart. 

The view will contain a standard grid view (using an html table) for each
table in the db, along with a page to add/edit records for each table. These
add/edit pages will have the data entry boxes at the top of the screen,
followed by the standard grid displaying a pageful of rows from the relevant
table. I'm toying between either (a) copying and pasting html into each of
those pages to display the grid, or (b) using a <jsp:include to pull in the
grid code. Which do you think would be more effective?

The way I see it, the advantage of (a) is that it'd be easy for a later
developer to follow what's going on; also each add/edit/view page gets their
own version of the code so they can be customised to look different. 

On the other hand, using the include in (b) would ensure that a change made
to the grid in the original code (eg adding a new column) would
automatically appear in the other pages. 

What do you think? Views very welcome.

Thanks in advance,

If you are not the intended recipient of this e-mail, please preserve the
confidentiality of it and advise the sender immediately of any error in
transmission. Any disclosure, copying, distribution or action taken, or
omitted to be taken, by an unauthorised recipient in reliance upon the
contents of this e-mail is prohibited. Somerfield cannot accept liability
for any damage which you may sustain as a result of software viruses so
please carry out your own virus checks before opening an attachment. In
replying to this e-mail you are granting the right for that reply to be
forwarded to any other individual within the business and also to be read by
others. Any views expressed by an individual within this message do not
necessarily reflect the views of Somerfield.  Somerfield reserves the right
to intercept, monitor and record communications for lawful business

More information about the thelist mailing list