I have worked on a client project with Ian's 4.x portals package. In
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.
