Hi, Is there something like a search query parser for MMBase?
groet, Ruud -----Original Message----- From: Nico Klasens [mailto:[EMAIL PROTECTED] Sent: Mon 5/22/2006 11:45 PM To: Discussion list for developers Cc: Subject: Re: [Developers] RFC: MMBase frameworks 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. This will have a major impact on the source code of mmbase and will also have impact on applications on top of mmbase. How often name collisions occur in practice is not clear. 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, > > As some of you know (and probably others don't), I have been busy > together with Nico Klasesn to see if there is a way to create an > "MMBase framework". The reason is simple: many companies have spent > huge amounts of money for custom MMBase implementations, and > components in those implementations are never given back to the > community. One of the reasons is because of the 'lock-in' to their own > framework which was built on top of MMBase. > > With many frameworks already in existance, and the need for "generic > components", I looked with Nico at Didactor, the EO site and to > finalist's Karma/CMSC. The result of this session is now a word > document that I attach here (html version also added). > > The main suggestion is: don't enforce a "great unified mmbase > framework", but work the other way around: define some interfaces that > frameworks should implement and components must use. That way every > framework can keep its own way of doing things. So, don't enforce > people to use either tree-include or leaf-include, but create an > interface for creating URLs for which the EO will write an > implementation for their framework which generates urls based on > leaf-include. > > Next week, on the symposium organized by Jo, I will present this > proposal to parties interested in a mechanism to share components > between parties. Currently it is "my" proposal (together with Nico), > but I would hope it could be "our" proposal. For that I need your > comments, insights and possibly even flamewars :). > > Johannes > >------------------------------------------------------------------------ > >_______________________________________________ >Developers mailing list >[email protected] >http://lists.mmbase.org/mailman/listinfo/developers > >
<<winmail.dat>>
_______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
