I'm overstretched to implement this so I'm throwing it out for anyone else who wants to try it. If anything when finished, it would give you an even more flexible links SQL installation. So here goes.

In a nutshell, this plugins would allow arbitrary link record in the Links table can be 'linked" to another record in another table. This is cool because you can have many different types of records in any of your categories and depending on what a link has been associated with, will be displayed differently. It would also allow for future flexibilty by using a somewhat write once, use many approach.

In the Links table, you'll need at least two columns: Table, TargetID. These pair of values points to another arbitrary table, which has at an integer autoincrement primary key. The rest of the columns in this imaginary table is totally up to the user.

So here is where the wacky stuff happens. In the templates such as links.html or detailed_links.html, you'd have a new function call. This call would generate the html for the display of the extra information this other table carries. Something like <%Plugins::MyPlugin::generate_associated_content%> would suffice.

You'll also have to create an admin interface that will allow you to associate template files to tables, so the generator knows what template files to pump the data through. As well, you'll have to subclass all the new tables to change data manip screens so that they'll have all the Links fields and specific table fields and properly handle interactions with both tables.

I'm not sure how searching should work, but hey, this is not my plugin.

Anyways, just an idea

Is this a coincidence or what? A few days ago I had a very similar idea.

Since many directories contain data of many types, this would be a very good solution.

Here are some thoughts:

1) in the admin, you can generate arbitrary tables (which will contain whatever you want), let's call them linkdata tables.
2) there is a master table, which tells you what linkdata table is associated with a link. The advantage of this is that you can associate many linkdata tables with one link.
3) maybe it would be easier to define the relations on a category basis, with some sort of inheritance from parent categories.
4) Add/Modify templates on the user side could be generated as you say.
5) Add/modify/delete would work fine, there are hooks to intercept this.

6) The major difficulty at the moment is the "Browser". Since the link forms on there do not come through the html-subclass of the Links table, it is almost impossible to manipulate the forms. I think this should be addressed for a future version of Links SQL. Or do you know something better?

Ivan
-----
Iyengar Yoga Resources / GT Plugins

Excellent!

1 & 2 : Right, like a resource index table. allows you to do a many-to-many relationship to link and other linkdata tables too

3. I don't know which would be easier. Though, I can see things getting tricker when it comes to stuff like search results. If a link resides in more than one category to which do you resolve?

4. Right, I was thinking that the script could generate an automatic template file when the new table was created. Then the user can customize the template to make it look pretty. I think I've seen your page builder plugin do this, very cool stuff, by the way.

6. The browser is a tight piece of code that I haven't worked with, so I'm going to have to see what other people think. On a hunch, I think it's going to be difficult if not impossible without major work and almost replacing the browser.

3. Search results are a problem even now when a link is in more than one category. As for the linkdata tables, the link could take information from all of the categories involved!

6. Just give us a hook for every sub that's in there. Define the form elements as Links:Category::HTML and Links::Link::HTML instead of GT::SQL::Display::HTML::Table. Those two things would help a lot to start with.

Ivan
-----
Iyengar Yoga Resources / GT Plugins

3. hmm... I think it just depends on implementation. I like to see to each link as an object without context, but maybe context is unavoidable. It might have to be that there are at least three contexts: link display, link detailed, and search result.

6. I'll have to take a closer look at the code.

Hmmm searching. I realise now that that is the reason why I did not pursue the idea any further.

If you have data in different tables, you would also have to change the search routine to take into account ALL the other tables... That might slow down things. On the other hand you could maybe put in a select option, indicating whether a table will be searched (in general). Or you could search the additional tables only when a special key is passed in (e.g. search_all=1)

Ivan
-----
Iyengar Yoga Resources / GT Plugins

might be possible to have a glut table which contains ID => Textfield and reference lookup. Search results would extract the proper text but it'd be hard to get filters working properly.

Hi,

I *think* what you are saying, is what I've been saying about extending the Users table to include the additional stats (that a plugin, or a webmaster might want to track).

I *think* it's also how I implemented my mutliple file attachment. I've been looking at my salvaged .cgi's and I think I had about 80% of that working... maybe more.

I'm working on that now, actually, trying to make it 2.1.1 compliant, and to fix some rough edges, but I hit a block in that my system was geared to look for images, and I have *not* been able to get netpbm to compile on my servers (maybe you could pass that on to whomever??).

