Worked most of the night on this, and made a few little changes (it's amazing how hours of playing can be reduced to a line of code <sigh>) and there are now a series of routines that allow a lot of flexibility, and the calling function is a bit long, but only one function is needed, not several.
<%Plugins::User_Edit_Profile::load_user_profile_table ('table_name')%>
This loads a data record belonging to the logged in user from table_name (eg: another profile page). In this plugin, it defaults to "Users", but if/when I get this into the Widgets, it will be a settable default parameter. The current config allows you to set the key fields in the profile tables, but defaults to Profile_Username (to differentiate from Users::Username/user.Username which is *always* the logged in user).
<%Plugins::User_Edit_Profile::get_fields_like ('fields_like_')%>
<%-- the return is <%found_fields_like%> as an array of hashrefs
Profile_Field_Name => is the column
Profile_Field_Value => is the value of that column (just like the standard tags)
--%>
This returns an array of hashrefs (a loopable variable) of all the fields in the current tags set, that begin with the "fields_like_" field.
If you have a large number of check or select boxes, if you prefix them all with same prefix, you call this function, then you can loop through them, and only them. So if you have a few fields you want to manually format (create a form) you can auto generate the rest of them by using:
<%loop found_fields_like%> ... <%endloop%>
The main function, the one that returns the actual <%pretty_name%> and <%formatted_field%> is this one:
<%Plugins::User_Edit_Profile::FormatField_Select($Profile_Field_Name, $Profile_Field_Value, 'table_name', 'radio', '0')%>
It gets called inside the loop, for each record, or at the position in your template you want to return the auto-generated input box.
The $Profile_Field_Name and $Profile_Field_Value could be your regular 'tag_name' (hard coded) and $tag_name (it's <%tag_name%>) The point of using the loop, though, shows it's full functionality.
table_name is needed to grab an HTML object, this is a requirement of GLinks.
The next two fields are optional. They default to "select" and '0'. If you want a radio/select/checkbox you can pass in that parameter. If you want to have "no/0" fields removed, you can pass in a 1. This really doesn't apply to select boxes, which is why I did it this way, but lets say you have 20 yes/no fields. You can use select boxes, but it's annoying. You can use radio buttons or check boxes with both yes/no boxes, but it's also visually annoying. If you pass in "1" the "no=0" value is removed, and only the "Yes[]" value is shown on the form. If the field is set, the Yes[x] is checked, (or selected, for a radio button). If not, it's not. This probably has some quirks, but it seems to be working.
Oddly, this is a smaller routine than the previous ones. The calling function is a bit ugly though, and only if there is an outcry of horror, will I try to simplify it, by making some wrappers. (perhaps when/if it gets added to the Widgets). But, you really need to have a field name, selected/default value and a table, so to simplify it, some assumptions would have to be made, and that can be problematic.
There's actually a lot more work, mostly in setting up the install and management code, but if anyone needs a more advanced profile editor, and wants to suffer through this beta, I'll offer a big discount. This Profile_Editor_Pro is going to be a big plugin, and has taken up all my time at the moment. The main advantages are it allows using arbitrary tables for storing different profile data, so you don't have one HUGE table, and you can use this as a development platform for customizing advanced profile pages like some of the more advanced community sites. I have to more routines to write, and I'll show off a beta. I have to walk through the process of creating a new profile table, and make sure all the logic/routines work, and then it's ready for pre-release testing.
Once I get that done, the demo site will be posted.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
<%Plugins::User_Edit_Profile::load_user_profile_table ('table_name')%>
This loads a data record belonging to the logged in user from table_name (eg: another profile page). In this plugin, it defaults to "Users", but if/when I get this into the Widgets, it will be a settable default parameter. The current config allows you to set the key fields in the profile tables, but defaults to Profile_Username (to differentiate from Users::Username/user.Username which is *always* the logged in user).
<%Plugins::User_Edit_Profile::get_fields_like ('fields_like_')%>
<%-- the return is <%found_fields_like%> as an array of hashrefs
Profile_Field_Name => is the column
Profile_Field_Value => is the value of that column (just like the standard tags)
--%>
This returns an array of hashrefs (a loopable variable) of all the fields in the current tags set, that begin with the "fields_like_" field.
If you have a large number of check or select boxes, if you prefix them all with same prefix, you call this function, then you can loop through them, and only them. So if you have a few fields you want to manually format (create a form) you can auto generate the rest of them by using:
<%loop found_fields_like%> ... <%endloop%>
The main function, the one that returns the actual <%pretty_name%> and <%formatted_field%> is this one:
<%Plugins::User_Edit_Profile::FormatField_Select($Profile_Field_Name, $Profile_Field_Value, 'table_name', 'radio', '0')%>
It gets called inside the loop, for each record, or at the position in your template you want to return the auto-generated input box.
The $Profile_Field_Name and $Profile_Field_Value could be your regular 'tag_name' (hard coded) and $tag_name (it's <%tag_name%>) The point of using the loop, though, shows it's full functionality.
table_name is needed to grab an HTML object, this is a requirement of GLinks.
The next two fields are optional. They default to "select" and '0'. If you want a radio/select/checkbox you can pass in that parameter. If you want to have "no/0" fields removed, you can pass in a 1. This really doesn't apply to select boxes, which is why I did it this way, but lets say you have 20 yes/no fields. You can use select boxes, but it's annoying. You can use radio buttons or check boxes with both yes/no boxes, but it's also visually annoying. If you pass in "1" the "no=0" value is removed, and only the "Yes[]" value is shown on the form. If the field is set, the Yes[x] is checked, (or selected, for a radio button). If not, it's not. This probably has some quirks, but it seems to be working.
Oddly, this is a smaller routine than the previous ones. The calling function is a bit ugly though, and only if there is an outcry of horror, will I try to simplify it, by making some wrappers. (perhaps when/if it gets added to the Widgets). But, you really need to have a field name, selected/default value and a table, so to simplify it, some assumptions would have to be made, and that can be problematic.
There's actually a lot more work, mostly in setting up the install and management code, but if anyone needs a more advanced profile editor, and wants to suffer through this beta, I'll offer a big discount. This Profile_Editor_Pro is going to be a big plugin, and has taken up all my time at the moment. The main advantages are it allows using arbitrary tables for storing different profile data, so you don't have one HUGE table, and you can use this as a development platform for customizing advanced profile pages like some of the more advanced community sites. I have to more routines to write, and I'll show off a beta. I have to walk through the process of creating a new profile table, and make sure all the logic/routines work, and then it's ready for pre-release testing.
Once I get that done, the demo site will be posted.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
