We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.

Bug 5553 - centralize name storage/creation
centralize name storage/creation
Product: OJS
Classification: Unclassified
Component: Framework
PC Mac OS X 10.4
: P5 enhancement
Assigned To: PKP Support
Depends on:
  Show dependency treegraph
Reported: 2010-07-07 09:39 PDT by James MacGregor
Modified: 2013-05-29 16:21 PDT (History)
1 user (show)

See Also:
Version Reported In:
Also Affects: OCS 2.3.2, OHS 2.3.1, OMP 1.0


Note You need to log in before you can comment on or make changes to this bug.
Description James MacGregor 2010-07-07 09:39:33 PDT
As per http://pkp.sfu.ca/support/forum/viewtopic.php?f=9&t=6309&p=24234#p24234: centralize how names are stored and generated within the codebase to make it easier for others to control how they are displayed via eg. plugins.
Comment 1 Alec Smecher 2010-07-07 09:52:22 PDT
This has mostly been done already, e.g. with the PKPUser::getFullName function; if areas in the code are identified that don't use this, please note them here and we'll correct them.
Comment 2 jerico 2010-07-07 10:27:53 PDT
I also considered using PKPUser::getFullName() for name formatting when I implemented the citation editor.

The problems I had with that approach is:
- not all names can be dealt with in User objects especially when it comes to citation formatting or import/export
- the approach is not easily pluggable/extendable (unless we let getFullName() delegate to a filter, which makes a lot of sense to me)
- the approach is not easy to configure for different output
- this is not a solution for interoperability with external apps
- it's not easy to maintain standards-compatibility like NLM or the like

The user object is quite specific and too heavy for generic name representation. NLMNameSchema or some similar standards-based approach is more appropriate IMO.

We could delegate name output to filters and use FilterDAO::getCompatibleOjects() in places where we need name display. Of course the filter can be kept in cache so that we don't have to retrieve it from the DB more than once per request. It can be used in the PKPUser object but also in places where a PKPUser object is not available.

Name display can then be configured in the set-up in a community-extensible and standards conforming way.
Comment 3 James MacGregor 2013-05-29 16:21:41 PDT
Already completed by Jason -- see the PKPIdentity class.