Config-Hierarchical

 view release on metacpan or  search on metacpan

Todo.txt  view on Meta::CPAN

#Options/CATEGORIES_TO_EXTRACT_FROM put the warning info on a single
line. Same in GetHashRef.

#Error in GetCategories example

# History output has changed the action is before the value now

#Disable silent ...
        C::H will display warnings

#Missing blank line before FILE and LINE

#Replace 'You can override the aliased category variables.' by you can
STILL

#Options/ history: remove comment about how it could have been done


#GetMultiple: better variable names


#Delta: no identical filter example is weird

#document history compacter

#add comment, history force lock, override, lock,... to history event

#Config Delta

	in package Config::Hierarchical::Delta
	
	this can be used for showing what config have changed before running rules or to show
	the difference between a node and its package
	
	delta between lists in a config object

		$c->Delta
			(
			CATEGORIES => [],
			EXTERNAL_CONFIGS => [], #sense if they are C::H or other type. expect a hash access 
			CHECK_SUB => sub,
			DISPLAY_CALLBACK => sub,
			)
		
	delta between objects (with lists)
		=> can be done in two steps
		
	accept callback from caller 
		pass object to caller for introspection
		caller pass arguments to callback
		default callback is a dumper
			default dumper can also get arguments

	return a diff data structure that can be displayed by any dumper

#package Config::Hierarchical::Tie::ReadOnly
	same as GetHashref but the values are kept in the config object, usufull to save memory when doing EvalString

# GENERATE WARNING for ALIASED categories

#can we override a locked variable => yes, no warnings (except override)

!Add sub to initalize a category in one call. once initialized, it shall not be possible to initialize
	a category again.
	=> use INITIAL_VALUES
	
#Add sub to extract a config for user defined categories. the returned config should be directly usable
	to initialize another category
	
	my $config_1 = new Config::Hierarchical(.....) ;
	
	my $config_2 = new Config::Hierarchical
					(
					INITIAL_VALUES =>
						[
						config_1->GetAllVariableInInitializationFormat
							(
							CATEGORY => 'XYZ,
							LOCK => 1,
							HISTORY => undef # remove history
							),
						
						[CATEGORY => 'CLI', NAME => 'CC', VALUE => 1,],
						[CATEGORY => 'CLI', NAME => 'LD', VALUE => 2, LOCK => 1],
						],
					) ;


#It should be possible to implement a category through a reference to another C::H object
	this is nested configs. one solution is to implement a tied hash interface on top of C:.H
	for read only nested config, we cuold implement only exists and fetch in the tie. Maybe
	implementing two tied modules on top of C::H is the cleanest solution
	
	
	my $config_1 = new Config::Hierarchical(.....) ;
	my $config_2 = new Config::Hierarchical
					(
					.....
					REFERENCE_CONFIG =>
						[
							{
							CATEGORY_NAME => 
							CONFIGURATION_REFERENCE => $config_1,
							ALLOWED_VARIABLES => [], 
							LOCKED_CATEGORY =>
							HISTORY => ...
							...
							},
						]
					) ;
	This is not going to be time effective even if it save a lot of memory
		=> this decision should be left to the user

	
#Add sub to lock category, making the category read only

#Add validation
	can we define a validator for an already existing configuration variable, yes
	do we inherit validators, between what?
	Can a validator be used for cross variable dependency? preferably something added externally
	can we have multiple validators (good)

Todo.txt  view on Meta::CPAN

#Packages that do not modify a config variable shall not be in the previous history
	not part of this module as history is handled manually

# ----------------------------
# We need to be able to get a config's history accross packages.
	#This means we need to be able to link histories together. Possibily link
	config together.

	#A naive approach is to copy the history from parent to child. This will
	use memory but will guarantee isolation.

	#Setting history should only be allowed once before the variable is defined


#'precedence given to X::Y'  should be 'X::Y takes precedence'

#when a class override another:
	do we need to use override again next time?
	shall we display a warning if override is not set
	this is how it worked in 0.01
	=> force it to override
	
#variable history should be extracted accross the categories in the right order

#what happends when setting an overriden variable?
	#does it stay overriden? yes
	is a warning generated? yes


#Add option to warn if lower level config will be ignored
	IE: setting a local variable would display a warning about the non local variable
	CHECK_LOWER_LEVEL_CATEGORIES
	
#Warning when categories are used explicitely by the user
	setable through a sub 
	SetDisplayExplicitCategoryWarningOption
	WARN_FOR_EXPLICIT_CATEGORY

#Is category used in Get?
#Get should return where the config is comming from (GET_CATEGORY)
#Config category dump should be done in hierarchical order
#status message and displayed messages differ slightly. 
	#use the same variable
	#multiple lines are displayed when multiple higher priority entries are
		encountered, display a single header footer
# An empty history string is added when the value is identical
#Check number of element in all subs to avoid 'odd number of ...' message
# OK Do we need 'force lock' to unlock 
#OK Can we set a protected category variable?
#We should be able to add a comment to the history entry when setting a
	variable
#lock status is not added to history when locking is done through 'set'. 
	OK when	done through 'lock'
#typo in GetCategories example
#Do we keep a history of warnings (protected, ignored, ...) and should it be an option

# ----------------------------

#test utilities
#wantarray
#locked categories
#custom get
#custom Get Hash ref
#document  code
#=head1 TEST, COVERAGE and EXAMPLES
#test pod, syntax, critic ...
#coverage
#check the extra test modules in Xmas proj
#check all coverage tests and make them real tests
#Manifest, README, ...

test distribution release manifest ??.



( run in 0.408 second using v1.01-cache-2.11-cpan-5511b514fd6 )