<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Yes, there are no limitations on the fields. Sliders, spinners,
choosers, int, Integer, float, custom widgets and the like.<br>
<br>
Joe Walker wrote:
<blockquote cite="mid5dd47426050822151375c930ce@mail.gmail.com"
type="cite">
<pre wrap="">Another advantage of 2: You can configure it with more than just Strings?
On 8/22/05, DM Smith <a class="moz-txt-link-rfc2396E" href="mailto:dmsmith555@yahoo.com"><dmsmith555@yahoo.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">We use a BeanPanel to represent the editable fields of the various
Installers, which at this point is just the HTTP installer.
The fields come out in a random order. They should be in an order that
is appropriate for the Installer.
I would like some input before I make changes.
Any thoughts on how to change the code. I see a couple of possibilities:
1) Create an interface BeanOrdering with a single method "String[]
ordering()" that the installers will implement.
The BeanPanel would call this to figure out which order to display
the fields in.
2) Don't use BeanPanel but create an interface class SiteEditor which
would have an implementation per installer.
A SiteEditorFactory would be able to create an appropriate
SiteEditor from the installer type (e.g. sword-http, sword-ftp).
There are advantages and disadvantages to both.
Advantages of 1)
Fairly simple to implement in "client" classes.
Disadvantages of 1)
Ordering the fields in BeanPanel is not trivial, but only needs to be
figured out once.
Not obvious how the code works.
The class is not really all that general purpose. (The setters and
getters must use either String or Integer, no other work.)
I found it hard to debug when trying to figure out why a setter that
didn't take a string didn't work and that I needed to add support for
another data type.
Advantages of 2)
Code is similar to other patterns in JSword.
The code is pretty obvious.
Disadvantages of 2)
Lot more code.
Need to write a SiteEditor for each Installer.
I am inclined to do 2).
_______________________________________________
jsword-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/jsword-devel">http://www.crosswire.org/mailman/listinfo/jsword-devel</a>
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
jsword-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/jsword-devel">http://www.crosswire.org/mailman/listinfo/jsword-devel</a>
</pre>
</blockquote>
</body>
</html>