If that could happen, I could probably release a beta of this sort of thing, or at least a somewhat targeted implementation (files/images) in a few days.

I will send you my code to look at, the .tar I was able to salvage. It's:

1) not well written, or smoothed out.
2) It's almost guaranteed to *not* work, and certainly not work well
3) It is *not* going to work with the most current version of Links, I think it was 2.01
4) It requires netpbm to be installed
5) It may require a date module (I have since changed that to use Links date module)
6) It is *probably* a version or two, and several bug fixes BEHIND where I was when everything crashed.
7) It's probably best broken up into modules to be used as the basis for making a working system.

You would probably want to try to install it on a separate site, with links 2.01, and see what it does. I don't think you can really see it in action without doing that, since a lot of stuff was put into the templates, and used includes, and such (not quite a php <G>), it's not really easy to grasp what the program is doing without setting it up.

If it's what you are talking about, maybe we can use it as a basis to go on with this project.

If you want this sort of thing as a "free" plugin, open source, or group project, I can probably work something out that would be extremely agreeable, I'm in a really agreeable mood lately <G>.

if nothing else, my plugin did think through a lot of the "logic" bugs, and problems you hit when dealing with uploads, attachments, and additional information.

It could be (easily?) extended to be any data, by simply bypassing upload routines, or adding some flags.

It would solve the *big* issue of multiple attachments, link additions and extensions, and such, and put that into the hands of the general user population.

BTW -- did anyone look at the revival of the "Dynamic flags" issue ?? These are flag fields in the Links table that would alter/add behaviour to links, and be able to be included in searches and such without altering code (from a users point of view).

This gets back to *how* does links know about these extra fields, from an "internal" point of view? Is there a way to hook into the central system to install this sort of "dispatcher" on *every* call to the Links table (or whatever table was extended??) (I think Alex had made a post about overidding the creator function, that *seems* like it would allow this??)


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

re: Link object

This is something else I had been working on from the begining <G> I think I posted several musings about this about a year+ ago.

In links, the base object (or conceptual object) is a "Link".

This is a piece of data, with a *lot* of attributes.

