Hopefully, the next version will be released tomorrow, so we can get started with it.

Many things have been talked about here, and I've got lists of things to do, and being planned, and I'll try to set up an area in the FAQ that will coordinate what people are wanting and doing.

My plans, for the most part, are:

1) Integrate the reviews/ratings into the links system, and let it carry through the user registration so it's available in all additional modules.

2) Banners and advertising module to allow targeting based on user preferences, and location within the site.

3) Catalog/shopping system, to allow targeted selling, and advertising based on the links within the system, _AND_ to allow the creation of a catalog that can handle unique/one-of-a-kind items as easily as stock/inventory items.

4) Changes to the editor area to allow editors to edit, and work on the links and still have them validated by an Admin, or not, as needed.

5) Integrate fully WWWThreads so that the forum is an interactive part of the Links site (this idea is still somewhat nebulous, and it needs the rating/review system). Now that w3t is template based, it's worth spending time on to integrate into the system. With two development groups -- one Links one Forum -- more features should be available in any unit time, but you'll need to have two licenses.

6) Convenience features in the Admin -- selective builds, partial builds, etc.

7) Flexibility in the "validate" routines to do bulk, keyword, and field validation (such as any link already edited by an "editor" or by a certain user.

8) Book store, using the advanced features of Links and templates to allow you to target book sales to areas of the site, and give users a choice of places to by using your affiliate codes (Borders & Amazon use a standard referer to track sales, Barnes & Nobles doesn't... (unless it's the other way around B&N does, Borders doesn't) )

9) Image uploads, and automatic thumbnail generation for logos, product shots, etc.

10) ????

That's all I can see on my desk at the moment, but the stacks are 2 feet thick and 4 feet across, so I'm sure there are things I'm missing .....

But those are the major ones I, or clients, have asked for.

They are all in somewhat of a limbo now, since they depend on the new Links USER modules to go into effect.

After being on the web, and visiting sites, I really want my user information carried through to related sites, and integrated merchants. I don't like entering my information a dozen times, keeping track of passwords and ID's, and profiles, etc. One central location per related site is my goal -- for forums, links, shopping, books, targeting, ratings, reviews, even the Email.

Big plans :)




http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/

some reason i have a feeling alex made a review.cgi..

i just have the feeling.. it'd be nice if he did really.. then all i'd need to do is make my graph.cgi to the new version and immediately have a review system up..

i mean why wouldn't he make one.. just about every directory has them..

Jerry Su

Hello, pugdog...

One thing that I am working on, but I am waiting for the next version before really diving into it...is a search agent capability for "Members" that stores up to six search agents (similar to Monster.com).

Any help with this will be greatly appreciated...I have created some fields in the "Members" table for storing query string information. If you know of any better method of doing this, let me know.



Regards,

I know Alex has indicated that there is a review module, supposedly. But I'm sure it's going to be a basic unit, and I know I'm going to want some added functionality out of it, such as users being able to see all their reviews, get a list of their ratings, be able to see which links/sites they've rated, etc.

I also want to be able to tie that in to perhaps other user-profile features, such as the ability to reveiw and unsend postcards and mail, etc. I posted this sort of feature (about how to decide if a database item could really be deleted, or if it was still unread, or on someone elses "hold" list) in a message last month, and it's very related to the same logic of ratings/reviews.

Also, as you point out, there will be some room for different graphic output modules, since not everyone is going to want the same look.

Some people may just want a numerical or star rating, others may want a whole big breakdown like on cgi-resources (but with some more compact, neater presentation).

Some people may want single line comments, or they may want a fully functional "review" feature like a movie site where 100 different people (from paid reviewers to visitors) rate a movie and post a long-ish review.

The real wait is for Alex to release _something_ so we know what direction to take. Even if it's a beta, it will be close enough to the stable version that we can start to add to it, and maybe get these additional features working by the time the stable version is released. I'm not against a beta. With so many inevitable changes, the big thing is to see what they are, and where the code is going.

http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/

I'm not exactly sure, but you might want to think about something like I'm doing with the book module.

Don't keep any query strings in any profiles. Keep them in a variable in the HTML_Templates.pm file, or even as sub-templates to call from in the search routines.

In the user profile you'd add fields for search1, search2, etc, and only put a name in each field that corresponds to the variable.

At some point, you may find that breaking the user profile table down into several tables linked by the ID, will allow you to modularize the various information you are keeping about a user. For instance, the main user table needs only the key data for the other tables, and primary information that the various programs need -- ID, name, password, email, and maybe the search features if those are used often. Address, payment, and other information should be in a different table linked by ID, and so forth.

But, normalizing and performance tuning the tables is a whole other discipline in itself :)



