Re: [development] Fieldsets for profile variables
Mark Leicester <mark.leicester@efurbishment.com> wrote:
Yes, I've also found the need for the sort of thing you describe. I have a working implementation that allows the arbitrary grouping of fields into fieldsets, where those fieldsets may be assigned and weighted within any category including the account page itself.
I left the account validation in. (Actually it is the account restriction.) So adding to the account page isn't something I had contemplated.
Like you I only allow a single level of fieldset. I use an extra table to group fields by a fieldset name in the same way that the current implementation groups by category names.
Well, the current implementation of category names is a bit less than what you describe you have implemented for fieldsets. At least in 4.7. It is merely an additional field within the profile fields table and there is no weighting allowed. Hence, the categories are displayed in alphabetical order. In addition to setting up a separate table, which I called profile_fieldsets, I just included a parent field in the table so the code can be expanded at some point.
My admin interface is incomplete as yet (clients were happy to have it configured manually and then left alone).
My UI is a clone of the way that the profile fields themselves are input. In essence, I just copied the profile module, renamed it profilefieldsets, stripped out everything from the resulting module that dealt with the user level and kept things that dealt with the profile fields, modifying it to deal with profile fieldsets.
I've also added radio buttons to the available profile field types.
In what context?
It sounds like we're more or less at the same place. Shall we compare notes?
Absolutely. I'll send you what I have off list, unless you think it should be shared here for others to comment upon. Thanks for the response, Mark. mike
Hi Mike, I've extended the existing profile module. I'm working with 5.x, so I can override core modules for a specific site by placing the module with the same name in the sites/[my_site]/modules folder, or override for all sites in a shared hosting environment by placing the module in sites/all/modules. On 28 May 2007, at 16:38, Mike Anon wrote:
Mark Leicester <mark.leicester@efurbishment.com> wrote:
Yes, I've also found the need for the sort of thing you describe. I have a working implementation that allows the arbitrary grouping of fields into fieldsets, where those fieldsets may be assigned and weighted within any category including the account page itself.
I left the account validation in. (Actually it is the account restriction.) So adding to the account page isn't something I had contemplated.
Like you I only allow a single level of fieldset. I use an extra table to group fields by a fieldset name in the same way that the current implementation groups by category names.
Well, the current implementation of category names is a bit less than what you describe you have implemented for fieldsets. At least in 4.7. It is merely an additional field within the profile fields table and there is no weighting allowed. Hence, the categories are displayed in alphabetical order.
In addition to setting up a separate table, which I called profile_fieldsets, I just included a parent field in the table so the code can be expanded at some point.
Yes, I added: a fieldset field to profile_fields; a profile_fieldset table (which has a weighting per fieldset); and a profile_category table (allowing weighting of categories too - i.e. ordering of tabs). The two new tables are updated with DISTINCT category/fieldset combinations from profile_fields whenever a profile field definition is saved, preserving any existing weightings. This approach removes the need for the validation against existing category names (i.e. the check for 'account'). Previously, I think profile module only prevented a duplicate 'account' tab. If you tried to define a any other category already defined by another module you'd get two tabs with the same name. With this approach you can place your fieldsets on new or existing tabs. Even if you enable another module with the same category name, they'll be automatically combined into one tab. The category field is autocompleting, allowing you to choose from a category defined by any module (not just the categories you've defined yourself using the profile module). If there's no javascript, you can just type in a category title to achieve the same effect. A downside is that now you must define both a category and a fieldset for every field. Previously, you entered one value which was re-used for both the category title and fieldset title. Fieldsets remain compulsory for a field. Anyhow, I think all I need to do now is add a form to let an admin edit the weightings for a category or fieldset (and a global rename for both). This is for 5.x so I'm not sure it helps you with 4.7, but I don't think a backport would be too difficult.
My admin interface is incomplete as yet (clients were happy to have it configured manually and then left alone).
My UI is a clone of the way that the profile fields themselves are input. In essence, I just copied the profile module, renamed it profilefieldsets, stripped out everything from the resulting module that dealt with the user level and kept things that dealt with the profile fields, modifying it to deal with profile fieldsets.
I've also added radio buttons to the available profile field types.
In what context?
Previously admins were able to create profile fields from a number of different field types (single checkbox, selection, textarea etc.). I've added: - 'radios' (i.e. a list of radio buttons), and; - 'checkboxes' (i.e. a set of checkboxes, allowing you to select multiple options from many choices).
It sounds like we're more or less at the same place. Shall we compare notes?
Absolutely. I'll send you what I have off list, unless you think it should be shared here for others to comment upon.
Great, yes please, and if you have admin access to a test 5.x installation, we can reciprocate.
Thanks for the response, Mark.
mike
Cheers! Mark
participants (2)
-
Mark Leicester -
Mike Anon