Some of those attributes are the stuff in the Links table. *BUT* those attributes also extend to any other table that has a LinkID field. This means the Cat_Links table (what categories it's in), the various search tables (what indexes it's in), keywords (what does a user see about this link -- a backwards look at it's search characateristics), attachments (what associated files or other data is with this link), it's "owner" (what user owns/controls the link), etc.

Not every program or script has to access every aspect of this link object.

Obviously, the Links::ID (LinkID) is *the* key piece of data, and in it's smallest form, a "Link" is just an record in the Links table,which would be an ID in it's most basic form.

The other major object was a User. This could have other data associated with it, tables, relations to other plugins, etc, as well as a list of Link objects. All keyed to Username. (It would have been *so* much nicer to have all tables use an autoincrement ID field as the primary key... username could then change....)

There are smaller objects, but most smaller objects are parts of the Link object.

You could extend this to other objects like a category, but that seems so much less useful in a hierarchial system than either of the above two objects which are the "free floating" data bits.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Hi,

I'm not quite sure I understand what this thread is about yet but I just wanted to add an expression of interest.

My database is a directory of shops so each link is information about a shop. My links table is growing all the time - I mean the actual fields in the table - as I add more and more information. I'm now at the stage where I would like to have extra tables so that for example I can add a selection of products (or even the whole database), multiple special offers, competitions, etc. for each link. Is this the sort of thing that you are talking about? I'm starting with the products table which I've just created but I'm now stuck on a way to edit it. It would be really useful if there was a way to modify the browser in admin to be able to choose to add tables to the table editor.

Hope I'm not too far off track.

Laura.
The UK High Street

>> In the Links table, you'll need at least two columns: Table, TargetID. These pair of values points to
>> another arbitrary table, which has at an integer autoincrement primary key. The rest of the columns in
>> this imaginary table is totally up to the user.

Ok... I've been thinking about this, and I don't see the need to do this, especially if you want "arbitrary" linkings.

Data normalization suggests this is a *bad* thing <slap> <G>

Create a "relations" table, which has a LinkID and a Table field, and if it's not a 1:1 extension of the links record, a separate TableID which is a pointer to a unique record within that table.

Obviously, LinkID is associated with the Links table, so you don't need to specify that, but you would need to specify the other table (unless you had table specific linkings, which starts to get messy....)

Why? Because in order to do that, you'd need another relation table, or you'd need to add an arbitrary number of fields to the Links table, or worse... store multiple parseable values in one Links field.... Messy.

But, perhaps you wanted arbitrary table to table linking as well?

You could have Table1/ID1, Table2,ID2 4-column pairings in the table, with the "default" Table1 being the Links table.

From Table2 you'd be able to find all associated Links, and from the Links table you'd be able to find all associated tables and table links.

This gets more complex than simply extending the system, using the Link Object as the primary, but it allows a table of 500 items (like books or merchandise) to be linked into a Links table of 5,000,000 items via the related table, without duplicating table entries.

Potentially, you'd want to do something like:

Links_to_Tables --> LinkID,TableName (main relations table)

TableName_to_Links --> LinkID, TableID (sub-table relations ie: specific table file)

Where you have a dispatch table, that lists all the links that have asked for extra tables, and then a table relation that links each LinkID to a TableID.

This would keep the size of the one main relations file smaller, and perhaps even be a more "normal" version of the database.

The call to the Links record would "fetch" the data from the Links_to_Tables table, and list the tables that this Link has relations with. If any interested the calling program, it could fetch that data from the TableName_to_Links table for that table.

No modifications to the Link record is needed. No limit to the number of arbitrary linking tables, or pre-set limits.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

That's exactly what it's all about.

Ivan
-----
Iyengar Yoga Resources / GT Plugins

Oh.... searches.

You'd need to add a "TableName" field to the search records, not just a LinkID.

Search would have to be "smart" enough to index all the tables, using the standard built in system, but flag each entry with a TableName.

Again, this would lead to some HUGE tables.... might be better to have search index each table separately, then do sequential searches if requested:

ie: Search Links Table (fast) [] (default) Search related Tables (slow) []

If you knew which tables (or you presented a list of search table potentials) you could allow the user to select which tables to include in any search, and cut overhead. This could be a dynamically generated list from a plugin repository, or simply hard-coded into the search template form.

You could then present "hits" based on what you found:

Caveat:: The Links table is *STILL* the main table, correct?? this is not a way to run multiple directories off one Links install?? Correct?

If so, then you would simply want to add any Links found by searching the related tables to the main list of Link "hits", perhaps with the added flag of "FetchTableNameData" to that Link (remember, post above... you present a list of tables the plugin might be interested in?? It's interested in any table with a "hit" for this link).


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

I wanted to bump this up a bit, to get some feedback.

I've been working on this, since this is the "core" or "nexus" of a bunch of problems, and plugins various people are doing. This is *not* a commercial plug in, I'm hoping it will become more a part of Links SQL in general, so it can be extended easily.

I need some feedback, since I want to see how the masses feel about this.

The concept is fairly simple, actually -- arbitrary tables extending the functionality of the Links record, or of Links in general.

The first tenent is to *NOT* alter the way Links is doing things, but to hook on, or extend what it's doing.

1) create a table "Links_Tables" which functions like Cat_Links, but keeps a record of what tables a specific link has relations to. This is a time saving device, and allows forward-linking. Each table will need to keep a pointer back to a LinkID to allow reverse linking. But that is up to the individual plugin/table author.

2) when a link record is requested (preferably when a call to get->($ID) is made, an automatic "fetch" from the Links_Table is made. What is returned is a list of TableNames that this link may or may not have active records in. It's up to the various plugins to make sure that the table data is fetched, or ignored. Default behavior is just to list the tables with a hot-link to the PluginName::handle routine with a notice like: "Additional information may be found on these links: ..."

The complexity of this is creating a dispatcher routine that will pass along the information to the correct plugin handler. I'm working on the flow of this, to make the dispatcher do as *little* work as possible, simply be a "widget" between the knowledge that extended data exists, and the actual fetching or manipulating of that data. Basically, it will only need to keep a list of plugins, table names, and the handler routines.

The "beauty" of this, if you will, is that it's an extensible, flexible, and arbitrary interface to any number of tables, with any number of fields -- WITH NO ALTERATIONS TO ANY CORE LINKS TABLES!

In the simplest form, a default "fetch" routine can simply take the tables returned in the first query, and append them to the links record.

If you've followed this far, the question is, do you have any suggestions, or feelings, about how the Links_Tables routines should be implemented?

The simplest manner would probably be pre_hooks to the site_html_link and site_html_display, but the problem is that you'd have to create a new routine for each template. The most elegant would be to probably subclass out the Links::Link subclass and override the default subclass in the Links.def, and in the table handler, wrap the calls to get, select and query_sth. It was suggested, that a new STH object may even be required.

If that last part sounded like Geek to you, it did to me too ;) The sad part is, I actually understand about 90% of it <G>, which is why I'm asking.

