[I have to say that I have not tried rails extensively but I did skim over their implementation of active record, etc]
If I understand Lars article, the main problem is granularity.
[High-level organization] If you are a developer-user of the platform then granularity stops at the package level and the things you can do with the package manager and the site (map) admin interface.
[Medium-level organization] OTOH, if you are a developer-developer the "granules/constructs" are not as finely grained as they need to be. You would either have to go with the existing constructs, i.e. form, list, page, portlet or you would have to build something from scratch.
This won't cut it. What I believe is missing, is a lower-level of organization which is currently (wrongly) substituted by copy/modify/write practices of tcl procs manipulating db tables and plsql code.
What is needed, is a larger granule that can be customized without copy/pasting existing code. This is mainly subdivided in three items:
* [reusable behaviour] a class granule is a step forward since it provides added flexibility (for example, via subclassing)
* [reusable structure] move data model into a db neutral granule, for example a db class [I do NOT advocate the use of a persistence layer here, just some way of exploiting reusable behaviour for structure]
* [reusable interface] expose UI granules both at the tcl level and also at the highest level via customization services... for example, there must be a way to represent a page as a tree of UI granules/portlets that depend on a collection of data sets and their decoration and placement (layout). This IMO would enable a developer-developer to prepare a page quickly and only at the end improve the graphic design part. [This is not as simple as it sounds but it can be done]
