[development] Fieldsets for profile variables
mark.leicester at efurbishment.com
Wed May 30 00:45:39 UTC 2007
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
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
> > 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
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
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.).
- '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
> > 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.
More information about the development