Call for co-maintainer

Are you planning to move this module forward?

With Fields in core and a strong push for Profiles using fields, New Profile module leveraging fields API!, a name field is really going to be in demand.

I've created a demo project under name, based on the core text fields. There are 4 or 5 core fields as there is no support yet for db modifications (or I'm missing a function call somewhere).

It only covers a single name set, having two sets, legal & preferred, seemed redundant and overly complicated. This would be easily covered by two fields anyway.

If your interested, I can transfer the project to you and help maintain.

I have just had a look at the ported version, after spending the last 5 days refactoring the Name module....

"You'll notice that there is now just one set of subfields whereas before there was a set for a LEGAL NAME and a set for PREFERRED NAME."

There is now a near 100% overlap between the modules CCK Fullname and Name. Your initial reluctance for dropping the legal / preferred combination was one of the motivating factors for going ahead with the Name project.

The base functionality is now very similar.

Some differences:

1. CCK Fullname allow TEXT columns, while Name is limited to 1-255 VARCHAR
   
   With Drupal 7, you can not dynamically change the columns, and I'm thinking about creating just 6 VARCHAR(255) to handle the data. If someone needs text, they can simply add a textarea and group it.
2. CCK Fullname supports free text for prefix, Name supports a select field for title.
3. Different naming conventions. Family and Given names in Name are language neutral, while first and last in CCK Fullname are language specific.

Additional Name features:

1. A parsing system for handling and using format strings, similar to the PHP date() function.
2. An admin feature for defining and managing custom name formats
3. Unlimited custom formatters by hooking into these custom formats.
4. Name has an additional generational suffix option.
5. Taxonomy hook in for the selects

I suggest that we merge these projects very soon.

I would suggest the Name project as the base, for the two reasons:

1. Name has a small count of Drupal 6 users, approx. 200, while CCK FullName is still mainly Drupal 5 with only 8 users so far in the newly ported version.
2. The namespace has more meaning as we get very close to the release of Drupal 7. CCK is not dead, but it is moving into the background...

Anyway, I'd love to hear your options. I have only just committed the refactored code, so it will take a few hours to be bundled together as a dev release.

Cheers

Alan

PS: If you continue with this project, I'm getting a flood of errors. Most are related to the default value in the MySQL TEXT column running on strict mode. (A default value is invalid SQL) This resulted in no field columns, and things fall over from there.

If you prefer to discuss this off-line use my contact form to give me an email.

Cheers

Alan

Don't forget the upgrade path for D5 if it gets another name...

& have slight problems with the name "Name"; its very different from the human name "Name Field, CCK", or CCK Name Field. Actually, I can find it easier back in between my many modules if it just starts with CCK. Like cck_name or cck_name_field.

After a night sleep I have second thoughts; maybe it should be name ("Name" here) and then second 'name' towards function in a second column; in this case "CCK field". I'm working on easier sortable modules and its just a mess how this is (NOT) arranged on Drupal. If one follows this structure, then Apache directory search can sort on the real module dir name AND on the description name ("CCK field" in this case); see example: http://All.DruMI.org

Anyway, maybe it has no use to think about this for the new module name here, as it probably would be unworkable to change many module names on Drupal to fit these benefits? Or could that be done?

@ClearXS I am not following the name request.The other projects title (Folder & CVS) is "name", but I have renamed the project title to "Name Field" - I have both a CCK and Field version, so Field seemed better than CCK Field. The Drupal 7 version will be released soon, but I'm writing complete SimpleTest tests before releasing that version.

@rconstantine Happy to help out by submitting patches when possible

Cheers
Alan

Seems the queue is getting a bit stale, you guys still need help on this, then please let me know.

I have a patch in queue for you guys and willing to help in getting some of the existing issues resolved.

Edit: queue looks fine, I accidentally wasn't filtering out fixed issues when looking originally. Offer still stands if you need the help.

Hi all,

If you folks would still like a co-maintainer, i'm willing and able.

Some thing that I would like to do:
1. Port to Drupal 7
2. Add a column for name ordering so we can support natural display of both western names and eastern names in the same field.

Just a follow-up:

In the long term (version 2?) I'd like to implement the full NLM dtd 3.0 standard for name storage and display.

For more info on this standard see:

http://dtd.nlm.nih.gov/articleauthoring/tag-library/3.0/index.html

http://dtd.nlm.nih.gov/articleauthoring/tag-library/3.0/n-6ub0.html

@phayes

Have you thought about providing patches for the Name Field module? I considering more i18n support, but as well as the order, there would also be a need for the "phonetics" spelling of the name to for sorting, etc.

I think that it is best to stick to standard database storage of the fields, as this provides the easiest method of searching, etc. It would be trivial to provide a formatter to provide the XML for the NLM DTD.

Cheers
Alan

Thanks for the link to the name field module.. It looks to be more fully developed and more powerful.

For the NLM DTD stuff, I was thinking it might make sense to model if after the geofield module (http://drupal.org/project/geofield). Basically the idea is that you have one "master column" in a standard rich format that contains all the information, and then you have a bunch of metadata columns that are dependent on the master-column. For example:

<string-name name-style='western'><prefix>His Royal Highness</prefix> The Prince <given-names>Charles</given-names>, <suffix>Prince of Wales and Earl of Chester</suffix></string-name>

We store this string as the "master" NLM column, then compute out the name-style, prefix, given-names, surname, suffix etc. etc. and put those in separate columns so that they can searched, sorted, filtered etc.

That's my idea - and I think it's a powerful approach, since you can deal with really odd names (as above) and still get all the relevant metadata. We should likely standardize around *some* format for the "master" column, NLM DTD is one option, but there might be others that make more sense.

Shall I go ahead and post this idea over on the name-field module issue cue?

Being maintainer of the imagefield extended module, there is a lot of pain when you start saving data in a non-standard db format. And performance takes a huge hit, when there are heaps of records - the entire record is loaded and parsed just to see what is there... but it can be useful to store data that is not used in searches or filters. I would move ahead very carefully before doing this

Yes, I agree with your concerns. Using it for searches and filters would be painful - hence the need for extensive metadata.

I'll make a prototype on github so you can see what i'm talking about more concretely.

Closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.