rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marlon Pierce <marpi...@iu.edu>
Subject Re: [DISCUSS] Proposal for Person Profile Direction in Rave
Date Tue, 07 Feb 2012 19:05:44 GMT
-----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/pMe5tH+i
bvfJdrMb5ELmweSQEORq35YFaV1/EkgDFbLBxMC7P4+wSr9jh2sNPyK5v5vXTaiI
/PoR4/uBJz+DG7Wn41cRMIoWeyy81SnpF28BQsafJSJXfc+eg8IGU5C8ap+ygfcg
vbawSepW736j3IaoJNaCXKF1jWQbxBrCaBV2g3o3Xg0qZLggcsQaGPkGYdBDDyPW
yGZZrfYnZOnTgiDEEateemiCCElZyzr/YgNRMhqAaSgTuVcgRPCS9KdnKXg0DycO
AQxBD7nrAwhHHa+MrWhE1txMij340BEnUISQVj+Jxl/gc36ConJs5wqSv/In8Iw=
=98f+
-----END PGP SIGNATURE-----

Mime
View raw message