Hi, Am Donnerstag, den 20.12.2007, 12:26 +0100 schrieb Carsten Ziegeler: > > I think, if we emply these finegrained controls for servlet selection we > > also have not much pressure in providing such a priorization scheme, > > which looks somewhat shaky. In fact using fine grained control, we can > > have servlets which just render resources for GET requests and leave > > handling resource updates to the default servlet. > > > I agree that it makes sense to use the same mechanism for servlet > resolving as we are using for script resolving. And I also agree that in > most cases only the GET case is handle by the servlet. > > But :) the question remains if we want to provide/think about a > mechanism to handle the situation where two servlets would handle the > same request. Or the case where a servlet and a script would handle the > same request. Or even two scripts. > > Perhaps this is currently a more theoretical discussion, but imagine you > use some bundles providing default behaviour for your content and you > want to specialize this default behaviour, like using inheritance in OO > languages? > It is possible to leave this up to the administrator as he can activate > or deactivate services - but again this doesn't seem to be very user > (developer) friendly.
For script resolution we have the path concept: if a script path consisting of the resource type, the selector(s) and the request method or extension is relative, a prefix (/libs and /apps by default) is applied and the first script found wins. For servlets we might apply the same logics: If a "path" is relative a list of prefixes is applied in succession until a servlet is found. The only difference is, that in the repository only a single script with a given path may exist while for servlets multiple servlets with the same path may exist. I think, we need not over-react to such a potential collision at the moment, provided we introduce such a absolute/relative path concept. Regards Felix
