At 07:28 AM 11/9/2001, brian moseley wrote:
>On Thu, 8 Nov 2001, Gunther Birznieks wrote:
>
> > web.xml should not exist as it does in java servlet API.
> > It should be an optional confile file written in Perl as
> > Perl data structures (hashes of hashes). This is much
> > more efficient and thin and will make porting servlet
> > API to be reasonably fast for CGI users much easier. SO
> > more like web.pl with web.xml being optional if XML is
> > really the preferred choice.
>
>i tend to disagree.
>
>my only concrete reason for preferring xml, other than that
>it "feels" right ;), is that you get much better error
>handling right out of the box, especially when you turn on
>validation. that's something that would have to be
>implemented as part of a perl-based config file processor.
I don't really believe that common problems are easier to find with XML
than with Perl constructs.
>something just makes my stomach turn, tho, wrt using
>code-based config files. they are higher-level artifacts
>than code and should be expressed in a higher level
>language. it's my belief that this makes it easier for
>non- or little-coding admins to configure and integrate. but
>of course i can't prove this. and maybe it's the group's
>concensus that this type of user is not our target.
Perl is a scripting language and is perfect for representing scriptable
configs instead of static XML documents. It's way more flexible.
> > We also do the same thing in our Java Toolkit anyway.
> > web.xml hardly contains anyhint other than a pointer to
> > our REAL config XML file for our java servlets where we
> > have a much much richer config API than Servlet's allow
>
>can you point us at an example of this config api?
Well, servlets allow you to set up params in web.xml but they are very flat.
What we do is instead have a single param called ConfigFile which points to
a location of a configuration file. com.eXtropia.servlet then will take the
value of ConfigFile and pass it to com.eXtropia.config and create a config
object.
This config object parses the XML and then basically you can walk down the
tree by asking it for the values. The idea is that all objects in our
toolkit (in Java) conform to the configurable interface and therefore have
a configure method that takes a configuration tree.
There is a type directive for a config that allows the config to also act
as a dynamic object factory that basically creates the object of that type
and then passes the config subtree of that type to the configuration method
for the object so that it instantiates and creates itself.
eg
<Action type="com.eXtropia.m1.gmfc.action.DeleteAddress">
DeleteAddress
<View>BasicAddressData</View>
</Action>
So when the config API creates an object of type DeleteAddress action, then
the config tree inside the <Action> tag will be passed to DeleteAddress
action to tell it how to configure itself (eg that the view an address
deletion is associated with is a basic address data view.
or for a widget...
<Widget type="com.eXtropia.view.widget.html.TextInput">
<Id>group_name</Id>
<Name>group_name_e</Name>
<maxlength>30</maxlength>
<size>30</size>
<Required>true</Required>
</Widget>
or something more hierarchical like
<Diagnostics>
<TraceInline>true</TraceInline>
<DefaultTraceLevel>DEVELOPER</DefaultTraceLevel>
<TraceListener type="com.eXtropia.diagnostics.SystemOutListener"/>
<LogListener type="com.eXtropia.diagnostics.SystemOutListener"/>
<LogListener type="com.eXtropia.diagnostics.FileListener">
<File>c:\Settings\gmfc.log</File>
<MessageFormatter>
<Format>{DATE} {MSG}</Format>
</MessageFormatter>
</LogListener>
</Diagnostics>
Which isn't represented well by a flat param name = value pair structure.
However, other than XSLT (which is horribly complex for this), the idea of
variables and macros and include files in XML just don't really exist very
nicely so it has to be coded into a config API also. This is also extra
time and yet another thing for someone to learn.
I guess I just still prefer Perl. The nice thing about XML though is that
you can use a GUI to see the XML config tree more easily. But when you have
large apps, the XML files get extremely large and the idea of a clean
system of programmatically calculating something or pulling in additional
config information dynamically without coding the app to look for it is a
nice feature of Perl that XML doesn't have by itself.
Anyway, I think it is reasonable to support XML for orthogonality with Java
Servlet, but I think it is a shame to move away from Perlisms because I
just feel like Perl supports so much more than Java that it can make use of
this stuff.
> > This is exactly the right way to do it. I've been
> > posting off and on for over a year on the Mod_perl list
> > (usually now to encourage people to start naming things
> > right) that making something into an Apache::* module
> > really sucks unless that's what it really is because it
> > confuses people into thinking the module is apache only
> > when it might not be (eg Apache::Session or Apache::DBI
> > naming really annoys me)...
>
>i wonder if we can't elect a committee to review the
>namespace and recommend name changes, deprecations of
>redundant modules, refactoring, etc. hm. better suited to
>the modperl list i guess.
Well, I think there is also a thought that all the Apche::* modules
basically makes mod_perl seem very rich. So it makes mod_perl look quite
good. So marketing-wise I think it's better for mod_perl, but worse for
Perl as a whole. Plus it's extra work. I am not sure what would happen if
people started refactoring CPAN. I think it would be quite interesting, but
I am not sure it would work.
Consider what would happen if it took 4 weeks to refactor something, so the
owner spends 2 weeks doing it and announcing a beta but then all of a
sudden has other work to do, so the module becomes in Limbo with people
still using the old version but anticipating the new one and being annoyed
that they have to wait longer for the revised API.
Yes, I know that theoretically open source should solve this because the
users will then take over the work, but in practice most users are users,
they aren't contributers other than patches, self contained module
additions, or bug reports.
> > I like the idea of using the servlet API. But I think it
> > requires warping into being efficient for Perlisms.
> > Otherwise it is really just following the crowd.
>
>i'd like to hear your other thoughts on the subject.
>hopefully you get time to write them sometime soon! thanks.
I am horrible about this. And I am off on business travel again tomorrow
for another week. I had a day and a half of high speed internet, and it's
back to the land of 28k dialup...
Well, this is one reason why I am decidedly NOT a leader in this group
(phasing in an out). :)
