|
Hello Johannes, Good idea to put this document out in the draft phase, now everyone can contribute. So here are my additions and clarifications which could be incorporated in the document. Chapter 4 There are actually 2 issues with object types. First is semantics and the second is naming collisions. We haven't discussed the naming collision and prevention in our session, but it might be nice to mention it. The semantic issue is more important for component sharing, but mmbase should deal with the naming collission too somewhere in the future. Naming collisions can be resolved by introducing namespaces like xml has. In xml namespaces are used to mix elements and attributes from different sources and applications. Every element or attribute name can be prefixed by a string which is mapped to a namespace URI. The URI namespace is universally managed and provides universal uniqueness of elements and attributes. 4.1 should clarify that the only way mmbase component currently can operate on models by defining several base types in the inheritance tree. The base types are usually hard to integrate in existing applications and will most likely contain fields which are not used by all applications. 4.2 describes nicely how mmbase mixin types could be used. The example is similar with an existing issue in the email application. The email builder has several properties which define in which builder and field the email address of a user is stored. This sections should also make clear that the concept of mixin types is from jsr-170, but that mmbase applies it differently. Mixin types in jsr-170 are always in addition to the primary node type. MMbase uses a mixin type to map several fields to a standardized node type which is not possible in jsr-170. A mixin type in jsr-170 is assigned after creation to a node. In our proposal the mixin type is assigned to a primary node type to map fields. Considering these differences it might be wise to drop the usage of "mixin type" as name. 5.2 The cmsc already has something in place like this. A portlet is also not allowed to know how a url looks like in the browser. A portal is allowed to provide a base url or a string which can be replaced in a post process to the real url. The cmsc uses two tags for this. The renderURL tag can be used to generate a url to tell the portal to call only the render method of a portlet. The actionURL tag is used to create a url to tell the portal to call the processAction and render methods of a portlet. Both tags can have paramters which should be added to the url. A PortalURL consists of global and local navigation elements. The global navigation elements are used to retrieve the page the portlet is on and the local navigation elements are to find the portlet on the page. For example, global is /news/2006/may/ and local is position_poll. To clarify, the new tag might be similar as the mm:url, but than without the page attibute. The page attribute should be retrieved from the application framework. Nico Johannes Verelst wrote: Hi all, |
_______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
