Gossamer Forum
Home : Products : Gossamer Links : Discussions :

URL generating

Quote Reply
URL generating
Is there a standard way (function or something) to generate an URL which is displayed dynamically or statically according the CFG->{dynamic_pages} , and still preserves the CFG->{dynamic_preserve values}.

Or I have to generate this URL, using my own code? Shocked

I'm creating a plugin to make sorting order changable on the category pages. There I need to create the URLs (sort order links), but if there is a function which does this, let me know, so I can use it.

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...
Quote Reply
Re: [webmaster33] URL generating In reply to
Hi,

If you use Links::user_page() function it will rewrite the URL's for you automatically.

The syntax is Links::user_page('template.html', { vars }, { opts });

Alternatively you can call:

Links::clean_output (\$text);

and it will rewrite the URL's in $text.

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] URL generating & Suggestions In reply to
Thanks Alex!

However it is a bit strange solution. Could not be better solutions?

Let me tell you some of my suggestions:
1) I'm thinking on an update of Links SQL v2.1 to v2.2, where in the ConfigData.pm file should be improved, to be able to use variables within values, like we were able to do in Links 2.0:
Code:
$server_URL = "http://www.website.com";
$db_cgi_url = "$server_URL/cgi-bin/links";
$build_category_url = $db_cgi_url . "/view.cgi";
I mean something similar like above, so we can use variables. Then later we can merge config values into the $CFG hash if needed.


2) Would be fine to make configurable the option names in URL we currently use: 'mh' or 'nh' or 'so', etc.

Should be placed into the CFG as following:
Code:
'option_new_links' -> 'mh'
'option_page_number' -> 'nh'
'option_category' -> 'cat' (currently 'g')
etc.


3) Would be fine to change the format of category in URL (used as 'g' option) we currently use in Links SQL 2.1 to eliminate the very ugly looking URLs:
Code:
http://www.website/cgi-bin/links-sql/page.cgi?g=Category%2FSubcat%2Findex.html&d=1
to:
http://www.website/cgi-bin/links-sql/page.cgi?g=Category/Subcat&d=1
So we do NOT need the '/index.html' or the URLencoding of '/' sign.


4) Also '/moreXX.html' is unnecessary, would be better to have an '&page=XX' URL option, wouldn't?

A correct dynamic URL would be look like this:
Code:
http://www.website/cgi-bin/links-sql/page.cgi?cat=Category/Subcat/subcat&d=1&page=14


5) Also when CFG->{foreign_char} option is turned on, the following URL type is unnecessary:
Code:
http://www.website/cgi-bin/links-sql/page.cgi?g=2/14/9/more14.html&d=1
and should be changed as following:
http://www.website/cgi-bin/links-sql/page.cgi?cat=9&d=1&page=14
As you see there is good enough, if we use the ID of Current category only without strings attached (this case the cat ID is '9').

Alex, I hope you will aggree these suggestions and you will implement them in the next release.
Please, please, please consider implementing these suggestions! Wink

Waiting your opinion.

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...
Quote Reply
Re: [webmaster33] URL generating & Suggestions In reply to
Hi,

1. Plugins can store their own options that users can edit. You should not change the main $CFG, as then it is not preserved during upgrades.

2. Why do you need this? Is it just for the look of the URL's?

3,4,5: These are all similiar suggestions but are unfortunately difficult to do with the way Links SQL works. Because Links SQL uses a single template set, when you make links in static mode, they must also work in dynamic mode.

The way it works is Links SQL displays your page as a static page, and then rewrites URL's to use page.cgi.

Let me know if this makes sense,

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] URL generating & Suggestions In reply to
Alex,

Please check my answers after the quotes.
Quote:
1. Plugins can store their own options that users can edit.
Yes, but currently there is no possible solution to have variables within the options.
The example I gave should talk to itself... You should see why is this so important.
But I worked out the idea a bit, so this may be more clear.
Let me know, if you don't aggree this:
ConfigData.pm should contain the following 2 data structure:
Code:
# Main variables (or you can even call as System variables):
my $MAIN;
$MAIN->{'server_URL'} = "http://www.website.com";
$MAIN->{'server_path'} = "/var/www/website/www";
$MAIN->{'db_cgi_url'} = "$MAIN->{'server_URL'}/cgi-bin/links",;
$MAIN->{'db_cgi_path'} = "$MAIN->{'server_path'}/cgi-bin/links",;
$MAIN->{'build_category_url'} = $MAIN->{'db_cgi_url'} . "/view.cgi";

