Something I've said for years, and which I'm now actually proving in my new program, is that the real power of GLinks/etc is in the underlying code.
The 2 years of delays in rewriting the underlying engine code have paid off, as upgrades, updates, and extensions are mearly updating different modules, or fixing up objects.
The power of the GT::SQL engine code is unmatched. There is *NOTHING* out there that compares, and I've hit error codes on other sites I've been using that show they are using less powerful and maintainable interfaces to the DBI system.
The major power of GLinks is in the templates. Not the luna set, or any other set, but in the actual template engine itself, GT::Template
Most of the sites I've been using have been using PHP, and that is a real problem. I really don't like PHP, and it's origins are in bypassing system and website security, which really rubs me wrong.
The GT::Template engine gives you the same sort of power of PHP (embedding functions within your templates) without actually violating the rules of separating the interface from the implementation.
You don't actually embed any code into the templates, only a tag, or function call (a longer tag) and you can pass in parameters, get values back, and even abort processing midstream and display other templates or output.
The program I'm about to release in beta is a great example of the power. It is a collection (and update) of a large number of plugins, globals, and other code we've written over the past 4-5 years. It's been only partially modularized for this program, but will be fully modurlarized in later versions. The routines are all in modules, and care was taken to make sure that as few $IN->params were used as possible, and that most values are passed explicitly, or collected and passed by the main routine. A number of routines were changed so that there was a script callable and template callable version. Every time a new "problem" was encountered in the program flow, we wrote a new function or modified (if possible) an old one to handle the new requirements (for instance, one of our display functions had a version for each sort of input box. since it was only a wrapper around the HTML functions, we added another parameter, and now one function is called from the templates; you simply pass in 'radio' or 'checkbox' if you want to force the data display to something else. One set of code to maintain for everything).
The past week or two I've been polishing up the look and feel, mostly template work. I've made extensive changes in the look/feel of the site and except for a few minor bug fixes I never had to touch the perl code to do it! The functions were already built, and it was just a matter of setting up the template tags to access them.
*NO* other program or system out there offers this huge amount of power and flexibility.
Once these programs roll out, we'll be releasing code libraries, where you can add in the functions you need for your system as you need them. Code libraries will include the display routines, access routines, image routines, ratings and reviews, profiles, and much more.
Once we do, I think other developers will catch on to this type of development, and even more libraries will be released.
There is no need to have specific scripts and output templates. The template parser has the power to allow you to simply request a certain set of data (by calling the right routine with the right input values) and get out almost anything you need in several different formats that can be used to display the data using stock and standard display skills (such as the <%loop%><%include template%><%endloop%> construct.
Just a few thoughts for anyone else looking to purchase GLinks, and wonders about what else is out there.
Yes, I've seen some slick interfaces, and some great admin areas, and such. But none have the underlying flexibility of GLinks, nor the power of the GT::SQL or GT::Template engine code. It's not perfect, but nothing ever is. With power comes responsibility, and some of that is having to write your own templates and maybe contract out for some modifications.
But, the fact you *CAN* do that, and that the process allows developers to write and invest time in stuff that can be used more than once, is the *real* power.
Oh, and yes, everyone has "plugins". But, with GLinks, I almost never use them as intended. The fact
Gossamer Threads spent the time for developing the features for plugins, means the code was reworked and you don't have to write "plugins" you can simply write functions or gobals. So, plugins do exist, and can allow easy code sharing, *BUT* you don't have to actually write plugins, you can simply write ANY sort of perl module and upload it to the Plugins directory, and access the functions from within the templates easily. This is different from other programs, which need specific rules of access. GLinks plugins are pretty much like any other module.
Happy Hunting
PUGDOG� Enterprises, Inc. The best way to contact me is to
NOT use Email.
Please leave a PM here.
