Can you suggest a suitable pattern? 2006-03-22 - By Jin Chun
Back
I think you need to simplify the problem. If the config item map directly to
your domain, then it may be simpler. Alternatively, you can go inside out or
outside in, in both cases you need the context that includes all items. For
example, if you bind directly from the GUI widgets to domain objects, inside
out would mean using something like a chain of command to allow all config
items to try and validate internally whether or not they are in a valid state.
Personally, I think outside in is better and more manageable, ie having a
Validation class that receives the context and exposes a method that can
validate against the configuration, all of them, then return back a validation
result as in commons validation that you can then use. We've done something
similar w a swing based trading app, and we use error codes and the context to
then localize the display of error messages back. In general, I would worry
about the structure first, then bind how you present it to the use later.
Thanks,
Jin
-- -- Original Message -- --
From: An interest list for Sun Java Center J2EE Pattern Catalog [J2EEPATTERNS
-INTEREST@(protected)]
Sent: 03/22/2006 06:02 AM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: Can you suggest a suitable pattern?
Thanks Kallol and M.Shariff.
The issue (I think) with the XML/Properties file is that all fields
aren't got through the same user interface components - for instance,
one field may have a combo box, other a number rider, some other plan
text and so forth. The validation rule for each of these fields is
complicated to be specified in a XML file (as mentioned before there may
be dependency on the previous field entries). Am I missing something
here? If you have faced with a similar issue and have taken this
approach please explain it in detail.
Thanks, Soms.
__ ____ ____ ____ ____ ____ ____
From: An interest list for Sun Java Center J2EE Pattern Catalog
[mailto:J2EEPATTERNS-INTEREST@(protected)] On Behalf Of Mohammed
Shariff
Sent: Tuesday, March 21, 2006 8:08 PM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: Can you suggest a suitable pattern?
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)
====================================================================
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)
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft
-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1=
"urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC
-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@(protected)
{font-family:Tahoma;
panose-1 (See http://ose-1.ora-code.com):2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@(protected) Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=purple>
<font size="2" face="courier new"><p>I think you need to simplify the problem.
If the config item map directly to your domain, then it may be simpler.
Alternatively, you can go inside out or outside in, in both cases you need the
context that includes all items. For example, if you bind directly from the GUI
widgets to domain objects, inside out would mean using something like a chain
of command to allow all config items to try and validate internally whether or
not they are in a valid state. Personally, I think outside in is better and
more manageable, ie having a Validation class that receives the context and
exposes a method that can validate against the configuration, all of them, then
return back a validation result as in commons validation that you can then use.
We've done something similar w a swing based trading app, and we use error
codes and the context to then localize the display of error messages back. In
general, I would worry about the structure first, then bind how you present it
to the use later.<br> <br>Thanks,<br> <br>Jin<br></p></font><hr><font size="2"
face="courier new"><p> -- -- Original Message -- --<br><b> From: <
/b>An interest list for Sun Java Center J2EE Pattern Cat========================
============================================
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)
|
|
