Forum OpenACS Development: Portals roadmap proposal
not-so-near-term enhancements to the portals module:
Comments would be greatly appreciated.
ACES does this (and was the starting point of our discussion) within the constraints of the existing portals package (in it's 3.4 form). But it's limited by the fact that the customization options are limited (i.e. title bar color and a couple of other things) and that customization options are at the portal, not portlet, level.
A limited expansion of the capability of the portal package could greatly increase its usability.
Read Michael's roadmap proposal and comment away!
I think that's some great stuff you posted. Very helpful in generating new ways to think about the portals module.
However, I'm not really clear about how portals, CMS and graphic designers work together. It seems to me that portals is a way of removing the graphic designer from having to generate UI all the time and allowing the user to to select a modular presentation of data from across the system. Rather than have the UI designer define how and where each person can view information, the user can select what info and how they wills see it.
An administrator chooses what info a user or user group gets to see. For example, everybody in an organization sees the general information that everyone needs to see -- what's for lunch in the cafeteria, where the stapler can be found and why God has abandoned us in our times of need. Also, each person gets a limited view of their mailbox so they know what they received last. However, Sammy the SysAdmin gets a page with all the pertinent system information, Gloria the Graphic Artist gets the latest pages to be delivered and Eduardo the Executive gets to see his stock quotes.
That is a pretty general description of how portals work. However, I'm not really sure what you're asking for that doesn't have to be built on a case by case basis. I must admit that I am not familiar with ACS 3.4, let alone ACES 3.4 so I don't really know what you are referencing.
Perhaps my real question is what kind of control do you want or need over the portlets? Shouldn't the portlets have as little UI design as possible so that they can conform to any data placed in them? What does a portlet consist of, anyway? Can you give me some examples of what kinds of data would be displayed in each of these?
Forgive me for asking these questions if they are a little elementary. I have some ideas of what I would like to see the portals packaged used for but I think that it's much more straightforward than what you are talking about. If you can describe it a little more I would appreciate it.
graphic designers work together. It seems to me that portals is a
way of removing the graphic designer from having to generate UI
all the time and allowing the user to to select a modular
presentation of data from across the system. Rather than have
the UI designer define how and where each person can view
information, the user can select what info and how they wills see
<p>To begin with, CMS and portals don't necessarily work
together at all. In fact, my point was exactly that CMS and portals
are largely orthogonal. CMS is fine if you want to crank out huge
numbers of content pages but not necessarily helpful when you
want to create a relatively small number of site pages with
hooks into various ACS modules. This is exactly why we need a
robust portals module in addition to a CMS.</p>
<p>Regarding the question of whether the whole point of the
portals module is to get rid of the graphic designers, I'd say the
answer is "not necessarily." Certainly, one possible use of
portals is to allow end users to pick their own personal windows
into a site. However, more often portals (if built right) could allow
site designers to set up the look and feel for whole classes of
users. If you think about the layout of, say, the home page of a
site, a great deal of thought goes into the visual design. Sure,
you may have an area (or "portlet") with links to latest news and
another with links to discussion boards, but they are not all
equally weighted. You want to be able to call the users' attention
to whatever is most important. If all portlets look exactly the
same, then you (the site designer) are denied the ability to
emphasize or de-emphasize elements on the page relative to
<p><i>Perhaps my real question is what kind of control do you
want or need over the portlets?</i></p>
<p>Think of the portals module as a site layout tool--a sort of
Quark for OpenACS. With it, you could bundle up any chunk of a
page (e.g., a box of text, a graphic, a news items window) as an
object and move it around a page, move it between pages, and
so on. In this vision, you'd want to exert the same visual control
over a portlet that you'd want to have over any object on any web
<p><i>Shouldn't the portlets have as little UI design as possible
so that they can conform to any data placed in them?</i></p>
<p>I'm not exactly sure what you mean by having a portlet
"conform to any data" placed in it. I agree that the portlets (by
which I mean the containers for the data) should <i>have</i> very
little UI. However, the portlet instances (by which I mean the data
showing through the container, displayed in a particular way)
<i>are</i> user interface. As such, a designer should be able to
control the way they look (and, in some cases, act).</p>
<p><i>What does a portlet consist of, anyway?</i></p>
<p>Maybe the best way to think of a portlet is as a container for a
(static or dynamic) content object. It can be displayed as part or
all of a page. Why turn pages or page parts into objects? Mainly
so that you can move it around easily (i.e., without
programming). Again, it's a layout tool.</p>
<p><i>Can you give me some examples of what kinds of data
would be displayed in each of these? </i></p>
<p>Sure. I'll use the example of an online course, since I know
that development problem the best:</p>
<li>You want to create a page tied to the calendar package that
shows due dates for all assignments (i.e., a syllabus). But you're
not sure where you want to put that page on the menu bar. So
you package it up as a portlet so you can move it around
<li>You want to create a window that shows new posts to the
discussion board. You want it on the home page and you want it
to have medium importance. So you put it in a portlet, move it to
the upper right quadrant of the page, and give it a visual
treatment that adds some weight.</li>
<li>You also want to create a window on the home page that
randomly displayed highly rated discussion posts. You want that
to be very prominent. So you put it in the upper left-hand
quandrant and you make it really stand out.</li>
<li>Even though about 90% of your class home page is dynamic,
you do want to have a static "Welcome to the class" message.
So create a portlet with an invisible box around it and move it to
the top of the page, spanning all three columns.</li>
<p>Could this be done without portlets? Sure. But you'd need a
programmer or at least an adp-savvy web designer to do it some
other way. With portlets, you can have <i>each</i> teacher
customize her own class without the help of a programmer. You
can also allow those teachers with a little graphic design savvy
or graphic design help (but without a programmer) to customize
the look of the objects on the page to give each object the
appropriate visual weight and position for UI (and aesthetic)
<p><i>Forgive me for asking these questions if they are a little
<p>Not at all. Don and I are proposing a new way of thinking
about the portals module. Nothing is self-evident here.</p>
prototyping tool (or, to be more accurate, a RAD tool). I, a
non-programming site designer, can whip together an
approximation of all the page layouts I want pretty quickly without
any programming or graphic design by using the existing
portlets when possible and creating dummy HTML mock-up
portlets when necessary. Once the layout is in place, the graphic
designers can work on making my design more visually
informative (and appealing) while the programmers can work on
turning my mock-ups into actual dynamic portlets. So the portals
module could change and accelerate the workflow for designing
and building an OpenACS-based site.
This reminds me again of Manila. It uses "macros" which allow you to display different features on a page. They are special codes that the admin of the site puts in the templates for the site.
It seems this idea should be built into (is it?) the CMS so a designer or whoever could just put in the hooks to the code into a page. Of course we don't want the admin even seeing the macros, they just want to build a page without learning to code, so:
Portals seems similar to the wizard idea aD had for the CMS. They could be a UI built on top of the CMS, or as an alternative to the current (or future) CMS interface.
I think we are all almost on the same page. Basically we want to make it easy for someone to build a small site. That is one way to make OpenACS more popular. It's perfect for the type of sites I have been building.
- More flexible header/footer control on individual portlets. We ended up just turning off all header/footer generation within portals and resorting to custom function calls (my_portal_header, my_portal_footer) within the portals themselves
- Import the acs 4.x enhancements - primarily, eliminate the need for the adp processing step (we just use a single function call for most of our portals - ACS4 lets us pick between ADP and TCL functions)
- Replace or eliminate the multi-page code - we didn't use it.
- Allow most portals to take an arbitrary number of content lines to display. For instance, if a view of the bboard system, let the user control the number of postings shown.
- On the subject of making portals interoperate with CMS, it would be nice if you could call portlets from a templated page. It would also be nice if you could designate each new CMS-generated page as a portlet.
- On the topic of removing the multi-page code, I emphatically disagree with Kjell. If anything, as I suggest in my roadmap proposal, we should expand this capability.
The separate pages are set up as a set of links that run across the top of the page rather than the ugly boxy tabs.
Rather than simply get rid of the multi-page functionality, the portal admin should be able to control whether or not users can add pages to their portal or migrate portlets from one page to another.
The reason I ask is because the discussion of portlets being included templates is an old idea that Ian discussed with several of us internally. I guess since the CVS repository for ACS 4 packages is public I'm in the clear discussing it. Anyway, I would hate to see all of Ian's hard work go to waste.
Of course, this may all be derived from his code that was under CVS and I may be way off mark, but all this discussion seems like deja vu...
If Ian already implemented some similar ideas and if they're in the public repository, hooray! We already have it. If it's just in an aD CVS tree somewhere, we don't.
Do you have an e-mail address for Ian? He should become one of us!
Ian's implementation contains at least some of Michael's requested features. The APM should do a nice job of making it possible to share locally implemented portlets with other sites. There's a lot of flexibility for providing different layouts for portal pages, and I think this is new. The ability to create a "mockup" page containing static html is there.
The ACS4 version is more flexible with respect to where and how the portal pages are organized. You mount the portal package on a site node using the site map, and that constitutes a new portal page. The cms package I proposed works the same way: you mount it on a site node and then you can add articles to that node. So integrating the two packages would not be difficult.
You can download Ian's documentation for the 4.x portal package here.
Disclaimer: I have not built a site that uses any version of portals, and would enjoy hearing from anyone who has had that experience.
I can say that after staring at his code and documentation for a couple of days, but further evidence comes from the fact that the ArsDigita intranet rewrite was relying on it, and extending it to make it easier to use. Reading Michael Bryzek's notes about the intranet project are what made me consider the portal application an essential part of the toolkit.
Yes, I believe that ACES has been widely considered inside aD as being a specialized variant of intranet. Given that ACES relies very heavily on portals, it makes sense that intranet does as well in 4.x.
The APM should do a nice job of making it possible to share locally implemented portlets with other sites.
Am I understanding correctly that ACS Site X could tie into Site Y's bboard (for example) and make it look as if it were an integrated part of Site X? If so, that's fantastic!
I haven't looked to see how much you can do with each theme, but it seems that you can provide a template so that would mean just about anything your heart desires.
There are a variety of datasources available, Tcl, ADP, and PL/SQL - this needs to be generalized, if there's not existing code that depends on that name can we change it to be database-diagnostic, i.e. "stored function" is the SQL92 generic phrase. It needn't be in any particular language in PG (i.e. calls for PL/Tcl, PL/pgSQL, PL/Python etc all look the same). That's true of Oracle, too, isn't it? Or doesn't Oracle support stored SQL functions as well as PL/SQL ones?
Whatever, if you've got time Luke it would be nice if you'd get rid of that PL/SQL naming for functions...
One datasource type is "raw" which gives the "container wrapping HTML" static case Michael discusses.
this case it was almost entirely from the user customisation
perspective. On the whole the package has worked well and the clients
are happy with it. Probably the most important notes to come out for
the portal package were:
The site designers would like to be able to restrict the dynamic
regions within a layout that elements could be assigned to. For
example, if an element has a wide design so that it should only appear
in certain wider dynamic regions on the layout page then the designers
would like to incorporate that restriction. This level of control is
not present in the 4.x portals package.
The portals package has no framework for per request caching. Many
elements of a portal will share _some_ information; for example
permission checks and user information such as regional localisation
or specified theme. For our portal the method for caching this
information within one request, so that each element didn't hit the db
separately, was ad hoc - it should probably be formalised in the
design of the portal package.
The permissioning is overly complex. Each element, datasource and
template is permissioned separately. Combined with the point above,
this very quickly adds up to a large number of db hits per request.
In our case the client wasn't interested in controlling access to
individual elements; so maybe a more coarse grained approach to
permissioning would be better?
disclaimer: I worked with an early release of the portal package (0.4)
and don't know if any of these features have since been added.
Sorry, no. APM "just" lets you install packages from the net onto your own server. But an xml-rpc interface to request that another server render a particular portal for you would be a very interesting thing to build, and could probably be tied into the portal package's list of "datasources" in a very clean way.
And, yeah, implementing an xml-rpc datasource for portals could be ultra-cool...