Re: XML parser and writer
Jeff Higgins wrote:
Brandon McCombs wrote:
Jeff Higgins wrote:
Jeff Higgins wrote:
Brandon McCombs wrote:
Hey guys,
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
Maybe a Java-XML binding framework?
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.
I didn't plan on using a database at all whether for storing user data
or user/application settings. If the DOM becomes unwieldly, and SAX
can't marshal new XML documents then what should I use if I want to
stick with XML? I think I want to stick with XML because I thought it
was the modern technology to use for not only storing data but
configuration settings.
In the past I've used the Java Preferences API and it was great for
easily retrieving, manipulating data, and then storing changes but the
changes weren't portable nor editable without my custom GUI which
provided both edit and import/export features. The Preferences API is
just for settings and not for data so I figured I'd have to look to
something else this time.
The XML file I plan to use is going to store not only the properties of
a task (name, description, frequency, etc.) but also all the dates on
which the task will occur (based on frequency) which is what I would
consider the data in this situation. When the application starts up, and
just before the current month is displayed, I build a data structure
that contains all the dates for all the tasks on a month by month basis
(the biggest timespan displayed by my GUI so far) so every time a month
is displayed in the calendar all the tasks and all their occurrences are
displayed. I also plan to have a list-like view of a single task, all
its occurrences, and the status for which occurrences of that task have
been completed.
A user may modify the frequency of a task, complete a single or multiple
occurrences of a task, or create/delete a task and I was hoping an API
was available for me to easily handle data elements, that were sourced
from an XML file, to accomplish those user actions.
That's what I have in my head so far for designing this. Note that this
is just a for-fun project I thought I'd try for my own benefit so at
this point there is no need for it to be enterprise-ready (i.e.
multi-user, etc.).
At this point the calendar displays better than I imagined and I'm
trying to wrestle around how to compute, store and display multiple
occurrences of a single task, hence this thread.
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. :(
If this was a professional project I would but I'm not worried about
that level of sophistication for something like this although your
example of a query probably isn't out of the question but it wouldn't
return any more than a handful of results for a user like myself or a
family member who might benefit from my program.
Having that said; If you view tour Calendar as a document the the DOM is
certainly the way to go.
JH