RE: Tables, Wrappers and MLs, oh my!

[marv.edmondson@xxxxxxx]

> From a newbie on JAVA400,
This table object sounds like a great tool to show the use of Java to a bunch 
of RPGers learning Java. Is this app sharable for downloading?

Marv Edmondson......

> Brad Stone wrote:
> 
> >So, basically what I did was create a table object that accepts
> information
> >to query any DB on our network (actually, anyone it can get to with the
> JDBC
> >drivers I have installed).
> 
> >It then returns the data in a table, with which I can do anything I want
> to.
> >And it will return the data in any format (xML) that I want.
> 
> And, it seems to have been a great discussion, though I didn't follow every
> twist and turn of the 'plot.'
> 
> My biggest criticism, which my specific example would have made more
> obvious, is that XML and HTML are really very different.  XML is not just a
> respelling of HTML -- it has a different purpose.  As will be seen, the
> current discussion can still apply unchanged, despite this, but it is not
> certain to be true.
> 
> I am not the world's greatest XML expert, but read on as I think what
> follows is pretty conventional wisdom about XML and also a related
> discussion about heaps.
> 
> One thing that RPG-trained programmers are unaccustomed to is heap storage.
> In Java terms, a network of objects linked together.  Perhaps RPG IV
> programmers have more familiarity with this, but Java readily permits much
> larger and more sophisticated arrangements between objects at run time than
> even RPG IV.  For instance, an HTML document could be represented, at run
> time, by individual rows, one by one, or one could for some reason build up
> the entire HTML document as a "root" object and connect everything together
> with object references.
> 
> This last idea may well seem strange and it is for HTML.  Why?  Because the
> HTML has no real affinity for the actual underlying data.  It is really, in
> the end, "pretty print".  However, for XML this sort of
> root-and-entire-object approach can make sense.  In fact, the XML interface
> set allows both approaches in the standard IBM XML4J definition implements
> of something called DOM (whole tree) and SAX (individual pieces). This is
> no accident.
> 
> This is all somewhat independent of the O-O discussion, so it may not be
> something to tackle at all or at least until the original discussion ends.
> 
> Now, if one is simply exporting HTML or XML and neither has any effect on
> the core application, then this distinction is academic and the entire
> existing discussion is just fine.
> 
> However, if there is an existing network of objects (say, what would be a
> sequence of related relational data base records like an entire "order",
> summary and detail records) all created and linked together at run time,
> the question of HTML versus XML could become more acute.  Why?  Because the
> XML form would have much more semantic agreement with the existing network
> of objects or DB2 records.  It might even be the case that the existing
> Java code might convert to make the original object network essentially
> "be" the XML tree.  The practicality of this would vary and might relate to
> issues like "the existing internal logic of the application family" versus
> "a standard industry XML model or model(s) that one must export to."
> 
> With all this, exporting to HTML might still be an issue; one might still
> need to produce web output all independent of using XML to deliver orders
> to one's supply chain, for instance.
> 
> The specifics could potentially reduce the level of agreement in the
> various "decorator" classes or it could simply change the structure of it a
> bit and leave it logically unchanged (reducing the arguments as I suggested
> last time).  That's what an actual example would help illustrate.
> 
> 
> 
> Larry W. Loen  -   Senior Java and AS/400 Performance Analyst
>                           Dept HP4, Rochester MN
> 
> speaking, as always, on his own
> 
> +---
> | 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 message was sent using MHO WebMail.
http://www.mho.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
+---