Hi Alexander, Am Donnerstag, den 03.01.2008, 13:03 +0100 schrieb Alexander Klimetschek: > Hi all, > > let me sum up the discussion a bit: > > Advantages of JCR are the visibility, explorability and easy > editability with standard tools (eg. mount as webdav, use your > operating systems file system support). Combined with the paradigm > "Everything is content" and pure scripting, Sling is simple and > everything of it gains from JCR's advantages. > > Now with the use of the OSGi platform in Sling, developing java > servlets is better due to a much better software lifecycle support. > But this needs an additional abstraction to include nodes, servlets > and services (IIUC, correct this list if I am wrong) called Resource. > These Resources are another tree, automatically combined based on > registered OSGi services (including servlets or even scripts) > configured by the service properties (e.g. filter.scope or > filter.order) and based on the JCR tree of nodes with content and > scripts (using sling:resourceType and some /apps, /libs etc. > convention for placing scripts inside the repository).
This explains it pretty much. > > The main problem of the resource tree is that it is completely > virtual, ie. it is invisible, non-explorable, non-editable (and not > standardized, both the structure nor the API) - which are IMHO more or > less serious drawbacks against pure JCR. This is not quite correct. Let me explain: Virtual: This does not necessairily mean invisible, non-explorable, non-editable. In fact, my idea of "virtual" is, that the resource tree is not persisted. In fact I assume, that the resource tree must be explorable by saying to "Extend resource enumeration to include resources from various sources". Non-Editable: It is true, the resource tree is read-only in that it only provides for reading resources. Updates are outside of the scope, because updates are provider dependent: JCR based resources are modified through the Session, Bundle-based resources are modified through OSGi interactions, still other resources are updated otherwise. Standardized: I don't think the API must be standardized - it must be stable and documented. And this is definitely the case here. In fact the API is very simple and straightforward IMHO. > This is independent whether > you are a strict content vs. "managed" code or "everything is > content" (even scripts) supporter, because it makes the runtime > structure of the framework much more visible, which is important for > debugging and understanding existing systems. Agreed, therefore explorability of the resource tree is part of the concept. I will more clearly note that in the wiki page. > So why not making this resource tree visible somehow. Either by > displaying it inside the sling web console This is definitely a very good idea ! Will also add that to the wiki page. > or by making it a virtual > part if the JCR repository - but I don't know how to technically > achieve that. But this way the resource tree would be even accessible > by a standardized API. This is more complicated and IMHO violates the layering principle as we inject in a "lower" (data) layer stuff from a higher (application) layer. In addition the JCR API is too heavy weight and does not provide the adapter concept, which makes the Resource tree so versatile. Regards Felix > > Alex > > -- > Alexander Klimetschek @iPhone > [EMAIL PROTECTED] > > Am 03.01.2008 um 11:42 schrieb Felix Meschberger <[EMAIL PROTECTED]>: > > > Hi, > > > > This sounds like "reinventing the wheel".... > > > > Am Donnerstag, den 03.01.2008, 12:18 +0200 schrieb Jukka Zitting: > >> No. I'd use nodes for configuring Servlets and Filters and have a > >> mechanism in the Sling framework for mapping those configuration > >> nodes > >> to the runtime instances of the components they represent. > > > > These runtime instances are OSGi services. Each service is registered > > with a set of properties. In Sling we generally use the Declarative > > Services specification. That is, each service has a declaration, and > > the > > Declarative Services implementation (called SCR for Service Component > > Runtime) cares for managing instantiation, registration and dependency > > management. > > > > So, each servlet or filter we register in Sling, always has properties > > and the filter.scope and filter.order properties are just part of the > > service descriptor. In fact, it is generally only the filter coder, > > who > > knows the correct values for these properties. So they are generally > > defined at programming time not at run time. > > > > Filter Programmers do not expect the casual user (or the > > administrator) > > to tamper with these values if not foreseen by the filter programmer. > > > > In addition to that: Consider a filter (or servlet) packaged into a > > bundle. How would the "initial configuration" come into the > > repository ? > > Of course we have the content loader, but then a filter (or servlet) > > programmer would do the following: > > > > 1. Create the Filter (or Servlet) > > 2. Care for defining the Descriptor for SCR > > 3. Add initial content for the JCR > > > > We already have support for 1. and 2. in place. 3. would just be > > another > > step with additional error possibilities. > > > > > >> This way you could use normal JCR editing tools for configuring and > >> modifying the application. > > > > Well, another thing, which already has been taken care of by OSGi: > > Through the Configuration Admin Service, configuration of service > > properties is very easy. And the Configuration Admin integrates nicely > > with the Declarative Services. > > > > So everything is already in place for these properties to be > > configurable, provided the programmer agrees in configurability of the > > properties. > > > >> Even better, with scripting support the > >> filter nodes could even be nt:files (or contain nt:files) with the > >> actual filter script that you could then modify in-place. > > > > Well, my "Everything is a Resource" paradigm IMHO better solves this > > issue. > > > > Regards > > Felix > >
