 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Tomcat - JSP/Servlet container | | Struts - A MVC web framework | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | JSP - A mailing list about Java Server Pages specification and reference | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | |
Struts & Hibernate
|
|
|
| | | Can you suggest a suitable pattern? | Can you suggest a suitable pattern? 2006-03-21 - By Kallol Bose
Back
Hi Soms,
What if we use a single class and drive it via a properties or a xml
file.this file will contain the fields and their validations, In future if
the config items do increase coressponding changes could be made in the
file.
Regards,
Kallol.
-- -- Original Message -- --
From: "Soms S" <somasundram.balakrushnan@(protected)>
To: <J2EEPATTERNS-INTEREST@(protected)>
Sent: Tuesday, March 21, 2006 12:36 PM
Subject: Can you suggest a suitable pattern?
> Design Issue:
>
> Motivation:
> There are as many as 37 config items; each config item has different
> fields and each field entry has different set of validation rules. The
> config items are sequentially arranged and have dependency between each
> other (the next config entry depends on the values provided to the
> previous config entry). We need a mechanism to configure all 37 config
> items.
>
> One approach is to have a Wizard kind of set up to configure the items.
> That is, display each config item and its associated fields in separate
> screens; when user chooses next, based on the current input we can
> generate the next config item.
>
> But using a Wizard will require 37 screens (one for each config item)
> and if the GUI is to be generated with a tool (for eg: Netbeans) then
> using 'Generation Gap' pattern would double the classes required 37 * 2
> = 74 classes! Besides if config items increases that would increase the
> number of screens which in turn would double the classes required; this
> obviously is a class explosion!
>
> I guess this is a generic issue and I'm wondering if there is any
> alternative or a design pattern to address this.
>
> Thanks, Soms.
>
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com
> J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)
>
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
-- ---- ---- ---- ---- ---- ---- ---- ---
Disclaimer: This e-mail message along with attachment, contain Patni GE
Confidential, proprietary & legally privileged information for the sole use of
the person or entity to whom this message was originally addressed. Any review,
e-transmission dissemination or other use of or taking of any action in
reliance upon this information by persons or entities other than the intended
recipient is prohibited. If you have received this e-mail in error kindly
delete this e-mail from your records. If it appears that this mail has been
forwarded to you without proper authority, please notify the sender and delete
this mail. This email (in whole or in part) is not to be reproduced or
furnished to third parties or made public without the prior express written
permission of the sender.
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
-- ---- ---- ---- ---- ---- ---- ---- ---
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
|
