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

david.landy at somerfield.co.uk david.landy at somerfield.co.uk
Tue Feb 17 02:23:59 CST 2004


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.


More information about the thelist mailing list