On 23/05/2012 17:16, Paul Sharples wrote:
On 23/05/2012 15:34, Jasha Joachimsthal 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.
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.
Yes, its still incomplete - I'm working on the changes, as part of the
other things below...
- 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
If you look in the pageUser table there is an (as yet) unused 'editor'
value.
I was planning to use this to either block/allow all user actions on
the page (including adding a widget) - so the page can be set to read
only for specified users
The owner of the page would be able to set this flag when sharing the
page. (and revoke it at a later stage, if they so choose)
(Some UI actions such as minimizing a widget for example, would not
not persist the value if the logged in user is not an editor)
- 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?
Not intentional and i thought it would be the logged in users data
which populates the widget, not the original owner.
Sorry just to add that what I meant here was that I planned to change
the current behaviour to do this.
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