Hi,
You aren't stealing thundar <G>
I went off on a different direction for awhile, and actually, it's helped me rethink how to do it all.
There are two ways. You can leave Glinks/Links as a backbone ,and try to hang all sorts of ornaments off it, or you can totally rethink the whole concept of what Links is, and simplify it all <G>
What I did/am doing with the ImageSQL etc programs (I have about 4 in parallel development at this point) was to re-think the whole concept of how to manage data within links. Rather than build a framework on top of a framework, I decided to use the User as the key piece of data, rather than the "link".
When you think through that, and expand the user table to include all the good stuff about a user, preferences, likes, bio's etc (or hang it off an aux table from Users) you suddenly clean up the whole Links database.
Now, you can do two things or more, but basically it comes down to two things.
1) when a user joins (or exists) automatically set up a category for them make them "editor" and let them go at it,
or
2) allow a user to request a catagory set up and be made editor, etc.
what happens is this.
1) you suddenly have access to *all* the features of Links -- Users, Links, Categoris, Editors, etc. With all the plugins, features, and stuff already written.
2) You only have to make minor modifications to some access scripts, and such to enable it all. You don't mess with the guts of it all.
3) It suddenly clears up all the excess stuff you are thinking about having to add it. <G>
Using CSS, the power of custom templates, and such, you can turn a category that is "owned" by a user into a special sort of beast.
You give that user "power" to do things in it, such as set up categories (or pre-set categories with special features) to which they add "links".
When the ImageSQL program in the Models and Photographers Gallery Lite version is released, it will resemble a blog in many ways. It won't *look* like a blog, because it doesn't have all that spammamation stuff like track backs and pings, etc. It does allow a user to create a miniature "community" of their own, posting images (mainly) (but it could be anything -- stories, articles, whatever you configure your link to do), getting comments, reviews, ratings, and all sorts of feed back. In addition, it will allow networking, connections, and users inter-linking their links with others (eg: a photographer who posts a picture can link to the models, stylists, locations, etc in that image).
So far, the only major issue I've run into is the User table has no auto-index field, and the Auth_Community for GLinks would have to be modified as would the Community modules to allow using the similar format for GForum for GLinks. This would allow users the flexibility to change the Username, but not lose any of their links or data.
Since "user" would be an end-node (or leaf) in any tree (no public categories or data areas would hang off a user) using a category to represent a user makes total sense. everything below that "user" belongs to them, and isn't part of the "public" system. (It's public, in the respect it can be viewed, but it's not a "commons" area, or part of the base structure of the site).
I've moved off in a slightly different manner, since I see blogs as nothing but "spam" in their current incarnation. 90% are just out to send out and recirculate bogus trafic. Some are not even circulating actual articles -- just jibberish.
The concept of a wikki, merged with a blog, in the structure of a Links hierarchy (rather than the anarchanistic circular linking of a wikki) seems to be the best format, for what I want to do, for developing new content offerings. You have a commons area, but people can congregate or group themselves along the walls, or perimeter of the various content areas to which they want to belong.
The best reasons to do it this way, are you preserve all the power of what is built into Links, and you are just adding on through the normal system of updates. Each update/upgrade gets applied to all users, but all users still have their own access/control limited by the core security of the system. It will (should) survive upgrades, and still allow you to run a very flexible, varied, and completely customized site.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
You aren't stealing thundar <G>
I went off on a different direction for awhile, and actually, it's helped me rethink how to do it all.
There are two ways. You can leave Glinks/Links as a backbone ,and try to hang all sorts of ornaments off it, or you can totally rethink the whole concept of what Links is, and simplify it all <G>
What I did/am doing with the ImageSQL etc programs (I have about 4 in parallel development at this point) was to re-think the whole concept of how to manage data within links. Rather than build a framework on top of a framework, I decided to use the User as the key piece of data, rather than the "link".
When you think through that, and expand the user table to include all the good stuff about a user, preferences, likes, bio's etc (or hang it off an aux table from Users) you suddenly clean up the whole Links database.
Now, you can do two things or more, but basically it comes down to two things.
1) when a user joins (or exists) automatically set up a category for them make them "editor" and let them go at it,
or
2) allow a user to request a catagory set up and be made editor, etc.
what happens is this.
1) you suddenly have access to *all* the features of Links -- Users, Links, Categoris, Editors, etc. With all the plugins, features, and stuff already written.
2) You only have to make minor modifications to some access scripts, and such to enable it all. You don't mess with the guts of it all.
3) It suddenly clears up all the excess stuff you are thinking about having to add it. <G>
Using CSS, the power of custom templates, and such, you can turn a category that is "owned" by a user into a special sort of beast.
You give that user "power" to do things in it, such as set up categories (or pre-set categories with special features) to which they add "links".
When the ImageSQL program in the Models and Photographers Gallery Lite version is released, it will resemble a blog in many ways. It won't *look* like a blog, because it doesn't have all that spammamation stuff like track backs and pings, etc. It does allow a user to create a miniature "community" of their own, posting images (mainly) (but it could be anything -- stories, articles, whatever you configure your link to do), getting comments, reviews, ratings, and all sorts of feed back. In addition, it will allow networking, connections, and users inter-linking their links with others (eg: a photographer who posts a picture can link to the models, stylists, locations, etc in that image).
So far, the only major issue I've run into is the User table has no auto-index field, and the Auth_Community for GLinks would have to be modified as would the Community modules to allow using the similar format for GForum for GLinks. This would allow users the flexibility to change the Username, but not lose any of their links or data.
Since "user" would be an end-node (or leaf) in any tree (no public categories or data areas would hang off a user) using a category to represent a user makes total sense. everything below that "user" belongs to them, and isn't part of the "public" system. (It's public, in the respect it can be viewed, but it's not a "commons" area, or part of the base structure of the site).
I've moved off in a slightly different manner, since I see blogs as nothing but "spam" in their current incarnation. 90% are just out to send out and recirculate bogus trafic. Some are not even circulating actual articles -- just jibberish.
The concept of a wikki, merged with a blog, in the structure of a Links hierarchy (rather than the anarchanistic circular linking of a wikki) seems to be the best format, for what I want to do, for developing new content offerings. You have a commons area, but people can congregate or group themselves along the walls, or perimeter of the various content areas to which they want to belong.
The best reasons to do it this way, are you preserve all the power of what is built into Links, and you are just adding on through the normal system of updates. Each update/upgrade gets applied to all users, but all users still have their own access/control limited by the core security of the system. It will (should) survive upgrades, and still allow you to run a very flexible, varied, and completely customized site.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
