Thanks Diane and Hassan for your replies. Very helpful and much appreciated. David David Landy, IT Consultant Business Intelligence Somerfield/KwikSave +44 (0) 117-301-8977 david.landy at somerfield.co.uk <mailto:david.landy at somerfield.co.uk> Don't be afraid to try something new. An amateur built the Ark. Professionals built the Titanic. Author unknown. -----Original Message----- From: Hassan Schroeder [mailto:hassan at webtuitive.com] Sent: Saturday, 14 February 2004 16:55 To: thelist at lists.evolt.org Subject: Re: [thelist] force a human intervention requirement for signu ps oraccess to resources david.landy at somerfield.co.uk wrote: > 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. I can understand your feeling that learning Struts might be too time-consuming, but it sounds like you're going to be re-inventing that same wheel, so it may not gain you that much time. And you'll miss out on the network of existing Struts developers (including those within your company) to plumb for expertise... But I'm a roll-your-own kinda guy, too, so don't listen to me :-) > 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. I'd avoid copy-and-paste; if you want variations, use multiple include files. Or a smart include that returns different markup based on the requestURI, or other criteria. Using taglibs (JSTL, etc.) heavily, rather than scriptlets, in the "view" pages will also help simplify things for future page maintainers. And since you're doing heavy table work, you might check out the display: taglib -- <http://sourceforge.net/projects/displaytag/>, for ideas if nothing else. HTH, -- Hassan Schroeder ----------------------------- hassan at webtuitive.com Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com dream. code. -- * * Please support the community that supports you. * * http://evolt.org/help_support_evolt/ For unsubscribe and other options, including the Tip Harvester and archives of thelist go to: http://lists.evolt.org Workers of the Web, evolt ! 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 purposes.