# Config options
$CFG = {
'add_system_fields' => {
'Hits' => '0',
'Rating' => '0',
'Status' => '0',
'Votes' => '0',
'isChanged' => 'No',
'isNew' => 'No',
'isPopular' => 'No'
},
'admin_email_add' => '1',
'admin_email_mod' => '1',
'admin_root_path' => "$MAIN->{'db_cgi_path'}/admin",
'admin_root_url' => "$MAIN->{'db_cgi_url'}/admin",
'bans' => [],
'build_add_url' => "$MAIN->{'db_cgi_url'}/add.cgi",
etc ...
};
The way above, all dependent data can be replaced by variables.
This would be important to have.

I know, you want to solve the saving of $CFG to ConfigData using GT::Dumper, but we could find the right solution how to solve the problem & still to have the Main (or System) variable feature.


Quote:
You should not change the main $CFG, as then it is not preserved during upgrades.
Yes, however sometimes there are useful options, which worths to implement in next release of LinksSQL into main $CFG. I have some & I will suggest them sometime in a separate post.


Quote:
2. Why do you need this? Is it just for the look of the URL's?
Well, I developed my own dynamic category page display script (view.cgi) for Links 2.0. The script was able to work in a) Full Dynamic mode b) Half Dynamic mode (more pages are displayed dynamically, first category pages are static) c) Full Static mode.
I used some logical names for me (like 'cat=' for category or 'page=' for pagenum or 'order=' for order).
These URLs are bookmarked for my users, so I want to keep these parameter names.
I also want to make clear looking URLs for the users, using options like 'p=' or 'page=' for pagenum and not something confusing like 'nh='.
I hope you understand, that this feature to change the parameter names in Config, would be important for me, and may be useful for others, too.


Quote:
3,4,5: These are all similiar suggestions but are unfortunately difficult to do with the way Links SQL works. Because Links SQL uses a single template set, when you make links in static mode, they must also work in dynamic mode.
As I wrote above I created a dynamic page script for Links 2.0, which has the same features and works exactly the same way as I suggest you to change.
So what's the problem? It can work, that's why I suggest. The decision depends just on you.

Quote:
The way it works is Links SQL displays your page as a static page, and then rewrites URL's to use page.cgi.
I don't really understand how you mean...?
a) You mean the page is gererated and saved as file to right directory (e.g.: /Computer/Printers/index.html), then is displayed in the browser and the URL is rewrited to display the dynamic URL? I don't really think it works like above, because I did not find any generated file while I used dynamic mode.
b) I suppose it works like any usual dynamic script, so starts the script, read the DB & executes templates, then prints out the result.
Please explain me how really works.


Let we check again the 3, 4, 5 points:
3) Question: Why we need to use '/index.html'?
Answer: I think in most cases it is unnecessary, because the default index file is used loaded when we point a browser to a dir /Category/subcat/. In addition this is only an input parameter so the only parameter we need as input is a unique category identifier (ID or Full_Name). And maybe page number. Nothing else.

Question: Why we need to URLencode the '/' sign?
Answer: there is no need to URLencode it, as I know. At least I did not URLencoded and thousands of users used my site happily, without problem with that.

4) Question: Why is '/moreXX.html' necessary? Would be better to have an '&page=XX'.
Answer: I think this is more logical & nicer, rather to use an ugly URLencoded '/moreXX.html'.

5) Question: Why we use the format '?g=2/14/9/more14.html', which is ugly in addition, because the URLencoding of '/' ?
How would it look for an only 10 level deep category system? I show you:
'?g=11/22/33/44/55/66/77/88/99/100/more14.html'. Isn't it UGLY?
Answer: I think using '?cat=9&page=14' is more logical and still makes possible to identify & query the links of the correct page we want to display, because: 'cat' is the ID of the category (each category ID is unique) and 'page' is the page number we want to display, if there are more pages. If page is not given, we assume as page = 1.
What is the unknown parameter we should need to know?
I think we have all parameters we need to display the correct page.

Alex, let me know your opinion and standpoint about implementing these suggestions.
Let me know, if something is still not clear.

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...

Last edited by:

webmaster33: Feb 27, 2002, 7:05 PM
Quote Reply
Re: [webmaster33] URL generating & Suggestions In reply to
>>
Yes, however sometimes there are useful options, which worths to implement in next release of LinksSQL into main $CFG. I have some & I will suggest them sometime in a separate post.
<<

