>-----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 > >> >> 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 >>
