Hi there,

I've search links 1.x forum with little luck on any new mods.

I've got a site that is stuck in Links SQ: 1.x can't upgrade because 2.0 is less flexible in some ways while more so in others. Not complaining mind you, I'm just wondering if there have been any advances in template parsing that would allow any of the following:
if(not)? elsif else parsing
unless parsing
<set variable = xxx> parsing

essentially wondering if any advances have been made to linkssql1.x parsing that currently exist in linkssql2.x parsing.

Again, the site I'm working on is totally incompatible with links2.x and I can not upgrade. Any advances....


peace.

Nope...you'd have to play around with Template.pm yourself...development of LINKS SQL v.1.X stopped a long time ago, and many LINKS SQL v.1.X users have upgraded to LINKS SQL v.2.X.

I, myself, will not be upgrading to LINKS SQL v.2.X for a long time...took me two and half months to upgrade all MODS from LINKS 2.0 to LINKS SQL v.1.X, and I imagine that it would take just as long to upgrade from LINKS SQL v.1.X to LINKS SQL v.2.X (yes, even with the "robust" plugin system).
========================================
Buh Bye!

Cheers,
Me

Thanks for the quick reply,

For the most part, I've upgraded the sites I work on, but there's one that just can't be upgraded, so I have to live with it and a better parser would make like much easier.

Oh well, I'll get working on it myself then.
wish me luck.

peace.

Good luck...
========================================
Buh Bye!

Cheers,
Me

Hi,

Your best plan of attack would be to try and replace Links::Template in version 1, with GT::Template from version 2. So look for calls to Links::Template->parse, and replace it with GT::Template->parse.

Then you will have the same parsing ability as in 2.x. By the way, what part don't you find as flexible?

Cheers,

Alex
--
Gossamer Threads Inc.

HI Alex,

Thanks for the tip. That's what I ended up doing and am happy to say it worked wonderfully. There's a minor changed in DB_Utils.pm that had to be made, the template parser from 2.x integrates easily with 1.x.

What's not as flexible about 2.x as 1.x was some mods that I did in 1.x that can't be done in 2.x. Specifically the ability to turn links into a multi db system with one version - much in the same fashion that dbman was done(at least in the nonsql version ages ago.

This site I've been working on for the last 3 years has the following - An artisans database, a links database, a calendar database, a poetry database and Feedback database. All use a modified version of linkssql 1.x that requires the addition of the following parameter almost everywhere - script.pl?db=something.(making it work everywhere though was quite a chore), but I had to have some way of being able to store wildly different information without having 300 fields for different database. So, this way, each db has it's own template sets, directories, path images folders, uploading capabilities without using a second version of linkssql1.x
Anyway, links 2.x seems pretty much built in defense of someone doing that - ergo less flexible.

peace.

Hi,

Not at all! You would still need to modify the code, but it's quite easily done. The main thing you must do is get a different $DB depending on what database you are using. So in Links.pm, where it says:

$DB = GT::SQL->new ({ def_path => $CFG->{admin_root_path} . '/defs', cache => !$MOD_PERL, debug => $debug });

you need to make the def_path dependant on what db= was passed in. That way $DB will represent the database passed in.

Cheers,

Alex
--
Gossamer Threads Inc.

You can take advantage of the new PHP front end to Links SQL 2.x That way you can put PHP code directly into the templates which gives you a much wider range of options.

Cheers,
Michael Bray

Not really, as with globals you can put perl directly into the templates giving you just as wide a range (and you can use our SQL libraries for very easy access to the underlying data).

Cheers,

Alex
--
Gossamer Threads Inc.