http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/

Ah! That sounds good...However, the problem I foresee is including all incidences of searching the database...since my hope is to keep the same structure that I have with Links 2.0 (which will take some tweaking)...this would be problematic to account for all types of query strings.

But that is a great suggestion you've provided. I'll mull it over and see what I can come up with.

Thanks!

Regards,

Ok,

If you are trying to store user-preferences query strings, forget about the User profile at _all_.

You need to create a new table to hold the query strings, and link it to the user table by ID or username.

Then, when a user requests the search page, you do a SELECT FROM QUERY_TABLE where User="the_user" and use that output on the template page to show the user his various pre-selected choices, as well as any defaults.

If that is what you are going to do, and use an arbitrary number of queries and formats, create a table for them, and link it to the users, don't fatten the user table needlessly.



http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/

Thanks, pugdog...I have been doing some comparative research of different search agent scripts...and what you have lately suggested might be the best approach.

What I am planning on doing is setting up a form that users can input their search preferences (rather than parsing the data directly from the search results page...although latter on I might add an option to automatically add the search preferences via a one click button or link) and store the data in a new table called Agents and using your advice to link the ID of the user to the user table is a great idea.

Thanks again.

Regards,

Eliot

I'm not sure what you mean by the search agents and query.

but most search agents have a standard query. If that changes, you want to update the "central" query string, and not a string in 1000's of different records.

If you want users to store specific queries such as "search for girls and beer" then you would want to store the TERMS with the engine ID, but _not_ the search URL/query string itself. That you would want to fill in from a central list of the query strings.

That way, if someone reports the AV search is no longer working, you can look at the string, make any changes, and every search is again working.



http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/

Here are some examples of "Search Agents":

http://my.monster.com/
http://my.careerbuilder.com/

Basically, these sites allow you to add values for arguments in queries via web forms...like the following:

Category
Keywords
Date Ranges
Salary
City
State

etc....

Then when you access these sites after setting up your profile and agents, you can access the stored queries by clicking on one button...very useful for multiple types of sites (especially E-commerce sites where you can store preferred merchandise that you want to search for in the future).

And another thing I plan on working on is emailing results to users based on their preferred queries.



Regards,

Eliot

Ok,

you will have to come up with a "rules table" for each of the sites. Decide what aggregate information you will need for all the search engines you support, and create a "query table" with that information, plus the userID/ID key field.

When someone wants to enter a query for search_engine_1, they are presented with a form that allows them to input their information as required by that engine.

If they want to do a multiple engine search, they enter their query in one larger form, and your back-end decides how to handle the data.

This is where the "rules" come in.

Not every engine will call it "query" or "Term" or something, so you have to have a mapping of the user input, to that specific query engine.

That is the "template" for that query engine.

Then, in the "query record" you store that query data only, not the search engine.

If you want to, you could store the search engine as well, but that starts to add complexity that is unnecessary.

You could let a user review their list of search queries, then pick the search engines they want to submit it to, using check boxes.

Let's say you want to store that data with the user's query so you can fe-fill out the form.

DO NOT (I repeat DO NOT!) try to create a new table entry for each search engine!!! What a waste! Use a TEXT field, and code the string for the search engines with which search engines were selected ---- AV|YH|NS|AOL| etc....

When you read their entry, parse that field 'split' it on the | character, and stuff each of those matching values into the corresponding search engines you support. If you don't support a search engine any longer, your OUTPUT template will simply disallow that field.

Following???

If you support ADDITIONAL search engines, those engines will just show up as unchecked, and the user can select them for the next query.

Make sense?

If you want to get fancy, you can add the "default" user seacch engine string to the list of user_profile parameters you store, and then allow a check box to "use default" search engines if "stored" engines don't exist.

Make more sense??

Again, you are only adding one "preference" tab to the User Profile table, and everything else is kept in the query table. A user can purge their query table, or you can limit it to the x-most-recent queries or the last 30-days, whatever.



http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/

Thanks for the response...Although I am not looking at having people search the WEB, only my directory!



The search agent stores preferred queries of MY directory in a table and then users with profiles can login and use those "agents" to conduct similar searches RATHER than having to input the same information time and time again.

Although your suggestions about using different web search engines is neat...and I may implement in the future.

Thanks again for your input and I hope you understand my goal better now.

Regards,

Eliot Lee

Well, if all you want is a user to be able to search your site, using search.cgi and a query term, or on certain fields, then just apply the data above, but you'll only have one search engine template (you can expand that later).

Store the data in a table for each query, you can even show the 10 most popular queries, or 10 most recent, etc.

Use the same tables, but you won't have to keep track of the search engine, only the keywords/search terms and fields.

http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/