You should never have to edit ConfigData.pm

Almost everything can be done with a global or declaring the hashref (or whatever else you want to declare) in your plugin.

Last edited by:

RedRum: Feb 28, 2002, 2:07 AM
Quote Reply
Re: [RedRum] URL generating & Suggestions In reply to
I was not clear enough??? Shocked
I wrote: "which worths to implement in next release of LinksSQL into main $CFG."

It means, I don't want to modify ConfigData.pm, but I would like if Alex would implement a few config options into next release.
I will make my suggestions later.

I hope this point 1) is clear now.

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...
Quote Reply
Re: [webmaster33] URL generating & Suggestions In reply to
Hi,

Quote:
Yes, but currently there is no possible solution to have variables within the options.

There is an undocumented "registry" feature to add variables. During install you can do:

$mgr->install_registry('YourPluginName', { foo => 'a', bar => 'b' });

Then you can access this in your code:

my $reg = Links::Plugins->get_plugin_registry ('YourPluginName');
print $reg->{foo}; # prints 'A';
$reg->{foo} = 'b';
Links::Plugins->set_plugin_registry('YourPluginName', $reg);

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?

Quote:
b) I suppose it works like any usual dynamic script, so starts the script, read the DB & executes templates, then prints out the result.
Please explain me how really works.

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/.

It's important to understand that part.

The same code is used to generate a static page, and a dynamic page. The only difference is a dynamic page goes through clean_output() function to make sure the output has dynamic links. The advantadge to this is that we don't have to make any template changes to be able to run in dynamic mode, or static mode.

The problem with what you want is when clean_output() is run, it does not know enough information to generate the type of links you want. i.e., all it sees is http://yoursite/pages/Category/, it does not know the ID number. It would have to re-look it up again slowing things down considerably.

Let me know if that makes more sense.

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] URL generating & Suggestions In reply to
HI Alex,

I'm not quite following the above conversation, but I have request that falls in the same category and it's a mod that I've implemented on one of my sites, and it seems to be working well.

The cleanoutput code only runs if a user has d=1.
This actually causes a problem when trying to use the preserve dynamic fields as script preserve fields (never really understood why this wasn't the original intention.)

What I did was this. I changed that code to clean the output regardless if d was set. This way, I could use my dynamic preserve fields without setting d to 1.

I added an if statement to updating the urls from build_root_url to db_cgi_url, so now it does it only if d is set to one, but all my db_cgi_urls still get cleaned and all the dynamic_preserve fields still work. This saves me from having to change all my templates urls and form tags because clean output still does it for me even though d is not set.

This has the result of enabling me to use the dynamic preserve field in the add.cgi, modify.cgi etc.. AND still keep the user in the html version of the site(unless d is actually set) instead of forcing everything into dynamic mode which I don't want. The dynamic preserve fields also get built during the print process which has already saved me about 10 hours of work.

I hope you can Implement that in future versions.


peace.
Quote Reply
Re: [klangan] URL generating & Suggestions In reply to
klangan: Yes, your idea is basically good, and I find useful, if we are thinking in the original concept of Alex (the cleanout after creation concept).

BUT: I don't aggree original concept of Alex.
In LinksSQL 2.1 when the page is finished, it is parses and replaces all URL values to the URLs we need.
I absolutely disaggree with that concept. Yes, the concept works, but can cause some problems.

We should use simple variables instead, which depends e.g. by the d=1 input variable.
Let me show, how it should work:
Code:
$server_path = "/var/www/website";
$server_URL = "http://www.site.com";
$db_cgi_url = "$server_URL/cgi-bin/Lsql";
$build_add_url = "$db_cgi_url/add.cgi";
$build_root_path = "$server_path/Links";
$build_root_url = "$server_URL/Links";
$params = the parameters we get from input $IN

if ($IN->{d} eq 1) {
# if foreign_char is turned on, we use category id instead of full name
my $cat= (($CFG->{foreign_char}) ?
($CFG->{category_id}) :
($CFG->{Full_Name}));
# category URL for dynamic pages
$build_category_url = "$db_cgi_url/page.cgi?cat=$cat&$params";
} else {
if ($CFG->{category_id} eq "0") { # this is home page
$category_URL = ""; # so we don't need category in url
} else { # so this is a category page
# if foreign_char is turned on, we use category id instead of full name
$category_URL = (($CFG->{foreign_char}) ?
($CFG->{category_id}) :
($CFG->{Full_Name})) . "/";
}
# category URL for static pages
$build_category_url = qq|$build_root_url/$category_URL$CFG->{build_index}|;
}
This way you will have control over all URLs, through all processing.
Yes, there would be also need to change the config structure as I suggested in my earlier post.

That's my basic concept. I think, my suggested way to use dynamic (not static) variables is better, and takes much less resource, comparing with current solution of Alex: reparsing the page and replacing urls with clean_output().

Please read my next post for more detailed info.

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...
Quote Reply
Re: [Alex] URL generating & Suggestions In reply to
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! Wink
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...
Quote Reply
Re: [klangan] URL generating & Suggestions In reply to
Hi Kyle,

Sorry, I must have missed your reply!

Quote:
This has the result of enabling me to use the dynamic preserve field in the add.cgi, modify.cgi etc.. AND still keep the user in the html version of the site

Hmm, but doesn't dynamic_preserve only make sense if the entire site is dynamic? As soon as a user visits an html part of the site, they are going to lose the vars in the URL.

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [webmaster33] URL generating & Suggestions In reply to
Hi,

I'll think about the config file format a bit more. I can see the advantadge of having config options referencing others.

Quote:
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:

Ah, but there is much more then that. What about links users make in their templates? Does a user now need to do:

<%if d%>
<a href="<%db_cgi_url%>/page.cgi">
<%else%>
<a href="<%build_root_url%>
<%endif%>

For every link? Things like links to detailed pages, links to reviews, links to file uploads, all need to be handled.

The main goal of using clean_output() is so you can use the same template, without modification in either static or dynamic mode. I'd still be interested to hear what you suggest.

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] URL generating & Suggestions In reply to
Hi Alex,

