Previous Thread
Next Thread
Print Thread
Rate Thread
Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
Question posed to all UBB code hackers in advance of UBB6 release (this does not apply to any betas):

Many of us plan on using some of the custom fields in the member profile for our hacks. I plan on using the 4th field, to be specific. However, many of us may end up using the same fields. So, I would like to propose, informally and fully subject to debate and/or ridicule, a "standard" we could all follow to store data in that field. An informal "agreement" among UBB code hackers.

Here is my suggestion, and bear in mind I hope you all know I am not trying to run things but merely propose this to get ideas and suggestions and start some of you thinking about it when UBB6 is out of beta.

[field:"data1","data2"...]

Example:

[foobar:"hello"][test:"goodbye","world"]

Here are my thoughts:

1) encase all stored data in [] brackets
2) use comma deliminated "data" for data
3) spaces will be ignored outside of []
4) terminate line with newlines char
5) this standard would apply to all 4
custom profile fields

Additional comments:

Well, if you didn't know, a newlines character is the only character that distinguishes one profile line from another.
If we follow this format, we can create hacks that can store and retrieve data safely, not have to be in any particular order, and also we can share data between hacks if we so desire. Such as a memberlist hack using data from who's online, or vice versa.

This also means we can share the same field without corrupting each other's data, and the only criteria when writing data to the profile line is to follow the standard and ensure a newlines is on the end.

We can even work on a common routine which could be placed in ubb_lib.pl which allows which custom line is to be examined, then parse the data into an array very similar to the way ReadParse() examines the environment or command line. Example: ReadCustomProfile(4) and the info is pushed into an array. And of course we could make another routine to write data.

Standardization is scary, but if done properly, means we can all hack freely and really make UBB6 even more special than it really is with our hacks. But hacks that WORK TOGETHER. Or, at least, work with each other.

All thoughts, ideas, opinions, good/bad/otherwise welcomed. This is only for UBB6 final release so I'm merely starting conversation now, informally.

-jim

Sponsored Links
Joined: Mar 2000
Posts: 21,079
Likes: 3
I type Like navaho
I type Like navaho
Joined: Mar 2000
Posts: 21,079
Likes: 3
Hey Jim, very good points, much the same as in my thread in the beta forums concerning profile field mapping... check there. Leshrac has some scripts to move profile fields around, and while they look good, standardization is still something we should look at. An "auto-install/ update" mechanism is being developed by borg that all major modifications will be adapted to and standardization can only help here...

There is a thread in chit chat from a while back where Navaho discusses developers "signing up" for profile fields, then everyone knowing that those fields are reserved for use by that particular modification. Some might argue that it'll leave some users with 50 fields in their profile when they only wanted to install one modification, but it so happens to use field # 50. I really don't think this will present a problem, or cause any additional overhead.

Having said that, you might consider using a higher # for your profile field, to prevent any conflicts, but it's up to you. You might wanna present your POV in the thread in the beta forum.


- Allen wavey
- What Drives You?
Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
Thank you very much for the input.

To me, it's clear we need two methods:

1) how to add/delete/update NEW profile fields
2) how to update EXISTING profile custom field

With each method there should be a standard library available to hackers which works with UBB6 libraries.

The first method is the best, so UBB6 end users can use all 4 custom fields. The second method is easier to implement and requires no hacking of member files. My suggestions were for the second method, and the UBB6 end user simply needs to keep it free and it minimizes impact on UBB6.

I'll look around for the other thread.

-Jim

Joined: Jan 2000
Posts: 5,073
Admin Emeritus
Admin Emeritus
Joined: Jan 2000
Posts: 5,073
Leshrac has already constructed that library you mentioned... IIRC, he's passing out beta copies.

Personally, I would advise against storing data in the user profile - I'd store it in external files, pulled in as required. The data is stored in a key/value format and is split into a hash when read. A reference to the hash is added as the last element of the user profile array when read. Thus, $userprofile[-1]->{'fieldname'} would always be valid. You'd never have to worry about array positions or any other such crap.


UBB.classic: Love it or hate it, it was mine.
Joined: Jan 2000
Posts: 114
Member
Member
Offline
Joined: Jan 2000
Posts: 114
Please read my comments and posts in this thread . I would strongly advise that we do not use any of the custom fields. These should be treated as standard fields that should only be touched by the end user, not by any public hacks. I believe I've already sent you a copy of my member interface libraries, if not, please e-mail me. I would also strongly advise that these become the standard for dealing with extra profile fields. They make it very easy to add and remove new fields and interface with existing ones. Everything is done via hash references (as it should have been in the first place), so you don't have to worry about conflicting profile field numbers, or profiles that are 50 fields long with half of them unused. It also makes it extremely easy to upgrade the profiles, should Infopop include any new fields in a future version. I've put a lot of time into writing these libraries cleanly and efficiently, and documenting them heavily, and thus I strongly believe that this is the right way to approach the extra fields dilemma. Please contact me if you have any questions/suggestions/etc.

Sponsored Links
Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
Sounds good, leshrac. smile

I will contact you after UBB6 is out of beta and you've worked out any bugs that may arise between now and then. I'm in no rush.

Compliments to you on a quick response, a fine effort based on comments of others in the other thread, and for making our lives much easier! Bravo.

-Jim


Link Copied to Clipboard
Donate Today!
Donate via PayPal

Donate to UBBDev today to help aid in Operational, Server and Script Maintenance, and Development costs.

Please also see our parent organization VNC Web Services if you're in the need of a new UBB.threads Install or Upgrade, Site/Server Migrations, or Security and Coding Services.
Recommended Hosts
We have personally worked with and recommend the following Web Hosts:
Stable Host
bluehost
InterServer
Visit us on Facebook
Member Spotlight
isaac
isaac
California
Posts: 1,157
Joined: July 2001
Forum Statistics
Forums63
Topics37,573
Posts293,925
Members13,849
Most Online5,166
Sep 15th, 2019
Today's Statistics
Currently Online
Topics Created
Posts Made
Users Online
Birthdays
Top Posters
AllenAyres 21,079
JoshPet 10,369
LK 7,394
Lord Dexter 6,708
Gizmo 5,833
Greg Hard 4,625
Top Posters(30 Days)
Top Likes Received
isaac 82
Gizmo 20
Brett 7
WebGuy 2
Top Likes Received (30 Days)
None yet
The UBB.Developers Network (UBB.Dev/Threads.Dev) is ©2000-2024 VNC Web Services

 
Powered by UBB.threads™ PHP Forum Software 8.0.0
(Preview build 20221218)