Is working on the subclassing method the "best" way to go with this, or is something more superficial?

Remember, the concept of this plugin or extension depends *only* on associating some TableNames with the fetched Links record. It's up to your plugins to use the system, and properly enter an entry into the Links_Table table, and register a handler routine.

Maybe an example:

You fetch your links record, and along with it comes $rec->{Links_Tables} = (TableName1, TableName2...)

It's up to you to do something with those tables. If all you want is the basic links record, you can ignore them, or send them to the default handler, but if you are dealing with the record from inside your plugin, you would want to process them.

Your plugin would also register a display hook, if it was to be called on link.html or detailed.html ...

A further explanation:

This would primarily be to allow one installation of links, to function as a multi-faceted system -- maybe one category would be a Classifieds, one a shopping cart, etc.

In general, only ONE plugin would be dealing with any given link, but maybe there may be a chain of one or two if a link has extra associations.

A link may have more than one entry in the associated table, so LinkID in that table would *not* be unique. An example of that would be for tracking attachments to the link, or for a shopping cart where you'd have one entry for "I Love Links" T-shirts, but you'd have one record in the associated table for each of the various sizes and colors you have in stock -- to keep inventory straight.

=====

So, any feedback? Comments? Suggestions? (Volunteers to look into writing the subclassing??) <G>


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Hi!
Just interesting if the plugin was ever released.
By the way will you pay for this plugin if somebody make one.

Thank you
Dmitry

Hi,

I'm still working on this.

I have a trilogy or perhaps better, a triangle of things I'm working on, each related very deeply and intimately to the others.

1) arbitrary attachments

2) multiple attachments

3) Image/gallery management

There are a lot of parts to this, and a lot of bits and pieces of codes. I'm over stretched on this, and there is no release date on the arbitrary tables. I *really* could use some help working on the subclassing concepts of creating the main plugin manager to trigger when a link record was read. This is a nuts & bolts thing that I really don't have the time, stomach, or inclination to learn to do and debug. It's a key feature of this, to do it right.

ie: every time a link record is read, a trigger has to go off to see if there are any arbitrarily attached tables to this link, then see if any plugins or code has 'dibs' on this read and needs to do something.

It's a dispatcher, probably analogous to the plugins dispatcher, that simply handles calls between the Links table, and any other tables out there.

This is #3 on my list, since I can (and am) building the other two programs much more quickly, and this will be something I work on over time -- unless I get some help. It could be something "free" to the gossamer community, since it was something I had been thinking about, Aki posted, and something GT would probably find useful in enhancing their basic engine. *BUT* time and man hours are the problem. This is a complicated piece of logic, and no one willing (or capable) of doing has the time to do it. Unfortunately.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Hi!
I see you point.
Nobody have spare time.
By the way i'm thinking to make a new plugin -
SE Web Spider.
Right know to create a full directory you need to go collect all the links manually or just wait while it will
grow by itself. But it takes to much time and effort to do this.
What i intend to do is to make plugin that will index Specific SE like Yahoo or Google and collect all
related link to the links DB.
Like say i created category, 'Web Design'.I put some keyword like Web Design, Web Developing select
category and select SE and just click index. So it will index SE(YAHOO) and collect all the links, it
probably will created some kind of index page, like list with all the links and info that you can take a look
and decide which one to validate or you can check validate auto.

Dmitry

Hey

That sounds real nice..

But can it be done is a question.. some have tried such a thing a while back and was faced with some problems..
Regards
KaTaBd

Users plug In - Multi Search And Remote Search plug in - WebRing plug in - Muslims Directory

Is this plugin still a suggestion or has it come to life yet?