Quote:
I'll think about the config file format a bit more. I can see the advantadge of having config options referencing others.
I'm glad you understand the advantages. I hope we will able to find a good solution. I'm open to help you. I would like to make LSQL a good, flexible Link system.

As for the template solution you suggested, there is 1 problem. I hate using if statements in template, because parsing is a relatively slow task. Even using the compiling is still slow task, so I only use template tag commands, if it is very necessary.

Just for an example in Links 2.0 my old dynamic page display took about 4.5 seconds for a page. I profiled the script and the template parsing took the most of the time.
Well, the LSQL displays the same template page in 1.2-1.8 second so it's significantly faster, but I'm sure the template process still takes the most time (I didn't profiled LSQL, yet, just supposing).

Quote:
For every link? Things like links to detailed pages, links to reviews, links to file uploads, all need to be handled.
Yes, they all need to be handled, I listed most of the functions, where change may need.
But remember, the fact that there is need to change code in so many functions, it doesn't mean it is the same process flow. In the same process flow there are only few changes. The category display needs the most change.
E.g. displaying a category page, you need to change in:
generate_category_page:
my $page = $IN->param('g') || $ENV{PATH_INFO} || '';
$page =~ s,/more(\d+)\.s?html?$,, and ($page_num = $1);

site_html_print_cat:
my $category_url = $CFG->{build_root_url} . "/" . $cat_db->as_url ($cat_r->{Full_Name}) . "/" . $CFG->{build_index};
my $category_name = $cat_r->{Name} =~ m,.*/([^/]+)$, ? $1 : $cat_r->{Name};
$cat_r->{Short_Name} = $category_name;
$cat_r->{URL} = $category_url;

build_category:
my $url = $CFG->{build_root_url} . "/" . $cat_db->as_url ($cat->{Full_Name}) . "/" . $CFG->{build_index};
if ($rel_name) {
$display{related} .= qq~<li><a href="$url">$rel_name</a></li>~;
}
else {
$display{related} .= qq~<li><a href="$url">$cat->{Full_Name}</a></li>~;
}
...
my $url = $CFG->{build_root_url} . "/" . $clean_name;
$display{next} = $display{prev} = "";
if ($numlinks > ($nh * $lpp)) {
$display{next} = $url . "/more" . ($nh+1) . "$CFG->{build_extension}";
}
if ($nh > 1) {
$display{prev} = $url . "/more" . ($nh-1) . "$CFG->{build_extension}";
}
$display{'next_span'} = build ('toolbar', { url => $url, numlinks => $numlinks, nh => $nh}) if ($display{next} or $display{prev});

I might missed a few places to change, but I have to hurry now.
These are only 3 places to change in the category display process flow.

Quote:
The main goal of using clean_output() is so you can use the same template, without modification in either static or dynamic mode.
I will think about this, and I will come back to you with a suggestion if I can, within a few days.

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...
Quote Reply
Re: [Alex] URL generating & Suggestions In reply to
I see what your saying, but the issue isn't about losing the vars when they get to the html part of the site.

This is what I have to do.
for the scripts, add,modify,user I need to have a variable called dt (it determines which set of .def files to access. I only need it for the scripts and yes, it's also used in the admin section. Using this method I can use the dynamic preserve fields variables (d,s,t,dt) and still keep people in html mode. When they go from script backto html mode, the variables are still encoded into the db_cgi_urls because they are also set on in the admin. I modified the script so that when I build it runs clean_output, it sees that dt is set and all my templates are encoded with dt=variable but unless d is set it won't encode the build_root_url vars, only the db_cgi_url vars and any of my form tags! This has the added advantage that I don't need to code the variable into my urls in the templates - an enormous job, plus I can still make changes to templates, people can still use the system without going into dynamic mode and I can do what I need to in there. All to often I get complaints from people viewing content that is not yet intended for building.

You can see how I have this working by going to
http://209.132.237.149/artists/index.html

You will notice that if you manually set d=1 to any of the script urls that the entire site then runs in dynamic mode.

My primary reason is that I'm running multiple database sets from the one script (I have space restrictions that can't accommodate two installations of links.)

I'm sure this has other applications as well

Let me know if you have any questions. I'll be happy to discuss it further.

peace.

Kyle
Quote Reply
Re: [webmaster33] URL generating & Suggestions In reply to
Quote:
But remember, the fact that there is need to change code in so many functions, it doesn't mean it is the same process flow. In the same process flow there are only few changes.


I'm not worried about changes to the code, that's not a problem. I'm worried about making it more difficult for the end user to work with their templates. Regardless of performance, I wouldn't want to force a user to wrap if's around all URL's, or maintain two sets of template sets.

Let me know what you come up with.. If we can make it seamless in the user templates, then I would be open to changing the code.

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [klangan] URL generating & Suggestions In reply to
Ah, this makes sense. Might be a worthwhile change in the code as I don't think it will affect performance to much.

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] URL generating & Suggestions In reply to
Hi Alex,

