Party Information Framework
From TYPO3Wiki
| Teams Committees | This project/information is related to the Extension coordination team |
| List Projects | The Framework for all partner-related issues-project list pages | See Current Project Members, Wishlist |
| you can help if you like! |
Contents |
|
Title: |
Party Information Framework |
|
This document is published under the Open Content License The content is related to TYPO3 - a GNU/GPL CMS/Framework available from www.typo3.com |
The Party Information Framework is an ECT (Extension Coordination Team) project for the management of party-related data. This project was formerly called Partner Framework. Why the name changed
News
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.
27.04.2007: Presentation of the current status and discussion at the TYPO3 Developer Days
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!
25.02.2007: Update of class model to 0.30 (PNG)
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:
http://typo3xdev.svn.sourceforge.net/viewvc/typo3xdev/tx_party/
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.
Basics
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... :-)
Vision
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.
Values
- Quality
We want to use unit-testing, publish early and often and strictly adhere to CGL - Versatility
The framework must be flexible enough to suit the needs of all extensions using party-data - Sustainability
The framework must be written an maintained by a team, not a one-man show
Issues with the current situation
- Redundancy
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.
Scope
- 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)
Standards
- 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. - PHP5
The framework will be built using PHP5. So even if you run it on TYPO3 4.0, you will be required to use PHP5. - 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. Currently, the version 3.0 is not yet finalized, so minor changes are still possible and will be included in the framework.
Components
Core - party
tx_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.
View - party_view
tx_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
tx_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
tx_party_reporting
The reporting extension provides all functionality to create reports for party-data or to prepare statistical data.
Migration - party_migration
tx_party_migration
This extension holds all tools necessary to migrate data to the party information framework.
Wishlist
Please feel free to add feature requests to this wishlist and discuss it on the ECT mailing list. 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)
Roadmap
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.
Project Team Meetings
We should plan some regular project meetings (will be discussed on the mailing list).
Here's a map of germany, another idea is to use quikmaps to find a good meeting-point.
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.
- Address list (tt_address) (contact: flyguide)
The most obvious candidate. The full functionality should be moved to the new party information framework - Direct Mail Subscription (direct_mail_subscription) (contact: revsbech)
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). - Address Directory (sp_directory) (contact: chorst)
Could probably be completely integrated into party_view. - Partner Management (partner) (contact: dbruehlmeier)
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. - Partner Frontend Plugin (partner_fe) (contact: dbruehlmeier)
Could be part of party_view and then become obsolete. - Address Exporter (sa_addressexport) (contact: salpers)
Could probably be completely integrated into the framework. - [Gobernalia] Newsletter (gb_newsletter) (contact: maximo)
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. - Extended Address Database (sg_address) (contact: geithman)
Details need to be checked, but it seems like a perfect fit for the party information framework. - Zip Code Search Tool (ast_addresszipsearch) (contact: commodore)
Could probably be completely integrated in partner_view. - Address list - North America (m1address_us) (contact: m1tk4)
Could be completely integrated in the core (the state-field is part of the core data model) - Company Database (cl_company_database) (contact: necro2k)
Could probably be completely integrated into the Framework. - Extend FE address fields (csextfeadr) (contact: stuedemann)
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). - Address list (address) (contact: robert)
Could become part of the core API or partner_sync (maps to CSV format) - User Import Tool (rs_userimp) (contact: clonedyke)
Could serve as the basis for all import/migration functionality - FE address edit for tt_address & direct mail (dmaddredit) (contact: foxpower)
Could probably be integrated in the party information framework. - Email address import and cleanup (emailimport) (contact: daniel_schledermann)
Could probably be integrated in the import/migration functionality - Direct Mail Companion (dubletfinder) (contact: oliklee)
Could be the basis for an integrated tool for finding and managing duplicate party records. - Backend tt_address dmail categories (icr_be_addr_dmail_cat) (contact: whity)
See comment of Direct Mail Subscription - KJ: tt_address Mailflag (kj_tt_address_mailflag) (contact: kj187)
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. - Contacts List (contactslist) (contact: oliklee)
Could probably be completely integrated into the party information framework. - Create/Edit Userdata (sg_userdata) (contact: geithman)
? - Birthday List (eu_birthdays) (contact: feynman)
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. - BZD Staff Directory (bzd_staff_directory) (contact: mrimann)
Listing of staff members
Extensions for Cooperation
- Calendar Base - cal
Currently using tt_address for organizer. - Commerce - commerce
Currently using tt_address. - University Manager - jsh_university
Also has a party-entity, so it might be interesting to coordinate the efforts.
Relations
Other relating projects to Party Information Framework (edit this, in alphabetical order)
- 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!
- David Brühlmeier, typo3(at)bruehlmeier(dot)com
- Elmar Hinz, elmar.hinz(at)team-red(dot)net
- Peter Kindström
- Norman Seibert, seibert(at)entios(dot)de
- David Slayback, dave(at)webempoweredchurch(dot)org
- Oliver Klee, typo3-coding(at)oliverklee(dot)de
- Oliver Hader, oh(at)inpublica(dot)de
- Robert Lemke, robert(at)typo3(dot)org
- Olivier Dobberkau olivier.dobberkau(at)dkd(dot)de
- Peter Kühn
- Sven Kalbhenn, sven(at)skom.de
- Andreas Wolf, typo3(at)andreaswolf.info
