>-----Original Message----- >From: Carlucci, Tony [mailto:[email protected]] >Sent: Wednesday, May 23, 2012 2:18 PM >To: [email protected] >Subject: RE: Predefined pages > >>-----Original Message----- >>From: Franklin, Matthew B. [mailto:[email protected]] >>Sent: Wednesday, May 23, 2012 1:29 PM >>To: [email protected] >>Subject: RE: Predefined pages >> >>>-----Original Message----- >>>From: Chris Geer [mailto:[email protected]] >>>Sent: Wednesday, May 23, 2012 11:36 AM >>>To: [email protected] >>>Subject: Re: Predefined pages >>> >>>On Wed, May 23, 2012 at 7:34 AM, Jasha Joachimsthal < >>>[email protected]> wrote: >>> >>>> (sorry for the duplicate, but I used the incubator mailing list again) >>>> >>>> I have a use case to implement predefined pages for users. When they >log >>>> in, they should see a page with a fixed set of gadgets. The users should >>>> not be able to modify the gadgets on the page. >>>> >>> >>>We need to do this as well. >> >>Us too >> >>> >>>> >>>> >>>> When we started with the portal we only had 1 type of page that could >>>> contain gadgets: >>>> Page contained one or many Regions. A Region contained zero+ >>>RegionWidgets >>>> which mapped to a specific Widget instance. >>>> >>>> Since then 2 new concepts have been introduced: the profile page and >>>shared >>>> pages. I'm trying to understand how a Page is defined. >> >>Good to bring this up Jasha. It has been something that everyone has been >>struggling with for a while and is a key architectural component that >deserves >>its own spot in the wiki for proposals. >> >>Taking a step back, I have seen the desire for the following "types" of pages >>expressed: >> >>1) A dashboard or portal page. Currently called a user page, it is created >>and >>managed by a single user. People have expressed interest, or added >>functionality to: (a) SHARE: allow others to view, but not modify, the page as >it >>exists (b) COPY: use this page as a starting point for new pages that are >>created by users >> >>2) A group, space or team page. A page where a group of users is >responsible >>for managing the layouts data, and widgets on the page, but no single >>individual "owns" it. This page would have visibility permissions for other >>people not in the "group" >> >>3) A profile page. A page that contains gadgets and information about the >>current user and is intended to be viewed by anyone in the system. The >page >>should be modifiable by the subject of the profile but this ability should be >>controlled administratively. >> >>4) An application page. A page with a set of widgets that are somehow >>statically defined and configured only for public access. >> >>5) An embedded page. A set of widgets rendered in a form suitable for >>embedding in external sites. >> >>As discussed previously, these conceptual models could be grouped into one >>or more workspaces or contexts. Within these workspaces pages are >grouped >>into a tree like model with subpages etc. >> >>IMO, what we really need is to re-evaluate the current model and architect >>something that can be applied to all of these use cases. >> >> >>>> >>>> Page has a pagetype. If the type is "User" then it appears as a tab in the >>>> main area. There seems to be an optional "ProfilePage" which has >multiple >>>> "SubPage" pages that have the ProfilePage as its parent. >>>> >>>> Then there's a PageTemplate type which seems to be mapped to the >>>> "ProfilePage" and its "SubPage"'s. >>>> The PageType is an enum in the code base. Initially it was a table in the >>>> database, but that caused a catch-22 when you couldn't use the >>>> initial-data.sql script to start the portal (some services needed to do a >>>> lookup of the pagetype). This means that I cannot add my own page type >>>for >>>> a "fixed" template. >>>> If a new widget should be added to a subpage, is that immediately >>available >>>> for all users or are all subpages individual instances? >>>> >>>> I've been confused by PageTemplate as well on how it's supposed to be >>>used. >>> >>>Definitions (my take): >>> - Page: a usable instance owned by a single user, comprised of a >>>page_layout along and gadgets assigned to the various regions. >>> - PageLayout: a static definition of how regions are displayed on a page >>>instance >>> - PageTemplate: a static definition of how a page should be constructed >>>(includes page_layout and widgets). A Page instance would be generated >>>from >>>a PageTemplate. >>> - SubPage: ??? >> >>I think these definitions are correct, though we might want to evaluate the >>roles and responsibilities for each of these. We can also add the workspace >>piece would define the context under which you are operating. >> >>> >>>Assuming for a second that those definitions are close, then a >PageTemplate >>>isn't the actual shared page but the definition for a common page. I think >>>letting users build pages on existing templates is a great feature, >>>especially if they can then customize them from there. This would change >>>how the profile page is currently working though. Maybe we provide a way >>to >>>generate a PageTemplate from an existing Page as an alternative to >>>"sharing". This still allows users to share their layout with actually >>>having people impacted by changes to their exact page. >> >>+1 > >To be clear, this exact functionality already exists in Rave (the ability to >create >a Page from a PageTemplate, then also allowing the user to customize it after- >the-fact). I believe right now in the default data script we currently only >provide one PageTemplate, for the Person Profile Page. However >PageTemplates can also be defined for a traditional User pages as well using >all the existing code and db structure.
Further clarity :) My +1 was to letting users generate a new page template on the fly based on the configured set of widgets and layout that they have. I agree with Tony that doing this wouldn't require changes to person profile as it exists, since it builds those pages on a template today. > >To see this in action, simply look at the database upon an initial fresh >startup. >You'll see there are no Person Profile pages in the Page table. Log in and >view >the person profile page of anyone, then take a look at the database again and >you'll now see records in the Page table, which were created off of the Page >Template data. > >> >>> >>>> >>>> Another option would be to use a shared "User" page. The admin shares >>>one >>>> of his pages with every user that matches a certain profile. We would >then >>>> need to hide the option to unshare it. There are however several issues >>>> with the page sharing: >>>> - operations like delete, collapse, move or change preferences look >>>> possible, but eventually return an error message. >>>> - users that accept a shared page can add a new widget to the shared >page >>>> that is immediately added for all users that have this page >>>> - users that accept a shared page share the same instance of a gadget. If >>>> the original page owner has done oauth to retrieve data, this data >>becomes >>>> available for all users of this shared page (which means my colleague can >>>> see my google contacts or appointments). >>>> >>> >>>I'm not a huge fan of forcing an admin to share their own pages for this >>>capability. It falls apart when you have multiple admins who need to >manage >>>the static pages unless you can also delegate admin rights to your shared >>>pages to others (seems confusing). >> >>+1 >> >>> >>>> >>>> The first two points can be solved easily by adding more checks. The last >>>> point is a conceptual issue. Was this intentional or not? >>>> >>> >>>My hope is that your third point was not intentional. While I can see how >>>that could have a useful use case, I think it opens the system let people >>>make huge mistakes much to easily. My 2-cents would be that shared >pages >>>are for sharing layout not exact data. >>> >>>> >>>> >>>> So that leaves my question. What would be the way to make predefined >>>pages >>>> that can be modified by an admin? >>>> >>> >>>I think there needs to be a way to define a Page whose owner is "system" >or >>>something like that so that any admin can maintain it and share it with the >>>other users. >> >>Now that we have time actually working with them, I think we should work a >>proposal in the wiki for a new page & workspace model that more efficiently >>captures these concepts. I have started an architecture topic for this [1]. >Let's >>refine what we are looking to accomplish there. >> >>[1] http://wiki.apache.org/rave/ArchitectureTopics/PageModel >>> >>>> >>>> >>>> Jasha Joachimsthal >>>> >>>> Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 >>>4466 >>>> US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll >>>> free) >>>> >>>> www.onehippo.com >>>>
