Felix Meschberger wrote:
> Noel J. Bergman:
> > > As such each request URL addresses a Content object which in turn
> > > resolves to a Component, which finally is responsible for handling
> > > the request and providing a response.
> > And this differs from a Servlet/Portlet, how?
> With Servlet/Portlet the URL resolves to the Servlet/Portlet directly
> and the Servlet/Portlet has to care for itself to acquire the data to
> act upon. With Sling, the framework resolves the URL to data and from
> the data resolves the Component (the entity corresponding to
> Servlet/Portlet).
In the case of Portlets, which might be the closest match, this isn't
strictly so, since the URL resolves to the Portal, the portal maps the
remaining request to the portlet and page (which may contain other portlets
to render).
> When the Component is called, the data is provided to the Component
> and the Component does not have to care about getting to it.
Sounds similar to something that IBM does with a page context in their
Dynamic UI in WebSphere Portal.
> In some sense components are comparable to Portlets. But while a Portlet
> just cares to render itself and generally does not know anything about
> the other portlets (obviously JSR-286 tries to overcome this limit). In
> Sling on the other hand, there is now almighty mother container, which
> knows about all components on a page to render.
OK, but that container is the Portal in a Portal server. The
components/portlets don't know about each other, but the Portal does. And
JSR-286 still doesn't let portlets know about each other. It simply
provides a means for declaring events that are JAXB-able payloads that can
be sent and delivered. The Portal is still responsible for providing a
means and control over targeting.
> Sling just resolves the URL to data and to a Component. This component
> then is responsible for rendering the complete page or finding more data
> to be included.
> Consider a page containing a page title and a paragraph system, which in
> turn consists of a series of paragraphs. With Sling, the Component
> responsible for the page would call include the page title and the
> paragraph system content. The paragraph system content in turn would
> include all paragraphs inside the paragraph system without the page
> component knowing about this at all.
Seems to me that you might want to consider a binding for JSR-286 Portlets
(using the Event mechanism to deliver the content to be rendered), rather
than create a totally new UI component framework. I can't see any reason
why the nested includes would be an issue.
Just a thought, and one that would need to be fleshed out.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
