Gossamer Forum
Home : Products : Gossamer Links : Pre Sales :

Links vs. In-link

Quote Reply
Links vs. In-link
I'm in the process of evaluating several different links managers. I was hoping someone could point out some advantages of LinksSQL over In-link (assuming LinksSQL PHP edition, and ignoring the price difference).
Quote Reply
Re: [Doug Nelson] Links vs. In-link In reply to
Hey there Doug!

I did a search in this forum using the keyword Inlink. 8 search results came back. You will find Inlinkv LinksSQL talked to death.

Hope that helps
Quote Reply
Re: [Ian Conza] Links vs. In-link In reply to
I actually did that already. Aside from the fact that Links is "better" and that perl is "better" there's not a lot of hard information.

Assuming LinksPHP vs. In-link, there's no need for perl to even be mentioned as a comparator. And since LinksPHP isn't even out of beta yet, there's no way to compare track records.

I guess I was hoping someone here had used both, and could state clearly the features they don't share.
Quote Reply
Re: [Doug Nelson] Links vs. In-link In reply to
The PHP front-end has only been available a day or two so people won't have had much chance to play or compre yet.
Quote Reply
Re: [Doug Nelson] Links vs. In-link In reply to
What do you mean "hard" information?

I believe that the thread in question about comparing the two applications does provide good set of benefits and disadvantages...it would be difficult to have a thorough comparison since users here USE GT products, like LINKS SQL. So, you will not find an unbiased or objective review of the two products.
========================================
Buh Bye!

Cheers,
Me
Quote Reply
Re: [Doug Nelson] Links vs. In-link In reply to
I've long ago gotten away from "this is better" across the board statements.

You need to evaluate your short and long term needs, then look at the features of the products available, and the development history (is it going in the direction you want, or have the developments been in other areas).

You need to look at the accessibility of support and help.

You need to determine if the code is high-grade, and maintainable. Is it efficient, and easy to understand. Can I honestly base my future on the code - even if the company that wrote it stops supporting it (that happens for all sorts of reasons).

When I looked at all the issues, I chose Links SQL and GT as the company. Links SQL code is "fresh" and not based or gounded in "old" thinking. It is object oriented, modular, and fairly well layered. "hacks" are minimal, and are always being turned into better code.

In the Perl vs PHP -- there are different needs. Perl is much, much, much more powerful. It's more mature, and a much wider base. It can stand alone, and run server applications (OS applications) and things that PHP just is not set up to do. PHP is easier for an ISP to set up, and allow their customers to run. It has the ability to run where mod_perl will not.

(That said, comparing PHP to standard perl is unfair. You need to compare it to mod_perl).

In addition, the GT template processer is getting better, so that PHP is becoming less of an issue than it used to be.

Again, it's what is better for you, and what your way of thinking is.

I prefer PERL, over PHP for many reasons. I have used both, but I find PHP to complicate the templates and the output rather than simplify them. I _LIKE_ unlinking the display from the data and the process. I also like the fact perl scripts do not lie in the webspace, but outside the public tree.

As there is more XML and other stuff added to the templates, PHP is going to just start to look very, very complicated, and there is _NO_ good editor out there (even for HTML!). I still do virtually all my HTML by hand, since it's the only way to ensure the "stream" is what you intend it to be. WYSIWYG editors add too much "extra" to the files to be trusted for critical applications.

Again, this is my personal preference, but you'll find most people with complex layouts have done it by hand, using include files, sub sections, and in some cases a well designed CSS file. CSS is really a way of improving the HTML by creating "blocks" that can be changed by changing one format parameter. Once you start to use it, you'll find it very, very helpful. But again, the more "fancy" things you ask it to do, the more disappointing it becomes.

HTML is still the workhorse of the Internet and Web, and while these other formats are out there, they are less useful until "perfected". Too many ideas, no standards. HTML has been around long enough that it is "standard" and still -- MSIE NN and Mozilla display it differently.

So, the short answer is -- the better product is what you yourself need. The long answer, is posted above :)




PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.
Quote Reply
Re: [pugdog] Links vs. In-link In reply to
Quote:
I also like the fact perl scripts do not lie in the webspace, but outside the public tree.

This is something that seems really important to me. I am very new at webmastering, but I really like the idea of having the code tucked securely away from prying eyes. Even the purchasing of a script (vs. free) helps, as everybody doesn't have easy access to the source code. This is more a general statement of likes and not really a Links vs. In Link commentSmile
--
Rob

SW Montana's Online Community
Modular Model Railroading
Quote Reply
Re: [pugdog] Links vs. In-link In reply to
That is an unfair description of PHP, as it not only allows you to seperate your HTML from your code, but it also allows you to store things away from a public directory.

Links SQL's PHP front end has no HTML in the PHP files. They have a print_page function that loads a template and displays it. It is just as possible to make GT's template module in PHP as it is in Perl. Many people say that PHP is no good because HTML is mixed with Code. In actual fact, most scripts now a days do not do this.

Secondly - You can have all your PHP functions in a seperate directory. Then in the HTDocs directory simply check an action, include the appropriate file and go from there.

I agree that Links SQL is much better then in-link, but simply because it uses Perl which is "much, much, much more powerful" Crazy is not why. Links SQL is coded very well which is why it is very good.



Cheers,
Michael Bray
Quote Reply
Re: [Doug Nelson] Links vs. In-link In reply to
Hi,

I think the fact that you can add as many fields as you need to Links SQL extremely powerful. In-Link limits you to 6.

I bought In-Link, and found it very clunky and slow.

Just my .02,
ATKOgirl
Quote Reply
Re: [ATKOgirl] Links vs. In-link In reply to
The only good point about In-Link is that the design is nice and clean.

Last edited by:

RedRum: Nov 13, 2001, 7:15 AM
Quote Reply
Re: [ATKOgirl] Links vs. In-link In reply to
ATKOgirl:

Does this mean you have a spare In-link license? :)