>-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of Sean >Cooper >Sent: Wednesday, May 23, 2012 1:06 PM >To: [email protected] >Subject: Re: Predefined pages > >On Wed, May 23, 2012 at 10: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. > > >This sounds like a use case for a project dashboard or a team page. > > >> >> 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. >> >> 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? >> >> >> 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). >> >> The first two points can be solved easily by adding more checks. The last >> point is a conceptual issue. Was this intentional or not? >> > > >This sounds more like a project dashboard or a team page. The admin >shouldn't have to 'share' out the page, but the page should be >accessible by multiple people while the admin controls the gadget >layout and content for the gadgets. > >I think we need to add a TeamPage definition and shake out a >definition of what that means. This conversation was started in >another thread... from the top of my head here is what I remember of >it > 1) Single owner of the page (which is transferable or maybe even shared) > 2) Anyone can view (or possibly a set of people can view) > 3) Owner controls the page template, gadget layout, gadget settings, etc > 4) Can have sub-pages > 5) URL is not tied to the owner of the page, instead should be the >id of the TeamPage or possibly even the 'name' of the TeamPage if a >requirement exists to keep them unique.
I just created a wiki page to start refining this concept. Let's make sure this gets added there. > >> >> So that leaves my question. What would be the way to make predefined >pages >> that can be modified by an admin? >> >> >> 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
