Menu
▾
▴
nms-cgi-devel — Developers discussion for NMS CGI programs
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(90) |
Dec
(25) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(183) |
Feb
(124) |
Mar
(123) |
Apr
(75) |
May
(49) |
Jun
(60) |
Jul
(58) |
Aug
(41) |
Sep
(27) |
Oct
(30) |
Nov
(13) |
Dec
(19) |
| 2003 |
Jan
(119) |
Feb
(70) |
Mar
(5) |
Apr
(16) |
May
(3) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
(3) |
Nov
(4) |
Dec
(7) |
| 2004 |
Jan
(9) |
Feb
|
Mar
(1) |
Apr
(7) |
May
(12) |
Jun
(4) |
Jul
(11) |
Aug
(17) |
Sep
(3) |
Oct
(15) |
Nov
(7) |
Dec
(2) |
| 2005 |
Jan
(4) |
Feb
(7) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(1) |
Jul
(3) |
Aug
(1) |
Sep
(9) |
Oct
(4) |
Nov
(1) |
Dec
|
| 2006 |
Jan
(5) |
Feb
(7) |
Mar
(19) |
Apr
(8) |
May
(6) |
Jun
(2) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2007 |
Jan
(1) |
Feb
|
Mar
(4) |
Apr
(2) |
May
(2) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2008 |
Jan
|
Feb
(3) |
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
| 2009 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2012 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Wizard <wi...@ne...> - 2003-01-30 21:25:37
|
I'm trying to import my base code for NMSBoard, but I'm having some problems (its been awhile ;-). I tried this: cvs -z3 -d:ext:neo...@so...:/cvsroot/nms-cgi import -m "NMSBoard Base code" nmsboard nms alpha but received (after some amount of waiting): Secure connection to sourceforge.net refused cvs [import aborted]: end of file from server (consult above messages if any) I'm using cygwin, but that shouldn't make any difference, should it? Any suggestions? Grant M. |
|
From: Dave C. <da...@da...> - 2003-01-29 11:13:04
|
From: "Wizard" <wi...@ne...> Date: 1/29/03 5:54:04 AM > I should have a working hunk of crappy base code to get > started on by the end of today (I was busy and didn't get > to starting until yesterday afternoon). I'll need a CVS > login to check it in. You'll need a sourceforge ID. Once you have one, let me know and I'll add you to the project. This will give you access to our CVS repository. Dave... -- <http://www.dave.org.uk> "Let me see you make decisions, without your television" - Depeche Mode (Stripped) |
|
From: Wizard <wi...@ne...> - 2003-01-29 10:58:59
|
I should have a working hunk of crappy base code to get started on by the end of today (I was busy and didn't get to starting until yesterday afternoon). I'll need a CVS login to check it in. This code is just so that I have something to work with. It will only have the file format and config format, and the ability to create/view multiple lists. This first version is ONLY SO THAT I HAVE A WORKING CODEBASE TO USE AS A PLATFORM. IT IS NOT ANYTHING NEAR WHAT I'LL HAVE WHEN I'M FINISHED. So don't go off all half-cocked and try to kill me. Besides, I'm unemployed and can't afford the medical bills ;-). Grant M. |
|
From: Nick C. <ni...@cl...> - 2003-01-25 16:34:05
|
On Fri, Jan 24, 2003 at 08:16:11PM -0500, Wizard wrote:
> > I would have thought it would be better to have a single method that
> > returns 1 if it's true or 0 if it's false.
>
> Yeah, you're probably right. I just kinda like code that looks like:
> if( $cfg->is_false( 'Threading' ) ) {...
>
> rather than:
> if( !$cfg->state( 'Threading' ) ) { ...
I was thinking more of:
unless ( $cfg->is_true( 'Threading' ) ) {...
>
> It seems more readable. I really didn't think about it being a problem if it
> failed to match either, but that's because I was writing it ;-). How about
> is_true and I'll check inverse values? i.e.,
> return undef if !/^[Yy]|[Tt]|[Oo]n|[1]/
> and !/^[Nn]|[Ff]|[Oo]ff|[0]/;
> That way the application can choose to die or offer alternative execution
> paths.
Yes, that would work, since undef is false.
> The other option being as you stated, dying inside the module. I
> never really liked that though, because it limits what the programmer can do
> without editing the module.
The programmer can trap the die with an eval, but I was thinking of
configuration values that must be either true or false. For instance,
if the config file says:
Threading=onion
and it's supposed to be true/false/yes/no then dieing with some sort of
helpful error message might be better than either treating it as true or
treating it as false.
Just a thought.
--
Nick
|
|
From: Wizard <wi...@ne...> - 2003-01-25 16:25:58
|
> Surely the perlish way to do this is 1 if it's true
> (/^[Yy]|[Tt]|[Oo]n|[1]/)
> 0 if it's false (/^[Nn]|[Ff]|[Oo]ff|[0]/) and undef otherwise?
That's what I had intended, but as I stated in a follow-up, it complicates
the implementation, i.e.,
if( !$cfg->is_true( $key ) ) { ...
will evaluate true for both 0 and undef, so I end up having to recheck for
undef, which means this:
if( defined $cfg->is_true( $key ) && !$cfg->is_true( $key ) ) { ...
See, that just sucks.
Grant M.
|
|
From: Wizard <wi...@ne...> - 2003-01-25 15:57:21
|
> With my pedant hat on, should we be concerned that most of these options > only have meaning in English ? Not really, as the configuration options will all be in English, which I think is mostly unavoidable. There is the possibility of adding a truth list to the configuration file and performing a string match, but I think that is overkill considering the keys are already English. I think we leave it up to the implementer to deal with. As a side note, I have a rudimentary i18n/l10n module that I'm thinking of including at some point if I have the time. It's a simple string replacement system that actually utilizes the Config module code along with selecting the catalog based on the 'HTTP_ACCEPT_LANG' variable (the process was based on a standard process for specifying such things, but I forget where I got it). Grant M. |
|
From: Nicholas C. <ni...@un...> - 2003-01-25 13:50:43
|
On Fri, Jan 24, 2003 at 08:16:11PM -0500, Wizard wrote:
> > I would have thought it would be better to have a single method that
> > returns 1 if it's true or 0 if it's false.
>
> Yeah, you're probably right. I just kinda like code that looks like:
> if( $cfg->is_false( 'Threading' ) ) {...
>
> rather than:
> if( !$cfg->state( 'Threading' ) ) { ...
>
> It seems more readable. I really didn't think about it being a problem if it
> failed to match either, but that's because I was writing it ;-). How about
> is_true and I'll check inverse values? i.e.,
> return undef if !/^[Yy]|[Tt]|[Oo]n|[1]/
> and !/^[Nn]|[Ff]|[Oo]ff|[0]/;
> That way the application can choose to die or offer alternative execution
> paths. The other option being as you stated, dying inside the module. I
> never really liked that though, because it limits what the programmer can do
> without editing the module.
Surely the perlish way to do this is 1 if it's true (/^[Yy]|[Tt]|[Oo]n|[1]/)
0 if it's false (/^[Nn]|[Ff]|[Oo]ff|[0]/) and undef otherwise?
Nicholas Clark
|
|
From: Simon W. <es...@ou...> - 2003-01-25 13:47:51
|
On Fri, 24 Jan 2003, Wizard wrote:
> > I would have thought it would be better to have a single method that
> > returns 1 if it's true or 0 if it's false.
>
> Yeah, you're probably right. I just kinda like code that looks like:
> if( $cfg->is_false( 'Threading' ) ) {...
>
> rather than:
> if( !$cfg->state( 'Threading' ) ) { ...
I always use unless instead of if in these situations for precisely the
same reason, it's easier to read :)
> It seems more readable. I really didn't think about it being a problem if it
> failed to match either, but that's because I was writing it ;-). How about
> is_true and I'll check inverse values? i.e.,
> return undef if !/^[Yy]|[Tt]|[Oo]n|[1]/
> and !/^[Nn]|[Ff]|[Oo]ff|[0]/;
> That way the application can choose to die or offer alternative execution
> paths. The other option being as you stated, dying inside the module. I
> never really liked that though, because it limits what the programmer can do
> without editing the module.
With my pedant hat on, should we be concerned that most of these options
only have meaning in English ?
S.
|
|
From: Dave C. <da...@da...> - 2003-01-25 11:21:26
|
On Mon, Jan 20, 2003 at 06:28:16PM -0500, Maurand, Curtis (Cur...@pr...) wrote: > I'll have a modification to your formmail script in the next 24 hours > or so that will allow user to read into the @referers array and the > @allow_mail_to from files located whereever the user wants to place > them. I usually put them in the cgi-bin, but security might be even > better to have them somewhere else, but thats a call for the server > admin. I'm just adding a little error checking for odd things that > might show up in the files, but essentially, one email address per > line or one domain per line. Curtis, If you're interested in providing patches to our scripts then please join the nms developers mailing list and discuss them there. <http://lists.sourceforge.net/lists/listinfo/nms-cgi-devel> Dave... -- It was long ago and it was far away And it was so much better that it is today |
|
From: Wizard <wi...@ne...> - 2003-01-25 01:21:10
|
> I would have thought it would be better to have a single method that
> returns 1 if it's true or 0 if it's false.
Yeah, you're probably right. I just kinda like code that looks like:
if( $cfg->is_false( 'Threading' ) ) {...
rather than:
if( !$cfg->state( 'Threading' ) ) { ...
It seems more readable. I really didn't think about it being a problem if it
failed to match either, but that's because I was writing it ;-). How about
is_true and I'll check inverse values? i.e.,
return undef if !/^[Yy]|[Tt]|[Oo]n|[1]/
and !/^[Nn]|[Ff]|[Oo]ff|[0]/;
That way the application can choose to die or offer alternative execution
paths. The other option being as you stated, dying inside the module. I
never really liked that though, because it limits what the programmer can do
without editing the module.
Let me know,
Grant
|
|
From: Nick C. <ni...@cl...> - 2003-01-24 23:10:59
|
On Fri, Jan 24, 2003 at 09:34:06AM -0500, Wizard wrote: > I'm adding this to the methods used in Config: > > $cfg->is_true( $key ); > $cfg->is_false( $key ); > > where: > > T | F > =======|======== > [Yy].* | [Nn].* Yes,yes,Y,y or No,no,N,n > [Tt].* | [Ff].* True,true,T,t or False,false,F,f > [Oo]n | [Oo]ff On,on or Off,off > 1 | 0 1 or 0 > > basically, /^[Yy]|[Tt]|[Oo]n|[1]/ and /^[Nn]|[Ff]|[Oo]ff|[0]/. > All other values are treated as NOT_TRUE && NOT_FALSE. > This allows configuration values to be more intuitive. > > For example, these all indicate false && not true: > > Threading = off > moderate = No > allow_html = 0 > expletive_filtering_enabled = False > > Any comments? I would have thought it would be better to have a single method that returns 1 if it's true or 0 if it's false. Having the case where the user puts 'Maybe' and both is_true and is_false return 0 is going to be confusing. If the configuration value is supposed to be a yes or no value then it would be more useful to have the code enforce that by dieing with an error message if the config file says 'Maybe'. -- Nick |
|
From: Nick C. <ni...@cl...> - 2003-01-24 23:03:11
|
On Thu, Jan 23, 2003 at 12:37:34PM -0500, Wizard wrote: > Ok, I think I have a general idea of where I am going. Here's what I have: > > Present Issues: > File Format - As stated in an earlier message, I'm going with NML, which > for the time being looks suspiciously like XML. I will do my best to hide > any format-dependent functionality so that it can be replaced if desired. > Configuration Parameters - I have a general understanding of what is > wanted, but I really don't know how to implement it, so I'm going to make my > module CGI::NMS::Config.pm. It will implement the ->get( $keyname ) method, > and perhaps some other methods (I'll post if I need anything else). I will > tag all of my calls in the code so that they can be easily replaced should > someone decide to push my module to a subclass role. This is really > self-serving, but it shouldn't be too painful to replace. > > Features (this version): > o WWWBOARD->NMSBOARD conversion utility > o Views: > List > Thread > Message > Search > o External Configuration(s) > o Ability to have multiple lists using one installation > Done by calling (...view.pl?cfg=./nms.cfg) > o IP/User/domain deny/allow (and maybe allow/deny) > o Post Moderating by User or All > o Email Alerts or Subscription Alerts > o External Templating (both template file & Cfg-based) > That looks good. -- Nick |
|
From: Wizard <wi...@ne...> - 2003-01-24 14:38:58
|
I'm adding this to the methods used in Config: $cfg->is_true( $key ); $cfg->is_false( $key ); where: T | F =======|======== [Yy].* | [Nn].* Yes,yes,Y,y or No,no,N,n [Tt].* | [Ff].* True,true,T,t or False,false,F,f [Oo]n | [Oo]ff On,on or Off,off 1 | 0 1 or 0 basically, /^[Yy]|[Tt]|[Oo]n|[1]/ and /^[Nn]|[Ff]|[Oo]ff|[0]/. All other values are treated as NOT_TRUE && NOT_FALSE. This allows configuration values to be more intuitive. For example, these all indicate false && not true: Threading = off moderate = No allow_html = 0 expletive_filtering_enabled = False Any comments? Grant M. |
|
From: Wizard <wi...@ne...> - 2003-01-23 17:42:36
|
Ok, I think I have a general idea of where I am going. Here's what I have:
Present Issues:
File Format - As stated in an earlier message, I'm going with NML, which
for the time being looks suspiciously like XML. I will do my best to hide
any format-dependent functionality so that it can be replaced if desired.
Configuration Parameters - I have a general understanding of what is
wanted, but I really don't know how to implement it, so I'm going to make my
module CGI::NMS::Config.pm. It will implement the ->get( $keyname ) method,
and perhaps some other methods (I'll post if I need anything else). I will
tag all of my calls in the code so that they can be easily replaced should
someone decide to push my module to a subclass role. This is really
self-serving, but it shouldn't be too painful to replace.
Features (this version):
o WWWBOARD->NMSBOARD conversion utility
o Views:
List
Thread
Message
Search
o External Configuration(s)
o Ability to have multiple lists using one installation
Done by calling (...view.pl?cfg=./nms.cfg)
o IP/User/domain deny/allow (and maybe allow/deny)
o Post Moderating by User or All
o Email Alerts or Subscription Alerts
o External Templating (both template file & Cfg-based)
That's it I think for now. If I've forgotten anything, let me know.
Grant M.
|
|
From: Nick C. <ni...@cl...> - 2003-01-22 23:17:06
|
On Wed, Jan 22, 2003 at 12:57:27PM -0500, Wizard wrote:
> > Sorry, you've lost me there. What problem ?
>
> This:
>
> $obj = CGI::NMS::Config->new( "LMachine/NMS/Config" );
No, there is no code in CGI::NMS::Config, it is a pure virtual class or
an interface class or whatever they're called this week. Its primary
function is to document the interface that the CGI::NMS::Config::*
classes must provide.
To create a config object, you need to know what type you're creating:
$obj = CGI::NMS::Config::Win32Reg->new( "LMachine/NMS/Config" );
$obj = CGI::NMS::Config::DynaFile->new( "LMachine/NMS/Config" );
If we want a script to be able to choose what config module to use based
on the string, we'll need to add a scheme switch, maybe something like
this:
{
package CGI::NMS::Config::Switched;
sub new {
my ($pkg, $arg) = @_;
if ($arg =~ s/^Win32Reg://) {
require CGI::NMS::Config::Win32Reg;
return CGI::NMS::Config::Win32Reg->new($arg);
}
elsif ($arg =~ s/^DynaFile://) {
require CGI::NMS::Config::DynaFile;
return CGI::NMS::Config::DynaFile->new($arg);
}
else {
die "invalid config switch arg [$arg]";
}
}
}
... so now we can do things like:
$obj = CGI::NMS::Config::ByScheme->new( "Win32Reg:LMachine/NMS/Config" );
--
Nick
|
|
From: Wizard <wi...@ne...> - 2003-01-22 18:02:20
|
> CGI::NMS::Config::DynaFile ? That'll do. > Sorry, you've lost me there. What problem ? This: $obj = CGI::NMS::Config->new( "LMachine/NMS/Config" ); Is that a file relative to CWD or is it a registry key? Meaning which module do I use? I could try each in turn, but that could be dangerous. Everything that I can think of would negate the whole idea of using a wrapper. It doesn't make sense to have anything user-specified in the script to specify where to find the EXTERNAL configuration. That's just dumb. Any suggestions? Let me know, Grant M. |
|
From: Nick C. <ni...@cl...> - 2003-01-22 17:41:24
|
On Wed, Jan 22, 2003 at 11:43:00AM -0500, Wizard wrote: > > The only issue I can see there is that it's impossible to have a value > > that includes newlines but doesn't end with a newline. I don't see that > > as a big problem at all. > > chomp $value? ;-) :) Yes, if the app knows that there's a newline on the end that the user doesn't want. Multiline strings without newlines at the end are quite silly anyway. I'm not worried. > > Yes, I'm happy for this to go into CVS as /v2/lib/CGI/NMS/Config.pm and > > /v2/lib/CGI/NMS/Config/DynaConf.pm or similar. > > Ok, I'll put together the wrapper and strip down the module. I was thinking > CGI::NMS::Config::CfgFile for the module? Could do, but you've kinda got 'config' in the name twice there. CGI::NMS::Config::DynaFile ? CGI::NMS::Config::NMSFile ? Either of those would make me happy, because the name says that it's a specific type of config file, with a syntax defined by us. NMS in the second one twice, I know, but it means different things (one of the NMS modules vs. the NMS config file format) so I think it's OK. I suppose CGI::NMS::Config::CfgFile would do if you're really attached to it though. Not a huge issue. > I know that you don't want to specify the mechanism implicitly, but Registry > entries look incredibly like directory entries. I.e., > "LMachine/Software/NMS/Config/", so not specifying could be a problem. Any > suggestions? Sorry, you've lost me there. What problem ? > (I'm not even going to mention the fact that Win32::TieRegistry is a tied hash ;-) good ;) -- Nick |
|
From: Wizard <wi...@ne...> - 2003-01-22 16:47:52
|
> > and it will work fine. In fact, I've even done:
> >
> > _OBJ03=<<EOO
> > my $old_value = shift @_;
> > my $new_value = shift @_;
> > $new_value ? $new_value : $old_value;
> > EOO
> >
> > $dispatch{ 'func1' } = $cfg->get( '_OBJ03' );
> > $value = &{$dispatch{ 'func1' }}( $old, $new );
>
> I'd be inclined to switch that off - it will be end users editing config
> files, if we let them put code in then they'll shoot themselves in the
> foot.
The dispatch mechanism is part of the application, not the module. The code
is just variable data as far as the module is concerned.
> The only issue I can see there is that it's impossible to have a value
> that includes newlines but doesn't end with a newline. I don't see that
> as a big problem at all.
chomp $value? ;-)
> Yes, I'm happy for this to go into CVS as /v2/lib/CGI/NMS/Config.pm and
> /v2/lib/CGI/NMS/Config/DynaConf.pm or similar.
Ok, I'll put together the wrapper and strip down the module. I was thinking
CGI::NMS::Config::CfgFile for the module?
I know that you don't want to specify the mechanism implicitly, but Registry
entries look incredibly like directory entries. I.e.,
"LMachine/Software/NMS/Config/", so not specifying could be a problem. Any
suggestions? (I'm not even going to mention the fact that Win32::TieRegistry
is a tied hash ;-)
Let me know,
Grant M.
|
|
From: Nick C. <ni...@cl...> - 2003-01-22 15:31:15
|
On Wed, Jan 22, 2003 at 08:34:02AM -0500, Wizard wrote:
> > That's a nice config file handler, but (for NMS) I don't like the
> > developer directives as special comments. Some NMS users will delete
> > those to save space, even if we tell them not to.
>
> Those are special for use with CFGs shared between Windows/Java and Perl.
> They don't need to be in there for NMS. It still sucks up any name=value
> pair as long as it doesn't look like a comment.
>
> > We should have a module that addresses config handling, but I don't
> > think it should be tied to a particular file format. If I were doing
> > this, I would define a class CGI::NMS::Config, with methods for
> > fetching config values, and have a subclass for each different type
> > of source of configuration data.
>
> This isn't really tied to any particular format. It will work just fine with
> any "name=value" or "name=<<HERE" or even "name = value" -type file.
> It's just that it was written to be compatible with .ini and .properties
> files.
Ah, I hadn't got that it wasn't just an INI file reader. In that case
IniFile probably isn't a good name for it. Maybe we're back to calling
it CGI::NMS::Config::DynaConf.
> As far as the "different type of source..." what do you mean? Where
> else would the config params come from, if not a file?
A config file in a different format, a DBM file, a remote database,
hard coded into the CGI, fetched via LDAP or SOAP, made up at random,
grabbed out of Win32::Registry, etc, etc. Anything that anyone might
ever want to get config from.
> > Bits of Config::DynaConf would become CGI::NMS::Config::IniFile (or
> > something) and would implement new() and get().
>
> Ok, I think I get it. If I understand correctly, you want CGI::NMS::Config
> to be a generic wrapper for whatever mechanism is called, so DynaConf (or
> likely some variation) would become one of the implemented access mechanisms
> for CGI::NMS::Config. Like AnyDBM, which was discussed yesterday. Is that
> correct?
Yes, exactly.
> > One thing that needs to be sorted out for any configuration source
> > is multiline values, those will be needed for templates in the config
> > file.
>
> I prefer to see separate template files for templates, but that's just me.
> DynaConf does support <<HERE documents. It originally worked by sucking up
> everything between the 'name=' and either the next 'name=' or the next
> comment, but I decided that was a bit dangerous.
Separate files for templates are nice, but TFmail users requested the
ability to inline the templates into the main config file, so I added
it.
So long as DynaConf does here document like things, that's OK IMO. And
it's a lot better than the way TFmail does it now, with % at the start
of each line.
> > Another is how to get metacharacters like " and \ in the config value. I
> > don't know off the top of my head how ini files handle that type of
> > stuff.
>
> I don't think there's a real issue there until you do something to it. For
> instance, with DynaConf you can actually have declarations like this (note -
> I had to add a LIMIT '2' to the module to split only on the first '=' for
> non <<HERE directives. It should have been there, but well, you know):
>
> Template=<link rel="stylesheet" type="text/css" href="css/nms.css" />
>
> which you can then do:
>
> print $cfg->get( 'Template' );
>
> and it will work fine. In fact, I've even done:
>
> _OBJ03=<<EOO
> my $old_value = shift @_;
> my $new_value = shift @_;
> $new_value ? $new_value : $old_value;
> EOO
>
> $dispatch{ 'func1' } = $cfg->get( '_OBJ03' );
> $value = &{$dispatch{ 'func1' }}( $old, $new );
I'd be inclined to switch that off - it will be end users editing config
files, if we let them put code in then they'll shoot themselves in the
foot.
> The only issue is embedded newlines. They can only be done within <<HERE
> documents, because DynaConf doesn't let you include a line like this:
> Name = ' Test\n this\n string\n'
>
> but it will keep them if done like this:
> Name = <<HERE
> Test
> this
> string
> HERE
The only issue I can see there is that it's impossible to have a value
that includes newlines but doesn't end with a newline. I don't see that
as a big problem at all.
> I can do the wrapper which should be relatively straight-forward, but are my
> answers to your comments satisfactory? Should I do the mods I suggest and
> include it?
Yes, I'm happy for this to go into CVS as /v2/lib/CGI/NMS/Config.pm and
/v2/lib/CGI/NMS/Config/DynaConf.pm or similar.
--
Nick
|
|
From: Wizard <wi...@ne...> - 2003-01-22 13:38:53
|
> That's a nice config file handler, but (for NMS) I don't like the
> developer directives as special comments. Some NMS users will delete
> those to save space, even if we tell them not to.
Those are special for use with CFGs shared between Windows/Java and Perl.
They don't need to be in there for NMS. It still sucks up any name=value
pair as long as it doesn't look like a comment.
> We should have a module that addresses config handling, but I don't
> think it should be tied to a particular file format. If I were doing
> this, I would define a class CGI::NMS::Config, with methods for
> fetching config values, and have a subclass for each different type
> of source of configuration data.
This isn't really tied to any particular format. It will work just fine with
any "name=value" or "name=<<HERE" or even "name = value" -type file.
It's just that it was written to be compatible with .ini and .properties
files. As far as the "different type of source..." what do you mean? Where
else would the config params come from, if not a file?
> Bits of Config::DynaConf would become CGI::NMS::Config::IniFile (or
> something) and would implement new() and get().
Ok, I think I get it. If I understand correctly, you want CGI::NMS::Config
to be a generic wrapper for whatever mechanism is called, so DynaConf (or
likely some variation) would become one of the implemented access mechanisms
for CGI::NMS::Config. Like AnyDBM, which was discussed yesterday. Is that
correct?
> One thing that needs to be sorted out for any configuration source
> is multiline values, those will be needed for templates in the config
> file.
I prefer to see separate template files for templates, but that's just me.
DynaConf does support <<HERE documents. It originally worked by sucking up
everything between the 'name=' and either the next 'name=' or the next
comment, but I decided that was a bit dangerous.
> Another is how to get metacharacters like " and \ in the config value. I
> don't know off the top of my head how ini files handle that type of
> stuff.
I don't think there's a real issue there until you do something to it. For
instance, with DynaConf you can actually have declarations like this (note -
I had to add a LIMIT '2' to the module to split only on the first '=' for
non <<HERE directives. It should have been there, but well, you know):
Template=<link rel="stylesheet" type="text/css" href="css/nms.css" />
which you can then do:
print $cfg->get( 'Template' );
and it will work fine. In fact, I've even done:
_OBJ03=<<EOO
my $old_value = shift @_;
my $new_value = shift @_;
$new_value ? $new_value : $old_value;
EOO
$dispatch{ 'func1' } = $cfg->get( '_OBJ03' );
$value = &{$dispatch{ 'func1' }}( $old, $new );
The only issue is embedded newlines. They can only be done within <<HERE
documents, because DynaConf doesn't let you include a line like this:
Name = ' Test\n this\n string\n'
but it will keep them if done like this:
Name = <<HERE
Test
this
string
HERE
I can do the wrapper which should be relatively straight-forward, but are my
answers to your comments satisfactory? Should I do the mods I suggest and
include it?
Let me know,
Grant M.
|
|
From: Nick C. <ni...@cl...> - 2003-01-22 11:48:28
|
On Tue, Jan 21, 2003 at 01:03:36PM -0500, Wizard wrote: > A couple more things (in reply to my own email) > > Modularization. > > Externalization of configuration. > I have a module that I wrote some time ago for doing external configurations > of Perl scripts. I know it works on numerous platforms, it's fast, and I am > familiar with it. Should/can I use it? Here's the man page: > http://www.neonedge.com/perl_tools/Config/ > Let me know. That's a nice config file handler, but (for NMS) I don't like the developer directives as special comments. Some NMS users will delete those to save space, even if we tell them not to. We should have a module that addresses config handling, but I don't think it should be tied to a particular file format. If I were doing this, I would define a class CGI::NMS::Config, with methods for fetching config values, and have a subclass for each different type of source of configuration data. The config file handling in TFmail manages with a single method for getting config values: $config->get( KEY [,DEFAULT_VALUE] ) so CGI::NMS::Config could just document (but not implement) that. Bits of Config::DynaConf would become CGI::NMS::Config::IniFile (or something) and would implement new() and get(). A CGI that needs a config would be passed a CGI::NMS::Config object as an argument to its constructor, so the CGI script might look something like: my $script = CGI::NMS::Script::NMSFoo->new( config => CGI::NMS::Config::IniFile->new('/path/to/config/file.ini'), ... ); $script->request; The beauty of that type of approach is that the script modules don't know or care where the config comes from. Other file formats can be added just by writing other CGI::NMS::Config::* modules. If someone wants the configuration to come from a database, all they need to do is write CGI::NMS::Config::DBI and plumb it in, no other modules need to change. We could even have CGI::NMS::Config::Hash, to allow a particular installation of a CGI to have a hard coded config independent of any external thing: my $script = CGI::NMS::Script::NMSFoo->new( config => CGI::NMS::Config::Hash->new({ secure => 1, foomode => 'yes', }), ... ); $script->request; ... and so on. One thing that needs to be sorted out for any configuration source is multiline values, those will be needed for templates in the config file. Another is how to get metacharacters like " and \ in the config value. I don't know off the top of my head how ini files handle that type of stuff. -- Nick |
|
From: DH <cra...@ya...> - 2003-01-22 11:01:11
|
> > What are we calling this animal? > I'll suggest NMSBoard. By the way, what does the 'TF' in TFMail mean? > Grant M. > My guess is "The" Form Mail __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Simon W. <es...@ou...> - 2003-01-22 09:16:19
|
On Wed, 22 Jan 2003, Nick Cleaton wrote: > On Tue, Jan 21, 2003 at 02:22:29PM -0500, Wizard wrote: > > > By the way, what does the 'TF' in TFMail mean? > > Template Form Mail And there was me thinking it meant 'Turbo' :) Simon. |
|
From: Nick C. <ni...@cl...> - 2003-01-22 09:07:03
|
On Tue, Jan 21, 2003 at 02:22:29PM -0500, Wizard wrote: > What are we calling this animal? > I'll suggest NMSBoard. That sounds good to me. > By the way, what does the 'TF' in TFMail mean? Template Form Mail -- Nick |
|
From: Wizard <wi...@ne...> - 2003-01-21 23:18:48
|
What if for now I do something like this (pseudo code):
$data_file = "nms.dat";
&print_header( $cgi_function_parameter );
$q = NMS::Data::NML->new( $data_file );
if( $cgi_function_parameter eq 'message' ){
$q->print_message( $cgi_msg_id ); # this is separate file?
} elsif ( $cgi_function_parameter eq 'thread' ) {
$q->print_thread( $cgi_thread_id );
} else {
while ( $q->some_left() ){
$q->print_thread();
# and perhaps
$q->next();
}
}
...
I'll be using the newly-defined 'NML hierarchical file format' ("Liar! It is
not XML! It only looks like it when you squint!") for storage. Because the
object is now data-hiding, it doesn't really matter what it is. We can
convert it to whatever the consensus is anytime before we ship. Does that
make sense, or should I just wait?
Let me know,
Grant M.
|
14 messages has been excluded from this view by a project administrator.
