Hi,
On Jan 3, 2008 11:09 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, den 02.01.2008, 11:39 +0200 schrieb Jukka Zitting:
> > Along those lines, my counter-proposal would be to use special
> > sling:servlet and sling:filter nodes for configuring and accessing
> > such resources, sticking with the "Everything is Content" paradigm.
> > :-)
>
> I do not quite understand, how you would actually implement that ... Do
> you propose to create a node for each Servlet and Filter registered as
> an OSGi service (and conversely to remove that node again as soon as the
> servlet and filter is unregistered again) ? And then, when the node is
> accessed, how is the servlet retrieved and where it is retrieved from ?
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.
For example, instead of having "filter.scope" and "filter.order"
properties associated with filter components, I'd rather put that
configuration information inside the repository, as sling:filter nodes
within a configuration subtree. Something like this:
.../sling:config/
/filters/
/request/
filter1 [sling:filter]
filter2 [sling:filter]
filter3 [sling:filter]
...
/component/
filterA [sling:filter]
filterB [sling:filter]
...
This way you could use normal JCR editing tools for configuring and
modifying the application. 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.
BR,
Jukka Zitting