Still more of a dream.

Participation never materialized, and despite a few dozen posts on potential ways to create/link the arbitrary tables, I never got any specific feed back on how to do it. I'm pretty certain this can be done, and with the plugin system, it can be sent through a dispatcher like the plugins system, but I don't have the time to pick it apart and figure it out.

A search on "arbitrary" and "tables" will bring up most of the messages.

If someone wanted to fund this, it might be a possible. But, I can only give this a few hours a week of thought, and sometimes not even that much. It needs about 10+ hours a day for 15 to 20 days, at least, and that is an expensive proposition to get the skelleton worked out. It probably needs an additional 10 to 20 days to get a working beta, and who knows how much time after that to get it really working. I estimated this at about 300+ hours of real work, not counting "brain time" which is that time you spend thinking about it, drinking beer or diet coke, playing puzzle games, etc to figure out the sticking points.

But, if this ever was accomplished, it would be really, really cool, as every new feature, category, or area could have it's own set of specific tables with additional data.

"joining" tables is part of the solution. As is separating searches into several different types. Depending on the size of the main directory, though, a separate search server/database would be required for performance reasons. Under 20 or 30,000 links, probably not. Over 100,000, depending on the number of associated tables, probably a necessity.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Well, we discussed already about this here:
http://www.gossamer-threads.com/...ary%20tables;#213838

Probably would be good idea, to open a new thread just for this subject.
So I opened a new thread, and maybe we could move there to discuss about it, if you aggree this.

Here the thread is:
Multiple object properties plugin

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

I know over the past 2-3 years, I've posted a *lot* of musings on this.

I'm not one for trying to generate revenue from my *programming* but rather my time, so posting programming ideas, or code, is something I do.

Most people can't apply the fixes, and if someone can, then their efforts should give back to the whole. We tried to write a code-license for Ultranerds, and I may get back to it, that is something of a mix of GPL, CL, and others, where you can use the code, but *any* modifications *must* be given back to the community at large.

Otherwise, it's a copyright violation of sue-able proportions.

If you want to collate all my musings, with yours, and with Aki's, I'll be fine with that. I wanted this as an open-source group project anyway. Since if we can achieve this, GT may have no reason to *not* release thier code engine as GPL. In that case, we all win, since I have no doubt it's the best code engine out there for SQL and template parsing. It could put PHP out of business!

The GT parser is really awesome, and Perl has advantages that are so far beyond PHP or mod_php, that it's hard to discuss. Perl code is *never* ever shown in a server burp, but PHP is. That can be major security holes, since if google happens to index your site at that time, it's there for the google hackers to use. And, believe me, even my brother, who is a computer novice of the highest order, someone who considers a key (those metal things with teeth) a high-tech device, used google to hack into his account at a major institution, and *that* is really, really scarey.

(btw... we've had nothing but problems with our bathroom since Novembrer, and Cole Plumbing is about to be villified on my http://SquirrelHillNews.com site, and I'm "drunk" for the first time since my freshman year in college in 1980. So pardon any mistakes here.... But we had a sink overflow, that poured into our dining room *AGAIN* after $20K of bathroom repairs, and caused us to close our shop for 2 hours to clean up the mess..... All our new ceiling is ruined, and I'm so pissed off, I can't begin to describe it. So, please pardon any mistakes. I am typing things I don't remember typing.... but 1/2 a bottle of wild turkey will do that.... the good stuff... Russells Private Reserve... goes down like water. Last time I did this was 1980, and 2/3rd a bottle of JD did me real good. I woke up 15 hours later, without a hangover, ace'd my Biology final, and got an a- in orgo. So, while it's good to not drink and type, I'm not taking that advice at the moment. )

But two things I would love to see as a group project are

1) arbitrary tables, to extend the functionality of links
2) cascading style sheets to apply colors to the current Luna set of templates



PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Just wondering, why you did not mention this thought, in the
CPAN release of GT lib (or modules)
thread...


Hey-hey, my friend! Take care of yourself!
So much "firewater" can make your tomorrow day a bad dream


Well, this could be possible.
However if I do not have a regular income, I can not really afford free developments in my free time.
I will be able to help in such developments only, if I will have a good income, so I will be able to spend my free time to donate some efforts to the public domain.
However I don't know, if we have any tool & environment for group developments.

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