Party Information Framework
- 1 News
- 2 Basics
- 3 Components
- 4 Wishlist
- 5 Roadmap
- 6 Related extensions / projects
- 7 Current Project Members
notice - Open Content License
18.06.2011: move the tests into the new extension party_tests.
10.02.2011: experimental version 0.1.0 published on TYPO3 TER.
30.09.2010: experimental version 0.0.1 published on TYPO3 TER.
30.09.2010: The project was taken over by Franz Holzinger. Subversion is at https://forge.typo3.org/projects/extension-party/repository
10.03.2008: The project was taken over by the Web Empowered Church (WEC) and is now called wec_people. Christoph Koehler (christoph(at)webempoweredchurch(dot)com) is the lead developer. Please refer to the WEC Trac Site for more information.
05.04.2007: Added the new logo of the project.
26.02.2007: Added work packages to all components. If you are interested, please join us in the development!
18.01.2007: Update of class-model to 0.20
15.01.2007: See proposal for the class model It is based on the current version 3.0 of xPIL/xNAL, which is still in draft state. It is expected to be published as final in Q1/2007, so I will update the model later with any changes that might still occur.
For the core extension tx_party, I would like to stay as close to the standard as possible. If the need arises for further classes and/or attributes, I would like to encapsulate those in extra extensions.
I would like to invite you to give feedback on the class model. Please pay special attention to the cardinalities and the completeness of all classes/attributes. What did I miss or misinterpret from the standard? Please note that all the classes are linked to the according xPIL/xNAL elements (click on the class and choose 'file').
The next step will be to build a first version of the data model based on TYPO3 4.1, according to the class model.
Development will be public, I have created a new folder on typo3xdev:
Greetings, Dave (newsgroup)
08.01.2007: You are invited to cast your vote about the future development of the Party Information Framework on the ECT Mailing List.
Definition of a Party
Party is the umbrella term for persons and organizations (e.g. companies, associations, teams, etc.). It has nothing to do with some sort of a celebration... :-)
The Party Information Framework is the central extension in TYPO3 to manage all party-related data (such as names, addresses, e-mail addresses, phone numbers, relationships between parties, etc.).
How can this be useful to me?
Check out this scenario which explains how the Party Information Framework can help you.
We want to use unit-testing, publish early and often and strictly adhere to CGL
The framework must be flexible enough to suit the needs of all extensions using party-data
The framework must be written an maintained by a team, not a one-man show
Issues with the current situation
One problem is that there is no central place in TYPO3 which holds party data. Frontend-users are persons and thus parties, they are saved in fe_users. Backend-users are persons as well, they are saved in be_users. Both tables hold an e-mail address, for instance. If a person is both, a frontend- and a backend-user, his e-mail address is saved twice. If the same person has also subscribed to a newsletter, chances are that his e-mail address is saved for the third time, this time in tt_address.
- Data model
The data model of tt_address does not comply with common standards for names and addresses. For instance, there is just one 'name' field, which holds the first, the middle and the last name. This makes it impossible to build a proper address handling, where for instance an application would like to address its customers by their last name only. On top of that, many importants fields of a party - such as the birthday of a person, for instance - are missing.
- Wide range of extensions
Due to these facts, there are many extensions trying to improve the situation. Many of them are really good, but the problem is that most of them cover just one aspect and none of them solves to problem as a whole. This makes it impossible for instance to build a solid frontend extension for party-data. For new extensions needing party-data, it is very difficult to decide which solution to build on.
- In scope of the Party Information Framework is the management of all party-related data.
- Out of scope are, in particular
- User Management (e.g. the project is not about combining backend- with frontend users. It will, however, provide solutions to remove redundant party-related data from the users tables, such as the e-mail address)
- Personalized content (This might be a possible use of the framework, but it is not part of the framework itself)
- TYPO3 5.0
The framework is built with the goal of becoming a package of TYPO3 5.0. We surely will support the 4.0 string, especially while 5.0 has not yet been released, but the development focuses on the support of 5.0.
- OASIS xPIL 3.0 and xNAL 3.0
We are building on the OASIS standards wherever possible, e.g. the data and the object model follow the standard. The OASIS CIQ V3.0 Committee Specification has been released in November 2007. OASIS CIQ TC FAQ
Core - party
The core is the base for all other party extensions. It contains only the model (with the exception of the basic backend-module). The model is basically an object-oriented API (based on lib/div) to access all data and methods of the framework.
Tests - party
View - party_view
This extension is the 'View' layer of the framework. It contains the view- and controller functions. It can be used to display party-data in the Frontend, but it also contains all the rendering methods e.g. to render an address in a country-specific way.
Syncronizing - party_sync
The syncronization module is in charge of exchanging party-data with other clients, such as another TYPO3 table (e.g. tt_address), other extensions or other systems outside TYPO3.
Reporting - party_reporting
The reporting extension provides all functionality to create reports for party-data or to prepare statistical data.
Migration - party_migration
This extension holds all tools necessary to migrate data to the party information framework.
Please feel free to add feature requests to this wishlist and write an email. We can then decide into which module the feature belongs and how it can be included into the roadmap.
- for phase 3: Is PEAR::LiveUser good for Rights Management? (See Enhanced Rights Management) --Daniel Brüßler 13:06, 28 February 2007 (CET)
The Roadmap is split to the different components of the Framework. We are currently working on Phase 1.
We have deliberately decided not to commit on any specific dates yet. We will do that as a community effort as soon as the development of the core component has actually started.
Related extensions / projects
Extension to potentially integrate
These extensions are candidates to be integrated into the new party information framework. The goal is to get as many extension developers together to work on the same framework with the long-term vision to drastically reduce the number of extension.
The most obvious candidate. The full functionality should be moved to the new party information framework
Currently, the direct mail subscriptions are saved in extension fields of tt_address. There are two solutions: (1) Integrate it into the party information framework (possibly still as an extension) or (2) move it to the fe_users table (quite certainly as an extension). What should definitely be changed is the way the categories are saved on the database (currently a binary value).
Could probably be completely integrated into party_view.
Many concepts can be used as a basis for the new party information framework and the complete functionality could be integrated, so the extension could become obsolete.
Could be part of party_view and then become obsolete.
Could probably be completely integrated into the framework.
Could be adapted to use the party information framework in the long run, in the meantime it could still use tt_address which can be syncronized using party_sync.
Details need to be checked, but it seems like a perfect fit for the party information framework.
Could probably be completely integrated in partner_view.
Could be completely integrated in the core (the state-field is part of the core data model)
Could probably be completely integrated into the Framework.
Could be completely integrated in the core (the additional fields are part of the party data model and the field visibilty concept for the frontend should also be part of the core).
Could become part of the core API or partner_sync (maps to CSV format)
Could serve as the basis for all import/migration functionality
Could probably be integrated in the party information framework.
Could probably be integrated in the import/migration functionality
Could be the basis for an integrated tool for finding and managing duplicate party records.
See comment of Direct Mail Subscription
Might be worth to integrate in the core party data-model, especially since the format in which the party wants to receive his mails might also need to be available for other clients than direct_mail.
Could probably be completely integrated into the party information framework.
Adds a birthday-field for a Frontend-User and lists the birthdays on the Frontend. The birthdate is an attribute of the person, the list could be part of party_view.
Listing of staff members
- Commerce Shop Extension This extension use an 1:N relation for addresses and included an own addressmanagement, which should be part of the Party Information Framework.
- Enhanced Rights Management - a pear class for a RBAC / Role Based Access Control.
- Inline Relational Record Editing - 1:n relations for BackEnd-Forms -- Oliver Hader
- Newloginbox development coordination - Ingmar Schlecht and Stefan Strasser
The User list plugin (pi3) of Newloginbox is related to the Party Framework. If the Party Framework will ship with a user listing plugin, the pi3 of Newloginbox wouldn't be needed any more.
- Users Addresses - relations between fe_user and tt_address, best practice discussion - Elmar Hinz
- dkd_feuser_belogin - relation between fe_user and be_user
Current Project Members
Are you an extension developer using party-functionality or are you interested in this project in any other way? Please contact Dave or any other member of the project team and join in!
-- Franz Holzinger 11:25, 3 April 2011 (CEST)