I had now a bit time to read your post in details. Right now I understood why you was afraid about the templates...
Quote:
What about links users make in their templates? Does a user now need to do?:
<%if d%>
<a href="<%db_cgi_url%>/page.cgi">
<%else%>
<a href="<%build_root_url%>
<%endif%>

For every link? Things like links to detailed pages, links to reviews, links to file uploads, all need to be handled.

The main goal of using clean_output() is so you can use the same template, without modification in either static or dynamic mode.

However I can say NO, the templates does NOT need to be changed.

The solution is easy, we have to treat the URL changes & treatment within the script, and not in the templates. I already solved this problem in my script. My old dynamic page display script in Links 2.0 worked as following:


First, I had a few config options, to decide where we need to use dynamic and where static URLs:
Code:
# Build dynamic categories (the category pages will be displayed dynamically)
$build_dynamic_categories = 0;
# Build dynamic span (more) pages (all more pages will be displayed dynamically)
$build_dynamic_more_pages = 1;
# Build dynamic new category (the page where links of new pages are listed, will be
displayed dynamically)

$build_dynamic_new_category = 0;
# Build dynamic new pages (the pages with new records, will be displayed dynamically)
$build_dynamic_new_pages = 1;
(Combining the options above, the script was able have several usage modes: static, half dynamic,
dynamic. The config above shows my half dynamic mode. Category pages was rebuild each time, but all the more pages was displayed dynamically. This way I was able to speed up site refreshing, having it many times faster than before)


Alex, now let me show you a few examples, how I solved the dynamic or static URL generating in the modified Links 2.0 scripts. Of course, there were much more changes, but here are some to be able to imagine how I mean.
E.g. in site_html_templates.pl/sub site_html_print_cat:
Code:
$url_dynamic = "$build_category_url?cat=" . &urlencode($cat);
$url = "$build_relative_url/" . &urlencode($cat) . "/$build_index";
($build_dynamic_categories) ?
($output .= qq|<strong><a class="link" href="$url_dynamic">$category_name
</a></strong> <small class="numlinks">($numlinks)</small>|) :
($output .= qq|<strong><a class="link" href="$url">$category_name
</a></strong> <small class="numlinks">($numlinks)</small>|);

