On Dec 15, 2007 10:19 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> ...Am Mittwoch, den 12.12.2007, 17:00 +0100 schrieb Bertrand Delacretaz: > > One important goal is being able to drop a microsling application... > > The classical bootstrap problem. In Sling we solved this with a initial > content load support in the jcr/resource project.... Do you have a suggestion for how to solve that in microsling, i.e. without using OSGi bundles? A simple mechanism might be to detect (with JCR observation) when *.sysview.xml files are loaded into the repository, and import them automatically. Or, more flexible, define a script name pattern that is executed automatically when copied into the repository (I'm sure many of us would love to have this called AUTOEXEC.js ;-). This script could create the required initial content nodes when an application is dropped into microsling. Note that, if we go this route, microsling must search for such files when starting up, in case they have been added while the microsling webapp was not running. > > ISSUE 1: Chicken and egg problem, resource not found intially -> map * > > to SyntheticResource > > ....I would propose a slightly modified variant: An entry in the in the > SyntheticResourceProvider is a tuple consisting of a regular expression > for path mapping and a resource type, that is > > (regexp, resourceType) > > If the regexp matches, a SyntheticResource is created as follows... I like the idea, though if we want this in microsling we'll need some configuration mechanism (which could be part of the autoexec script mentioned above). > > > > ...ISSUE 3: Rendering a Property uses the Resource-path based script > > resolution, not good > > The problem is, that it was once decided, that properties would never be > addressed directly ... I know, but why not give access to them, at least for the GET method? We have a use case with the textarea/iframe initialization. > ...I would solve this problem such that the resource resolver would (a) > accept addressed properties and (b) the resource type of the property > resource is the resource type of the parent node. Of course a property > resource would return the property and not the parent node.... Sounds reasonable, and people can always add an extra selector to the Property URL to use a different script. > ...The core point I want to mention is, that the Resource is central point > in Sling request processing, where the resource type is used to select > actors. If we stay in this concept of a Resource with a resource type, > we do not need to implement any special casing but can just keep going.... Agreed. -Bertrand
