rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlucci, Tony" <acarlu...@mitre.org>
Subject RE: [DISCUSS] Proposal for Person Profile Direction in Rave
Date Thu, 09 Feb 2012 14:26:27 GMT
Assuming lazy consensus without any further feedback, I'll start creating Jira tickets either
tonight or tomorrow.

Thanks, Tony



>-----Original Message-----
>From: Marlon Pierce [mailto:marpierc@iu.edu]
>Sent: Tuesday, February 07, 2012 2:06 PM
>To: rave-dev@incubator.apache.org
>Subject: Re: [DISCUSS] Proposal for Person Profile Direction in Rave
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Sounds great to me since it will make Rave more social. The last item (#6)
>introduces some broader issues:
>
>* Internal notification/messaging requirements ("Person X wants to be
>connected to you"), so we may want to expand this to think of general
>messaging requirements.
>
>
>* Symmetric connections (friendships, family connections, business
>connections) vs. asymmetric connections (following public figures and
>institutions that don't follow you back): what will we support? Can we support
>multiple models?
>
>
>* We'll also want to address scaling at some point.
>
>
>
>Marlon
>
>
>On 2/7/12 10:07 AM, Carlucci, Tony wrote:
>> Hello Rave Community,
>>
>> We have internal requirements at MITRE to build out some extensive
>Person Profile functionality in Rave.   We've developed a proposal of the
>direction we'd like to take the Person Profile in Rave, since we think a lot of
>the features would be appropriate to put into the core Rave code as opposed
>to our custom extension.    Before we started creating Jira tickets, we'd like
>the community to comment on it to make sure it fits into the community's
>vision of Person Profiles.  The features below represent what MITRE needs,
>and would definitely not represent the whole feature set of Person Profiles in
>Rave.  The first 3 items are the requirements for our initial version of the
>Person Profile and what we would focus on first (essentially the "view" work).
>The last three would be future enhancements.
>>
>> Thanks in advance for your time...
>>
>> Tony
>>
>>
>> (1)    A Person Profile page can be viewable by any user, not just the owner
>>
>> a.       proposed URI mappings: /portal/app/profile/{username or entityId}
>>
>> b.      We would add a new field to the Page model object: boolean
>isProfilePage
>>
>>                                                                i.      This will
be an indicator to the rest of the
>application that it is not a "Traditional" page object, but a "Profile" page
>>
>>                                                              ii.      This will also
allow the security layer on
>the services  to use this field to allow Profile Page objects to be viewed by
>people other than the owner
>>
>>                                                             iii.      Perhaps a more
sustainable long-term
>solution would be to create a pageClass column instead of the specific
>Boolean, that could be "regular, personProfile, future-alternate-page-class",
>etc?
>>
>>
>>
>> (2)    The Person Profile page can contain multiple sub-pages (tabs from a UI
>perspective), each containing multiple regions and widgets
>>
>> a.       Create a new ProfilePage model object
>>
>>                                                                i.      There will
be a one-to-many relationship
>between Page<->ProfilePage (one Page has many ProfilePages)
>>
>>                                                              ii.      Fields in ProfilePage
>>
>> 1.       Long entityId
>>
>> 2.       Page page
>>
>> 3.       String title
>>
>> 4.       PageLayout pageLayout
>>
>> 5.       List<Region> regions   ***this may need to be thought out more since
>a Region object currently has a Page object attribute ***
>>
>> (3)    Some widgets are fixed and some have no "chrome" (border, menus,
>etc)
>>
>> a.       Ability to render "fixed" widgets and widgets that don't have "chrome"
>on the Person Profile page
>>
>> b.      The solution should be generic enough so that this also available for
>traditional pages as well
>>
>>
>>
>> (4)    The owner of the profile can edit information about themselves that
>the Rave Administrator deems editable
>>
>> a.       We can build on the existing edit person profile context code in Rave
>>
>> b.      Develop a mechanism that controls what person profile fields can be
>editable by a user
>>
>>                                                                i.      For example:
out-of-the box we might
>let users update their email address, but for an internal corporate
>implementation of Rave we wouldn't want employees to be able to change
>that particular field
>>
>>                                                              ii.      Perhaps an
Admin screen that displays all
>person profile attributes and allows the admin to turn them on/off for
>editing?
>>
>>
>> (5)    The composition and layout of the Profile Page can be easily editable
>>
>> a.       Ability to follow a similar model of customization (Drag and Drop,
>add/remove widget, etc) of a traditional Page
>>
>> b.      Ability to create two types of Profile Page customizations
>>
>>                                                                i.      Owner Defined
Customization: I want
>EVERYBODY to see these customizations to MY profile page
>>
>>                                                              ii.      Viewer Defined
Customization: I want to
>see this common set of customizations when viewing ANYONE's Profile Page
>>
>>
>>
>> (6)    A user can create a connection between the individual they are looking
>at and themselves from the Profile Page
>>
>> a.       Create a UserConnection model that connects one Rave User with
>another
>>
>> b.      Full API stack for managing user connections (add, remove, view, etc)
>>
>>
>>
>> ---
>> Anthony Carlucci | SW App Dev Eng, Sr. | R501 / KW App Development &
>Maint
>> e: acarlucci@mitre.org<mailto:acarlucci@mitre.org> | v: 781.271.2432 | f:
>781.271.3299
>> The MITRE Corporation | 202 Burlington Rd | Bedford, MA 01730-1420
>>
>>
>>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
>iQEcBAEBAgAGBQJPMXYIAAoJEEfVXEODPFIDZ2UIAJMCpA3OdutpCld/pMe5t
>H+i
>bvfJdrMb5ELmweSQEORq35YFaV1/EkgDFbLBxMC7P4+wSr9jh2sNPyK5v5vXTai
>I
>/PoR4/uBJz+DG7Wn41cRMIoWeyy81SnpF28BQsafJSJXfc+eg8IGU5C8ap+ygfcg
>vbawSepW736j3IaoJNaCXKF1jWQbxBrCaBV2g3o3Xg0qZLggcsQaGPkGYdBDDy
>PW
>yGZZrfYnZOnTgiDEEateemiCCElZyzr/YgNRMhqAaSgTuVcgRPCS9KdnKXg0DycO
>AQxBD7nrAwhHHa+MrWhE1txMij340BEnUISQVj+Jxl/gc36ConJs5wqSv/In8Iw=
>=98f+
>-----END PGP SIGNATURE-----

Mime
View raw message