or
E.g. in site_html_templates.pl/sub site_html_category:
Code:
($build_dynamic_new_category) && ($build_new_url = $build_new_cgi_url);

or
E.g. in nph-build.cgi/sub build_category_pages:
Code:
$more_url_dynamic = "$build_category_url?cat=" . &urlencode($cat);
$more_url = "$build_relative_url/" . &urlencode($cat) . "/";
($build_dynamic_more_pages) ?
($next = $more_url_dynamic . "&page=$next_page") :
($next = $more_url . "more$next_page$build_extension");

This way there is simply NO NEED to do any change in templates.
The solutions are easy, just depends on you, if you want to implement them as I suggested in my previous posts:
184373 and
184565 and
186947.

Also I have to correct my suggestion posted in post 184373 in point 2), how to have the URL parameter names configurable. So would be better like:
$CFG->{url_parameter_names}{category} = "g";
$CFG->{url_parameter_names}{page} = "page";
$CFG->{url_parameter_names}{order} = "order";
$CFG->{url_parameter_names}{sort_col} = "sort";
$CFG->{url_parameter_names}{num_hits} = "nh";
$CFG->{url_parameter_names}{max_hits} = "mh";
etc.

Alex, what do you think now about these suggestions? I think, they are getting mature enough to start implementing them.
What is your current opinion?
Do you need more info or have more questions?
Should I start the development of these suggestions, and then pass a patch to you (based on LSQL 2.1) or you want to do the development yourself?

I need to continue my developments, and all we discussed here, are critical part of my site development. The reason, that I didn't started the development myself is, that I don't want to lose the future upgrade compatibility with Links SQL 2.x-3.x, especially because changing the clean_output() usage,
modifies the full Links SQL page display procedure (this is also true for URL parameter name changing).

That's why these features & improvements are so important for me...

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...
Quote Reply
Re: [webmaster33] URL generating & Suggestions In reply to
Just pulling to top. Alex, please don't miss reading my prev post.
Quote Reply
Re: [webmaster33] URL generating & Suggestions In reply to
Hi,

I like your config options for dynamic/half dynamic/static modes. I'll look at implementing something like this.

I have to think a bit more about the template suggestion though, and look at the examples. The most important rules are:

1. A user can switch between dynamic and static without altering their templates.
2. You should not have any <% if %> logic in your templates to handle dynamic/static. All of that must be handled by Links SQL automatically.

I'm not yet 100% convinced that what you propose will work, but I'm going to think about it a bit more. =)

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] URL generating & Suggestions In reply to
Quote:
I like your config options for dynamic/half dynamic/static modes. I'll look at implementing something like this.
I'm glad, that you like my solution. I hope you will be able to implement this in near future.
I can help your developments if you need help (remember, I have done it already).


Quote:
1. A user can switch between dynamic and static without altering their templates.
Yes, this is possible. I just change my config file, and now works as Dynamic, Half Dynamic, or Static, without changing any template.


Quote:
2. You should not have any <% if %> logic in your templates to handle dynamic/static. All of that must be handled by Links SQL automatically.
I don't use any <% if %> in links of my templates.
Categories and links are displayed by using the usual <%category%> and <%links%> tags.
This means, that all dynamic/static handling are done internally within Links 2.0.
So will be also done automatically in Links SQL after this is implemented.
I could help you implementing this feature also into Links SQL (I've done this already). I also use CSRCS, so I can even give you diff files in result, based on LSQL 2.1.


Quote:
I'm not yet 100% convinced that what you propose will work, but I'm going to think about it a bit more. =)
Ok. No problem. Check the examples, and think about it.
I'm sure you will be 100% convinced. Wink

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...
Quote Reply
Re: [Alex] URL generating & Suggestions In reply to
Alex,

You wrote, that you will think about the config file format, and you can see the advantadge of having config options referencing others.

Do you have plans to change the config format to be able to reference one config option in other?
From time to time I find, that this would be very useful.

I hate that I have to derive the server path & URL from config values like $CFG->{admin_root_url} or $CFG->{admin_root_path} or script path.
The config even misses such config variables like $CFG->{db_cgi_path}...

Do you have such development plans, which affects the plugin config or you throwed away this idea?

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...