 | 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 Mohammed Shariff
Back
Hi Soms,
You can use a single class which can derive its properties from a
properties file or an XML file. This class with getters and setters for each
field, should parse an XML file
or read the properties file, within a defined constructor or a method of its
own.
Hope it helps.
Mohammed Shariff
Soms S <somasundram.balakrushnan@(protected)> wrote:
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)
====================================================================
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)
<div>Hi Soms,</div> <div> You can use a single class which can
derive its properties from a properties file or an XML file. This class with
getters and setters for each field, should parse an XML file</div> <div
>or read the properties file, within a defined constructor or a method of its
own.</div> <div> </div> <div>Hope it helps.</div> <div> </div>
<div>Mohammed Shariff</div> <div><BR><BR><B><I>Soms S <somasundram
.balakrushnan@(protected)></I></B> wrote:</div> <BLOCKQUOTE class=replbq style
="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Design
Issue:<BR><BR>Motivation:<BR>There are as many as 37 config items; each config
item has different<BR>fields and each field entry has different set of
validation rules. The<BR>config items are sequentially arranged and have
dependency between each<BR>other (the next config entry depends on the values
provided to the<BR>previous config entry). We need a mechanism to configure
all 37
config<BR>items.<BR><BR>One approach is to have a Wizard kind of set up to
configure the items.<BR>That is, display each config item and its associated
fields in separate<BR>screens; when user chooses next, based on the current
input we can<BR>generate the next config item. <BR><BR>But using a Wizard will
require 37 screens (one for each config item)<BR>and if the GUI is to be
generated with a tool (for eg: Netbeans) then<BR>using 'Generation Gap' pattern
would double the classes required 37 * 2<BR>= 74 classes! Besides if config
items increases that would increase the<BR>number of screens which in turn
would double the classes required; this<BR>obviously is a class explosion!<BR>
<BR>I guess this is a generic issue and I'm wondering if there is any<BR
>alternative or a design pattern to address this.<BR><BR>Thanks, Soms.<BR><BR>==
==================================================================<BR>Companion
Site: http://www.corej2eepatterns.com<BR>J2EE BluePrints:
http://java.sun.com/blueprints/corej2eepatterns<BR>List Archive: http:/
/archives.java.sun.com/archives/j2eepatterns-interest.html<BR>Unsubscribing:
email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)<BR></BLOCKQUOTE>
<BR>
====================================================================
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)
|
|
|
