[development] Fieldsets for profile variables

[Mark Leicester]

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 at 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