Re: XML parser and writer
- From: "Jeff Higgins" <oohiggins@xxxxxxxxx>
- Date: Thu, 3 Jan 2008 02:29:07 -0500
Brandon McCombs wrote:
Jeff Higgins wrote:
Jeff Higgins wrote:
Brandon McCombs wrote:
Hey guys,Maybe a Java-XML binding framework?
I'm writing a program to help people track various items and placing
them on a calendar. These items are mainly ones that reoccur (monthly
bills for example). Each item (or task) has various properties that are
set for it and I was thinking of storing all the data in an XML file.
I'd parse the file and have the data available throughout the execution
of the program. Updates to the file would occur when someone edits a
task to change its re-occurrence frequency, etc. Therefore I will need
to both easily parse and write new XML files. I don't have a DTD or
schema developed and I may later so any API I use will have to work w/o
that for now. Can anyone suggest a simple API for parsing/writing my
own made-up XML files? I've ruled out SAX since it only parses and was
thinking of using DOM but I don't know if that will work because I've
never did any programming with XML before.
thanks for any pointers
XStream, Castor, JAXB come to mind.
OTOH, why not some database technology?
I thought about an internal (to the app) database however I wanted to
strike a balance between beginning and advanced user configurability and
the ease with which to carry the user settings from computer to computer.
In my mind, an advanced user can edit the XML file directly at the risk of
messing stuff up (that's where it would be nice to eventually have a
schema defined) instead of using a GUI interface I'll eventually create
for beginner users. Simply copying the XML file from 1 computer to
another makes it easy for a user to use the application on multiple
computers if desired (although it would be up to them to keep them sync'ed
up).
Using a database made both of those things more difficult in my mind. An
advanced user would have no way of modifying an internal db and an
external db would just be overkill and make the installation of the app
overly complicated.
Any thoughts to the contrary? Maybe my knowledge is incorrect regarding
internal (embedded?) databases.
Well, first, thanks for the invitation to exercise my contrarian tendency.
:)
And second, my extensive knowledge of and real development experience with
the above subjects are hereby disclaimed.
I can say though that I have tried unsuccessfully more than once to soften
my hard head against the difficulty of using the Document Object Model
as a relational database. I think it could make sense to allow your user
to import and export his Calendar in XML format for the purpose of
transport.
But as a data model for something even as simple as a single user Calendar/
Tasklist the DOM would quickly become unwieldy especially if you have any
intention of using any part of the relations in the relational database.
You may also consider your Calendar over time, and over multiple users,
and over feature creep and over data types. Querying the DOM for all high
priority alerts after noon in the second week of January. :(
Having that said; If you view tour Calendar as a document the the DOM is
certainly the way to go.
JH
.
- Follow-Ups:
- Re: XML parser and writer
- From: Brandon McCombs
- Re: XML parser and writer
- References:
- XML parser and writer
- From: Brandon McCombs
- Re: XML parser and writer
- From: Jeff Higgins
- Re: XML parser and writer
- From: Jeff Higgins
- Re: XML parser and writer
- From: Brandon McCombs
- XML parser and writer
- Prev by Date: Re: JMF
- Next by Date: Re: XML parser and writer
- Previous by thread: Re: XML parser and writer
- Next by thread: Re: XML parser and writer
- Index(es):
Relevant Pages
|
