Hi Alex,
I'm sorry for the late reply. I was busy nowadays.
Following part belongs to original subject
1) Quote:
There is an undocumented "registry" feature to add variables.
...
This allows you to have your own config options that are not displayed to the user, but still keeps it separate and outside of Links SQL. Another reason I don't want it in the $CFG is uninstallers typically don't clean up after themself very well, and I want to be able to know the contents of $CFG from one version to the next. Does the above help you with what you want to do?
No Alex, but it doesn't help the problem. However thanks the idea.
The problem is, that the Config is stored in 1 hash. This way we can not use config variables in the config values itself, because all values are within one hash, so we can not use the hash within itself.
You saved the config structure this way to be able to Dump the config hash into ConfigData.pm and to be able to read back easily.
I understand this, but I don't really aggree with that.
There would be possible to NOT use Dump function to save the config, but to create the config file yourself without Dump, and write the config values to the file as following (
all config keys separately):
Code:
use strict;
use Links qw/$CFG/;
$CFG->{"server_path"} = "/var/www/website";
$CFG->{"server_URL"} = "http://www.site.com";
$CFG->{"db_cgi_url"} = $CFG->{"server_URL"} . "/cgi-bin/Lsql";
$CFG->{"build_add_url"} = $CFG->{"db_cgi_url"} . "/add.cgi";
$CFG->{"build_category_url"} = $CFG->{"db_cgi_url"} . "/page.cgi";
$CFG->{"build_modify_url"} = $CFG->{"db_cgi_url"} . "/modify.cgi";
$CFG->{"build_root_path"} = $CFG->{"server_path"} . "/Links";
$CFG->{"build_root_url"} = $CFG->{"server_URL"} . "/Links";
$CFG->{"build_use_backup"}= "1";
$CFG->{"build_index"} = "index.html";
$CFG->{"build_links_per_page"} = "10";
$CFG->{"build_new_cutoff"} = "7";
$CFG->{"date_days_short"} = ['Sun', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat'];
$CFG->{"add_system_fields"} = {
'Hits' => '0',
'Rating' => '0',
'Status' => '0',
'Votes' => '0',
'isChanged' => 'No',
'isNew' => 'No',
'isPopular' => 'No'
};
etc... etc...
Please note the order of some variables (like "server_path") is important in this kind of config file.
I know this is the 2nd or 3rd config file format I suggest to you, but this one seems the most usable format.
As for the config input
on Admin interface, we can use a special template type to place in forms.
In the Admin on config form page, the values could be easily inserted with template tags.
e.g:
Admin form of "db_cgi_url":
<%CFG:server_URL%>/cgi-bin/Lsql
(the CFG shows the variable where we put the key, and "server_URL" is the key itself)
This will be converted into the config file in following format:
$CFG->{"db_cgi_url"} =
$CFG->{"server_URL"} . "/cgi-bin/Lsql";
I don't see problem with that config file format. It is written once in the Admin part, then it is only needed to make required at the beginning of each cgi file (require /configpath/ConfigData.pm).
Using this type of config file, the config possibilities are extending. There will be NOT any speed decrease, because the config templates are only parsed once on Admin config page then, are written into config file in Perl format.
I hope you understand the problem and the advantage of the config treatment system I suggest you.
I would do development of this feature, but I don't want to lost the upgrade compatibility between my developments & Links SQL.
Following part belongs to original subjects:
3),
4),
5) Quote:
The way it works is:
1. A user requests page.cgi
2. The script sees there is no arguments so it knows to build the home page.
3. Links::Build::build_home() is called which connects to the database and gets all the information that is needed.
4. It calls Links::SiteHTML::display_home which parses the home.html template.
5. After parsing, if you are in dynamic mode, Links::clean_output() is called. This rewrites the parsed html and changes all static links to dynamic links. So wherever it sees http://yoursite/pages/Category/ it changes that to http://yoursite/cgi-bin/page.cgi?g=Category/.
Hey, this is almost fine! Except the point 5!
There is simply NO need to use of clean_output()! It uses regexp to replace all URLs to corresponding one, and I think this is very uneffective. You have to replace even hundreds of URLs instead to place an if statement to the corresponding function and decide whether we create dynamic or static URL.
I understand your point that you solved the dynamic/static URL problem with just one logical function, but this is uneffective.
I suggest to ignore the code clean_output() in step 5 and use if statements in step 3 in the following functions, where the URLs are created:
build_toolbar
build_title_linked
build_search_toolbar
build_new_subpage
build_new_index
build_category
site_html_print_cat
site_html_link
(alternatively you can still call anytime Links::clean_output (\$text); to correct URLs, in plugins or when developing something new, but it's not recommended)
To show just one example how this should work fine:
Original code currently used in Links\Build.pm in sub build_title_linked (partial code):
Code:
$output = $home ?
qq| <a href="$CFG->{build_root_url}/$CFG->{build_index}">$top</a> :| :
'';
Corrected code:
Code:
$in_params = the parameters we get from input $IN;
if ($IN->{"d"} eq 1) {
$output = $home ?
qq| <a href="$CFG->{build_category_url}?cat=$IN{cat}&$in_params">$top</a> :| :
'';
} else {
$output = $home ?
qq| <a href="$CFG->{build_root_url}/$CFG->{build_index}">$top</a> :| :
'';
}
Well, this seems more difficult to develop, but you win efficiency & flexibility using this solution.
Using clean_output() you are locked down, because it also changes URLs which are not allowed to change, and you lose efficiency when displaying pages with hundreds of URLs.
Alex, I'm almost sure you will defend your clean_output() solution you used, because changing this would need to change a lot of codes in Links SQL, and would change the URL lookout comparing to the current.
But I think, the improvement (using my suggestions 3,4,5) would be positive and users would like it because the result will have:
a) clean URL lookout
b) freedom of URL treatment when developing plugins
c) more speed on pages with hundreds of URLs, links.
And yes, another solution is to make execution of clean_output() optional in config, but this would still need the changes I suggested...
Waiting your reply.
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...