Chuck is talking a bit more about his experience with portlets, and the implications for uPortal, Sakai, etc.
Sakai portlet notes:
* Preferences – site.upd to change
* Edit Mode – site.upd again
* `isUserInRole()` mapped to Sakai permissions site.upd, content.read, etc.
The `isUserInRole()` mapping seems a little counter-intuitive — seems like really portlet.xml should be mapped to a particular Sakai role, and that the portlet implementation should decide whether to hardcode the semantics of that role, or look them up based on sakai permissions, or another approach.
Chuck is again advocating JSR-168 as an alternative to the Sakai tool API. At the end of the day, I really feel like the most interesting model might be building Sakai tools that use JSR-168 as the view API. So you throw away the cross-platform promise, and just rely within Sakai on JSR-168 as a well-defined, nicely separated tool component API. Though, he had a note on the end about Sakai-specific portlets, but I don’t think he’s sold yet.
JA-SIG Conference: Building Portable Portlets
Tags: about · ANT · ci · conference · idm · it · ja-sig · jasig · jasigdenver07 · jsr · JSR-168 · mapping · portal · portlet · portlets · Sakai · tar · tools · ui · uportal · XML
Chuck is talking a bit more about his experience with portlets, and the implications for uPortal, Sakai, etc.
Sakai portlet notes:
* Preferences – site.upd to change
* Edit Mode – site.upd again
* `isUserInRole()` mapped to Sakai permissions site.upd, content.read, etc.
The `isUserInRole()` mapping seems a little counter-intuitive — seems like really portlet.xml should be mapped to a particular Sakai role, and that the portlet implementation should decide whether to hardcode the semantics of that role, or look them up based on sakai permissions, or another approach.
Chuck is again advocating JSR-168 as an alternative to the Sakai tool API. At the end of the day, I really feel like the most interesting model might be building Sakai tools that use JSR-168 as the view API. So you throw away the cross-platform promise, and just rely within Sakai on JSR-168 as a well-defined, nicely separated tool component API. Though, he had a note on the end about Sakai-specific portlets, but I don’t think he’s sold yet.