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