RE: HTML to XML, vice versa -- JAVA400-L

Again, I feel compelled to drop in a few comments.

There are two directions to go with this type of design, and it centers on the 
level of granularity required, as Larry alluded to.  However, in this case, the 
commonality of input/output requirements is pretty high.  Other than the actual 
formatting of data, such as inserting punctuation into things like social 
security numbers, most UI attributes are relatively universal over all data.

That being the case, far and away the most straightforward technique is to 
design a field definition and a field decorator, and allow those to 
commmunicate the necessary output requirements.  In effect, the field 
definition is a bean that controls the functioning of the field decorator.  
Again, as I mentioned in my previous post, population of the field definitions 
is an issue, but it would be no matter what.  Even with individual decorators, 
you would still need some information that would bind the field to the 
individual decorator.  This is the same information that is stored in the field 
definition.

Now, if your design is such that you foresee a VERY diverse set of formatting 
requirements - perhaps a special field type that requires completely different 
rendering characteristics - then you move towards the concept of an Abstract 
Factory.  Here, you'll design a class that will generate the appropriate 
decorator based on the field type.  This special decorator will be used in 
place of the standard decorator used for other fields.  In this way, you can 
treat special cases as the one-off that they are, while continuing to build 
your base decorator class that handles the vast majority of your needs.

My rules for design:

1. Identify commonality
2. Parameterize the differences
3. Coalesce the commonality into active classes
4. Coalesce the parameters into definitions (beans)
5. Abstract both with interfaces to allow exceptions

The trick is, what is an "exception"?  For me, an exception is usually anything 
that fails the 80/20 rule.  If less than 20 percent of my instances require it, 
it's an exception.  At least, that's the way it's been working for me, and it's 
very successful.



---------- Original Message ----------------------------------
From: "Larry Loen" <lwloen@us.ibm.com>
Reply-To: JAVA400-L@midrange.com
Date: Wed, 14 Mar 2001 10:05:22 -0600

>
Brad Stone wrote:

>To me, this really seems like a fancy way of hardcoding.  :)   If we make
a
>decorator object for every field in our system that's a lot of decorators.
>Now, multiply that number by every *ML tag we want to use.  Yikes.

True.  But, the question really would turn out to be "where does the
hardcoding go and how does one maintaint it?"

In my later examples I was going beyond output per se and trying to reflect
an underlying reailty.

XML is different from HTML.  In fact, what is likely to happen is that many
designs that today deal with records, one at a time, will instead deal with
XML "trees" that are kind of like records and kind of not.

So, internal to the Java program, the "natural" representation will be as a
tree of Java objects.  Processing will consist of walking up and down this
tree until the item of interest is found.

The question of "decorators" would arise primarily when it came time to
export this tree to some useful format.  This would be either an XML
document (to enable the tree to be simply reconstituted later) or to HTML
to produce output for the web.

Now, in point of fact, there is a whole separate thing called XML Style
Sheets that solves this problem without programming.

But, as a concise business example, this is still pretty good.

The issue here is "who owns what" and "who maintains what" and even "how
many times is it coded."

Certainly, the way things are described, this looks like, and is, a lot of
work.  But, any real application that exported to HTML faces all the
problems we're describing.

Moreover, the choice of "how" to export an address1 (or any other XML tag)
as an element of an HTML table is not immediately obvious in detail.  Do
you have a need to use a fixed font?  Should the address always be red?  Is
it actually better to render it as a small table within a table?  Is there
an ordered list of sub-pieces?  An unordered one?  For address1, these are
fairly easy to answer.  But, there will be XML tags for which this is not
as obvious.  I wouldn't want to distribute the answers to these questions
all over the code.

These are, in short, the sorts of questions that the individual HTML
decorator object can answer in arbitrary detail.  Moreover, if the design
is divided as we've recently suggested, the separate object means the kind
of information is not present in the base "address1" type object where it
doesn't belong.  Or, in the nonJava case, scatttered throughout a bunch of
procedural code.  If we didn't do this, the knowledge I'm talking about may
end up scattered everywhere we want to do ToHTML, which might be more than
one place after all.

And, because all this hardcoding is specific to "the HTML decoration of an
address1 tag", a lot of things do end up hard coded.  But, these
hardcodings also end up centralized and easy to change.  While it can be
long and tedious in some circumstances to make all these objects, once it
is done, it can be reused several times, maybe even within the first
release of the same project.  You don't, in other words, have to distribute
all this dreary detail all over the code.  And, if it must be changed, you
go to one place to change it without drastically affecting who knows how
much code.

When you're done, these classes will act like old style assembler language
macros.  They will be brief, easy to get correct, and logically (or even
actually) included where invoked.

Another potential here is that address1 is too low a level of granularity.
Maybe the employee tag would be the lowest granularity of decorator object.
But, I doubt if that really saves as much work as one might think.

I would also be remiss not to point out that, in a lot of real world cases
like this, where there are dozens and dozens of entities, they can also
have at least the first pass of their Java source created by a faily
simple-minded source code generator.  A kind of quick-and-dirty poor man's
wizard.  I've used this with success, creating all the dreary boilerplate
that's probably bothering you and leaving on the substance (which has to be
coded somewhere) as the only thing I end up doing by hand.  These
generators are sometimes so simple, I've been known to write them in old
fashioned DOS Basic.


Larry W. Loen  -   Senior Java and AS/400 Performance Analyst
                          Dept HP4, Rochester MN
--
We must do a few things well, rather than everything late.
8-553-3535   (507) 253-3535

+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---

+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---