On Sun, 30 Jul 2000 [EMAIL PROTECTED] wrote:
..
> Hehe, I wouldn't even bother with an XML file.
actually my initial thoughts were to just use a text config file. i've
done shitloads of that in the past, like my "fully programmable MUD bot
client" but i thought that if the effort of parsing a text file is
comparable to the effort of parsing XML (and actually XML is easier: see
the XML::Node module) then by all means go XML!
> Since you already have a database at your disposal, why not store the
> display and input options (if they're not "default") in database tables?
> That way, you don't have to struggle with an XML parser and end users don't
> have to write XML. That way the specs for the display (color, font,
> visibility, widget placement, etc.) and input options (digits only,
> multiple choice options, pick list SELECT DISTINCT somefield FROM
> someothertable, etc.) would be available to other client applications
> connecting to the database directly (e.g. those that would not have access
> to the XML file), and use that information to render the data entry screens
> correctly.
ehrm. this is EXACTLY how WebDB does it..
..
> Then, if you wanted to pad your resume with another industry buzzword, you
> could just add options to export the various datamodels into XML DTDs.
that's easier than you think. The DBD::RAM module can convert its internal
RAM tables (which you can insert into using DBD::Oracle and DBI) into XML
directly.
(as you can see, havent quite gotten over my Perl one-track-mindness)
--
---------------------------------------------------------------------
Orlando Andico <[EMAIL PROTECTED]> POTS Phone: +63 (2) 937-2293
Mosaic Communications, Inc. GSM Mobile: +63 (917) 531-5893
Any sufficiently perverted technology is indistinguishable from Perl.
-
Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph
To leave: send "unsubscribe" in the body to [EMAIL PROTECTED]
