You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Felix Meschberger <fm...@gmail.com> on 2007/08/08 15:23:27 UTC
[Proposal] Sling
Hi all,
I would like to propose a new Apache project named Sling. The proposal
text is attached to this message and can also be found at [1].
More information on Sling may be found in the Jackrabbit Wiki at [2].
I would like to have the discussion on this proposal to go on in
parallel in the Jackrabbit Developers and Incubator General mailing
lists to gather as much feedback as possible. The vote for submission of
the project will be held on the Jackrabbit Developers list.
Of course we still welcome people willing to contribute to Sling or
merely serve as additional mentors.
Regards
Felix
[1] http://wiki.apache.org/jackrabbit/SlingProposal
[2] http://wiki.apache.org/jackrabbit/ApacheSling
Sling Proposal
==============
This is a draft version of a proposal to take the ApacheSling to the
Apache Incubator with a goal of becoming an Apache Jackrabbit
subproject. Discuss this proposal on the Jackrabbit Dev List. See the
proposal guide for a description of the expected proposal content.
Abstract
Sling is a framework to develop content centric web applications based
on the idea of modularizing the rendering of HTTP resources.
Proposal
Sling allows easy development of web application which are centered
around content which is acted upon. 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. Though
Content is a Java abstraction, the main source of data is a Java Content
Repository conforming to the JSR 170 API such as Apache Jackrabbit.
Background
Sling came to live in an effort to rewrite the central request
processing engine of Day Communiqué 4.0 and make it available for other
applications requiring an easy to use and flexible web application
framework. As such, the guidelines to develop Sling can be summarized as
follows:
Modularization:
Functional blocks of the processing engine should be split to
enable independent upgrade and replacement. At the same time
some degree of dependency management amongst the modules is
required.
Runtime Management:
Modules must enabled to be separatly started and stopped as well
as installed, upgraded and removed.
Components:
Recognizing the need to componentize development of Web
Applications and have easy mix and match for such components to
build web pages, the basic building blocks of web pages are
called components.
Content Repository:
Leading the Java Content Repository (JCR) initiative a new
request processing engine must natively support JCR (e.g. Apache
Jackrabbit) as the store for its content.
By leveraging the OSGi core service platform specification the
modularization and runtime management goals can be more than met. Sling
is therefore built as a set of bundles. Additionally Sling provides a
standalone application launcher and a web application to launch Apache
Felix as its OSGi framework to deploy the Sling bundles into.
Rationale
Content repositories, as defined in the Content Repository for Java
Technology API (JCR), are well suited to work as content stores of web
applications. However, the JCR API deals with generic Nodes and
Properties and not with business objects that would be more meaningful
to application developers. Therefore one of the building blocks of Sling
is the integration of a content mapping infrastructure, namely
Jackrabbit Object Content Mapping.
Another cause of regular headaches in current web application frameworks
is managing the life cycle of long-running applications: Add new
functionality, fix bugs, starting and stopping modules. This is where
the OSGi service platform comes into play. This specification provides
both help in the area of modularization and lifecycle management (and
more, actually) and definitions of services, so called Compendium
Services, which help concentrate on the core application and not worry
about issues such as logging, configuration management etc. Sling uses
Apache Felix as the OSGi framework.
Third, a request will generally not be handled by a single Component but
a series Components. The idea is that a request URL addresses a Content
object, which is mapped from a JCR Node and which is serviced by a
Component. The Component may then access child Content objects, aka
child nodes, and have Sling service those Content objects through their
Components again. Using this mechanism, each Component only contributes
to part of the final web page.
The advantage of this mechanism is, that Sling does not require tons of
templates or scripts to render different pages. Rather the developer may
provide a tool box of Components which may be mix-and-matched as
required. In addition this even allows for easy content authoring.
In short, the main features of Sling may be summarized as follows:
* Uses a JCR Repository as its data store
* Uses Jackrabbit OCM to map Repository Items to Java Objects
* Internally deals with Java Objects
* Built as OSGi Bundles supporting any compliant OSGi framework
* Provides integration into Apache Felix for launching and OSGi
services support
* Componentized data model allowing flexible web application
building
* Based on standard Servlet API
* Open to allow support for web application complying with REST
architectural style
* Each Node for which a valid Jackrabbit OCM mapping exists may be
addressed by URL
Initial Goals
Establish Sling as the content centric web application framework for JCR
repositories. As such, it is intended for Sling to mature into a
subproject of Apache Jackrabbit.
Current Status
Meritocracy
We plan to do everything possible to encourage an environment that
supports a meritocracy.
Community
By proposing this project to the Incubator for inclusion as subproject
of Apache Jackrabbit we hope grow Sling into first class web application
framework which leverages the know-how of the Apache community.
Core Developers
The project was founded be Felix Meschberger in late 2006 at Day.
Currently only Day employees work on this project, though this will
change as soon as we get a chance to invite more people to join this
effort. In fact the initial committer list already contains several
people not related to Day.
Alignment
Sling is targeted to be deployed into any compliant OSGi framework. To
support HTTP requests Sling interoperates with the OSGi HttpService.
This allows deployment of the framework inside a Servlet API compliant
servlet container given appropriate bridging or the framework may be run
as a standalone application, where an implementation of the OSGi
HttpService handling the HTTP requests is deployed.
To access content addressed by URLs, Sling depends on any compliant
implementation of the JCR API, such as Jackrabbit, plus the Jackrabbit
Object Content Mapping.
Known Risks
Orphaned products
This is an active project within Day Software and will be the basis of
ongoing work of Day's own content management products, such as Digital
Asset Manager. In addition, it is foreseen, that Web services of
Jackrabbit may be ported to Sling.
Inexperience with Open Source
All committers have experience working on open source projects and
several are veterans at Apache.
Homogenous Developers
Sling is currently being developed only by Day employees, but we hope
that the framework will attract interest from other individuals and
companies.
Reliance on Salaried Developers
Most of the developers are paid by their employer to contribute to this
project, but given the anticipation from the Java community for Sling
the committers' sense of ownership for the code, the project would
continue without issue if no salaried developers contributed to the
project.
Relationships with Other Apache Products
* Apache Jackrabbit
* Apache Felix
A Excessive Fascination with the Apache Brand
Day actively contributes to Apache Jackrabbit and other Apache projects,
and the individuals behind the Sling project feel that an Apache
community would be the best environment for the codebase to grow and
attract new users and contributors.
Documentation
Initial Documentation is made available on the Jackrabbit Wiki pages at
ApacheSling.
Initial Source
Currently Sling is a closed source project. For this reason the source
can only be opened upon the acceptance of the project as an Apache
Incubator project by the IPMC. Upon the acceptance of the project and
submission of the Software Grant by Day, the source code will be
committed to the Apache SVN repository.
Source and Intellectual Property Submission Plan
The code base will be licensed to the ASF using a software grant from
Day, allowing Apache to relicense as pure Apache License 2.0 code.
External Dependencies
Besides depending on two Apache projects, namely Jackrabbit and Felix,
Sling depends on the OSGi API libraries, which are made available as
part of the Apache Felix project under the Apache License 2.0.
Cryptography
* none
Required Resources
Mailing lists
* sling-dev at incubator.apache dot org
* sling-commits at incubator dot apache dot org
* sling-private at incubator dot apache dot org
Subversion Directory
* https://svn.apache.org/repos/asf/incubator/sling
Issue Tracking
* JIRA Sling (SLING)
Java Packaging
* All Sling classes live inside and below sling. It is foreseen to
root sling at org.apache such as to have all Sling classes at or
below org.apache.sling.
Other Resources
* none
Initial Committers
* Felix Meschberger (fmeschbe at apache dot org)
* Carsten Ziegeler (cziegeler at apache dot org)
* Bertrand Delacretaz (bdelacretaz at apache dot org)
* Christophe Lombart (clombart at apache dot org)
* Juan José Vázquez Delgado (juanjo dot vazquez at gmail dot com)
* ... More to be invited ...
Affiliations
Of the committers Felix, Carsten and Bertrand are tasked by Day to work
on Sling. All of them have a professional as well as an personal
interest to further develop this project. Neither of the other initial
committers is affiliated with Day in any way.
Sponsors
Champion
* Jukka Zitting (jukka at apache dot org)
Nominated Mentors
* Jukka Zitting (jukka at apache dot org)
Sponsoring Entity
* Apache Jackrabbit PMC (vote needed)
Re: [Proposal] Sling
Posted by Felix Meschberger <fm...@gmail.com>.
Hi
Am Samstag, den 18.08.2007, 21:25 +0200 schrieb Gianugo Rabellino:
> > Anyone interested in mentoring Sling?
>
> Count me in.
Thanks, your listed.
Regards
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Sling
Posted by Gianugo Rabellino <gi...@apache.org>.
On 8/17/07, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On 8/8/07, Felix Meschberger <fm...@gmail.com> wrote:
> > Sling Proposal
> > [...]
> > Nominated Mentors
> > * Jukka Zitting (jukka at apache dot org)
>
> Anyone interested in mentoring Sling?
Count me in.
Ciao,
--
Gianugo Rabellino
Sourcesense, making sense of Open Source: http://www.sourcesense.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Sling
Posted by Jukka Zitting <ju...@gmail.com>.
On 8/27/07, J Aaron Farr <fa...@apache.org> wrote:
> "Jukka Zitting" <ju...@gmail.com> writes:
> > Still looking for a third mentor, preferably from outside Day.
>
> I'll help.
Thanks!
I think we have everything in place now in the proposal and there's no
active discussion going on, so I'll follow the advice in [1] and ask
the Jackrabbit PMC as the Sponsor to vote on accepting the proposal
for incubation.
[1] http://incubator.apache.org/incubation/Incubation_Policy.html#Entry+to+Incubation
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Sling
Posted by J Aaron Farr <fa...@apache.org>.
"Jukka Zitting" <ju...@gmail.com> writes:
> Hi,
>
> On 8/17/07, Jukka Zitting <ju...@gmail.com> wrote:
>> Anyone interested in mentoring Sling?
>
> Still looking for a third mentor, preferably from outside Day.
>
> I guess we could also go forward with just two mentors for now, given
> that we have two other IPMC members (Carsten and Bertrand, both from
> Day) as initial committers, so release votes and other such stuff
> shouldn't suffer from lack of IPMC interest.
I'll help.
--
J Aaron Farr jadetower.com [US] +1 724-964-4515
馮傑仁 cubiclemuses.com [HK] +852 8123-7905
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Sling
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/17/07, Jukka Zitting <ju...@gmail.com> wrote:
> Anyone interested in mentoring Sling?
Still looking for a third mentor, preferably from outside Day.
I guess we could also go forward with just two mentors for now, given
that we have two other IPMC members (Carsten and Bertrand, both from
Day) as initial committers, so release votes and other such stuff
shouldn't suffer from lack of IPMC interest.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Sling
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/8/07, Felix Meschberger <fm...@gmail.com> wrote:
> Sling Proposal
> [...]
> Nominated Mentors
> * Jukka Zitting (jukka at apache dot org)
Anyone interested in mentoring Sling?
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Sling
Posted by Felix Meschberger <fm...@gmail.com>.
Am Donnerstag, den 09.08.2007, 09:27 -0700 schrieb Eelco Hillenius:
> > I would like to propose a new Apache project named Sling. The proposal
> > text is attached to this message and can also be found at [1].
>
> +1.
Thanks :-)
> It seems to be primarily focussed on content delivery, not so much
> interactivity, right?
Yes and no. Currently, only content delivery is supported. But it is
foreseen, that we have a need for interactive applications, such as for
example support for JSR-311, but also Portlet, JSF, etc...
> As such it would handle a sub set of what most
> other web frameworks out there now try to achieve, which makes me
> wonder whether you are planning on interoperability with other
> frameworks as a core feature?
Definitely. While we have no concept yet, I assume something like
"pseudo-content" which could be registered as a service (in OSGi terms)
and which could be used to resolve the Content instance from the URL.
This would easily fit in the model.
Regards
Felix
Re: [Proposal] Sling
Posted by Felix Meschberger <fm...@gmail.com>.
Am Donnerstag, den 09.08.2007, 09:27 -0700 schrieb Eelco Hillenius:
> > I would like to propose a new Apache project named Sling. The proposal
> > text is attached to this message and can also be found at [1].
>
> +1.
Thanks :-)
> It seems to be primarily focussed on content delivery, not so much
> interactivity, right?
Yes and no. Currently, only content delivery is supported. But it is
foreseen, that we have a need for interactive applications, such as for
example support for JSR-311, but also Portlet, JSF, etc...
> As such it would handle a sub set of what most
> other web frameworks out there now try to achieve, which makes me
> wonder whether you are planning on interoperability with other
> frameworks as a core feature?
Definitely. While we have no concept yet, I assume something like
"pseudo-content" which could be registered as a service (in OSGi terms)
and which could be used to resolve the Content instance from the URL.
This would easily fit in the model.
Regards
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Sling
Posted by Eelco Hillenius <ee...@gmail.com>.
> I would like to propose a new Apache project named Sling. The proposal
> text is attached to this message and can also be found at [1].
+1.
It seems to be primarily focussed on content delivery, not so much
interactivity, right? As such it would handle a sub set of what most
other web frameworks out there now try to achieve, which makes me
wonder whether you are planning on interoperability with other
frameworks as a core feature?
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Sling
Posted by Alexandru Popescu ☀ <th...@gmail.com>.
On 8/8/07, Felix Meschberger <fm...@gmail.com> wrote:
> Hi Alex,
>
> Am Mittwoch, den 08.08.2007, 17:03 +0300 schrieb Alexandru Popescu ☀:
> > Very interesting initiative Felix! Still, I am wondering why this
> > would not start as a Jackrabbit contrib project, and I don't think I
> > have seen this in the attached proposal.
>
> The reason for not simply adding it as a contrib to Jackrabbit is the
> "size" of the project: It consists of roughly 30 sub-projects. Pushing a
> project of this size simply as a contrib to an existing project has been
> considered as going through the backdoor and not being the Apache way.
>
> I have not taken a note on this in the proposal because we just could
> not imagine just hacking it into Jackrabbit as a contrib.
>
I see. Maybe this should be clarified in the proposal, so that others
will not have to ask :-).
As I mentioned by the time you've sent out the first email, I am very
interested in seeing what this project is.
Looking forward to hearing more,
./alex
--
.w( the_mindstorm )p.
> Hope this helps.
>
> Regards
> Felix
>
>
Re: [Proposal] Sling
Posted by Alexandru Popescu ☀ <th...@gmail.com>.
On 8/8/07, Felix Meschberger <fm...@gmail.com> wrote:
> Hi Alex,
>
> Am Mittwoch, den 08.08.2007, 17:03 +0300 schrieb Alexandru Popescu ☀:
> > Very interesting initiative Felix! Still, I am wondering why this
> > would not start as a Jackrabbit contrib project, and I don't think I
> > have seen this in the attached proposal.
>
> The reason for not simply adding it as a contrib to Jackrabbit is the
> "size" of the project: It consists of roughly 30 sub-projects. Pushing a
> project of this size simply as a contrib to an existing project has been
> considered as going through the backdoor and not being the Apache way.
>
> I have not taken a note on this in the proposal because we just could
> not imagine just hacking it into Jackrabbit as a contrib.
>
I see. Maybe this should be clarified in the proposal, so that others
will not have to ask :-).
As I mentioned by the time you've sent out the first email, I am very
interested in seeing what this project is.
Looking forward to hearing more,
./alex
--
.w( the_mindstorm )p.
> Hope this helps.
>
> Regards
> Felix
>
>
Re: [Proposal] Sling
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 08 August 2007 22:20, Felix Meschberger wrote:
> Am Mittwoch, den 08.08.2007, 17:03 +0300 schrieb Alexandru Popescu ☀:
> > Very interesting initiative Felix! Still, I am wondering why this
> > would not start as a Jackrabbit contrib project, and I don't think I
> > have seen this in the attached proposal.
>
> The reason for not simply adding it as a contrib to Jackrabbit is the
> "size" of the project: It consists of roughly 30 sub-projects. Pushing a
> project of this size simply as a contrib to an existing project has been
> considered as going through the backdoor and not being the Apache way.
>
> I have not taken a note on this in the proposal because we just could
> not imagine just hacking it into Jackrabbit as a contrib.
The legal vetting still has to be executed. Knowing that Day is fairly
competent in this field(ing), I guess that could have a very quick turn
around in the Incubator.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Sling
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Alex,
Am Mittwoch, den 08.08.2007, 17:03 +0300 schrieb Alexandru Popescu ☀:
> Very interesting initiative Felix! Still, I am wondering why this
> would not start as a Jackrabbit contrib project, and I don't think I
> have seen this in the attached proposal.
The reason for not simply adding it as a contrib to Jackrabbit is the
"size" of the project: It consists of roughly 30 sub-projects. Pushing a
project of this size simply as a contrib to an existing project has been
considered as going through the backdoor and not being the Apache way.
I have not taken a note on this in the proposal because we just could
not imagine just hacking it into Jackrabbit as a contrib.
Hope this helps.
Regards
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Sling
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Alex,
Am Mittwoch, den 08.08.2007, 17:03 +0300 schrieb Alexandru Popescu ☀:
> Very interesting initiative Felix! Still, I am wondering why this
> would not start as a Jackrabbit contrib project, and I don't think I
> have seen this in the attached proposal.
The reason for not simply adding it as a contrib to Jackrabbit is the
"size" of the project: It consists of roughly 30 sub-projects. Pushing a
project of this size simply as a contrib to an existing project has been
considered as going through the backdoor and not being the Apache way.
I have not taken a note on this in the proposal because we just could
not imagine just hacking it into Jackrabbit as a contrib.
Hope this helps.
Regards
Felix
Re: [Proposal] Sling
Posted by Alexandru Popescu ☀ <th...@gmail.com>.
Very interesting initiative Felix! Still, I am wondering why this
would not start as a Jackrabbit contrib project, and I don't think I
have seen this in the attached proposal.
tia,
./alex
--
.w( the_mindstorm )p.
On 8/8/07, Felix Meschberger <fm...@gmail.com> wrote:
> Hi all,
>
> I would like to propose a new Apache project named Sling. The proposal
> text is attached to this message and can also be found at [1].
>
> More information on Sling may be found in the Jackrabbit Wiki at [2].
>
> I would like to have the discussion on this proposal to go on in
> parallel in the Jackrabbit Developers and Incubator General mailing
> lists to gather as much feedback as possible. The vote for submission of
> the project will be held on the Jackrabbit Developers list.
>
> Of course we still welcome people willing to contribute to Sling or
> merely serve as additional mentors.
>
> Regards
> Felix
>
> [1] http://wiki.apache.org/jackrabbit/SlingProposal
> [2] http://wiki.apache.org/jackrabbit/ApacheSling
>
>
> Sling Proposal
> ==============
>
> This is a draft version of a proposal to take the ApacheSling to the
> Apache Incubator with a goal of becoming an Apache Jackrabbit
> subproject. Discuss this proposal on the Jackrabbit Dev List. See the
> proposal guide for a description of the expected proposal content.
>
>
> Abstract
> Sling is a framework to develop content centric web applications based
> on the idea of modularizing the rendering of HTTP resources.
>
>
> Proposal
> Sling allows easy development of web application which are centered
> around content which is acted upon. 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. Though
> Content is a Java abstraction, the main source of data is a Java Content
> Repository conforming to the JSR 170 API such as Apache Jackrabbit.
>
>
> Background
> Sling came to live in an effort to rewrite the central request
> processing engine of Day Communiqué 4.0 and make it available for other
> applications requiring an easy to use and flexible web application
> framework. As such, the guidelines to develop Sling can be summarized as
> follows:
>
>
> Modularization:
> Functional blocks of the processing engine should be split to
> enable independent upgrade and replacement. At the same time
> some degree of dependency management amongst the modules is
> required.
>
> Runtime Management:
> Modules must enabled to be separatly started and stopped as well
> as installed, upgraded and removed.
>
> Components:
> Recognizing the need to componentize development of Web
> Applications and have easy mix and match for such components to
> build web pages, the basic building blocks of web pages are
> called components.
>
> Content Repository:
> Leading the Java Content Repository (JCR) initiative a new
> request processing engine must natively support JCR (e.g. Apache
> Jackrabbit) as the store for its content.
>
>
> By leveraging the OSGi core service platform specification the
> modularization and runtime management goals can be more than met. Sling
> is therefore built as a set of bundles. Additionally Sling provides a
> standalone application launcher and a web application to launch Apache
> Felix as its OSGi framework to deploy the Sling bundles into.
>
>
> Rationale
> Content repositories, as defined in the Content Repository for Java
> Technology API (JCR), are well suited to work as content stores of web
> applications. However, the JCR API deals with generic Nodes and
> Properties and not with business objects that would be more meaningful
> to application developers. Therefore one of the building blocks of Sling
> is the integration of a content mapping infrastructure, namely
> Jackrabbit Object Content Mapping.
>
> Another cause of regular headaches in current web application frameworks
> is managing the life cycle of long-running applications: Add new
> functionality, fix bugs, starting and stopping modules. This is where
> the OSGi service platform comes into play. This specification provides
> both help in the area of modularization and lifecycle management (and
> more, actually) and definitions of services, so called Compendium
> Services, which help concentrate on the core application and not worry
> about issues such as logging, configuration management etc. Sling uses
> Apache Felix as the OSGi framework.
>
> Third, a request will generally not be handled by a single Component but
> a series Components. The idea is that a request URL addresses a Content
> object, which is mapped from a JCR Node and which is serviced by a
> Component. The Component may then access child Content objects, aka
> child nodes, and have Sling service those Content objects through their
> Components again. Using this mechanism, each Component only contributes
> to part of the final web page.
>
> The advantage of this mechanism is, that Sling does not require tons of
> templates or scripts to render different pages. Rather the developer may
> provide a tool box of Components which may be mix-and-matched as
> required. In addition this even allows for easy content authoring.
>
> In short, the main features of Sling may be summarized as follows:
>
> * Uses a JCR Repository as its data store
> * Uses Jackrabbit OCM to map Repository Items to Java Objects
> * Internally deals with Java Objects
> * Built as OSGi Bundles supporting any compliant OSGi framework
> * Provides integration into Apache Felix for launching and OSGi
> services support
> * Componentized data model allowing flexible web application
> building
> * Based on standard Servlet API
> * Open to allow support for web application complying with REST
> architectural style
> * Each Node for which a valid Jackrabbit OCM mapping exists may be
> addressed by URL
>
> Initial Goals
> Establish Sling as the content centric web application framework for JCR
> repositories. As such, it is intended for Sling to mature into a
> subproject of Apache Jackrabbit.
>
>
> Current Status
> Meritocracy
> We plan to do everything possible to encourage an environment that
> supports a meritocracy.
>
>
> Community
> By proposing this project to the Incubator for inclusion as subproject
> of Apache Jackrabbit we hope grow Sling into first class web application
> framework which leverages the know-how of the Apache community.
>
>
> Core Developers
> The project was founded be Felix Meschberger in late 2006 at Day.
> Currently only Day employees work on this project, though this will
> change as soon as we get a chance to invite more people to join this
> effort. In fact the initial committer list already contains several
> people not related to Day.
>
>
> Alignment
> Sling is targeted to be deployed into any compliant OSGi framework. To
> support HTTP requests Sling interoperates with the OSGi HttpService.
> This allows deployment of the framework inside a Servlet API compliant
> servlet container given appropriate bridging or the framework may be run
> as a standalone application, where an implementation of the OSGi
> HttpService handling the HTTP requests is deployed.
>
> To access content addressed by URLs, Sling depends on any compliant
> implementation of the JCR API, such as Jackrabbit, plus the Jackrabbit
> Object Content Mapping.
>
>
> Known Risks
> Orphaned products
> This is an active project within Day Software and will be the basis of
> ongoing work of Day's own content management products, such as Digital
> Asset Manager. In addition, it is foreseen, that Web services of
> Jackrabbit may be ported to Sling.
>
>
> Inexperience with Open Source
> All committers have experience working on open source projects and
> several are veterans at Apache.
>
>
> Homogenous Developers
> Sling is currently being developed only by Day employees, but we hope
> that the framework will attract interest from other individuals and
> companies.
>
>
> Reliance on Salaried Developers
> Most of the developers are paid by their employer to contribute to this
> project, but given the anticipation from the Java community for Sling
> the committers' sense of ownership for the code, the project would
> continue without issue if no salaried developers contributed to the
> project.
>
>
> Relationships with Other Apache Products
> * Apache Jackrabbit
> * Apache Felix
>
> A Excessive Fascination with the Apache Brand
> Day actively contributes to Apache Jackrabbit and other Apache projects,
> and the individuals behind the Sling project feel that an Apache
> community would be the best environment for the codebase to grow and
> attract new users and contributors.
>
>
> Documentation
> Initial Documentation is made available on the Jackrabbit Wiki pages at
> ApacheSling.
>
>
> Initial Source
> Currently Sling is a closed source project. For this reason the source
> can only be opened upon the acceptance of the project as an Apache
> Incubator project by the IPMC. Upon the acceptance of the project and
> submission of the Software Grant by Day, the source code will be
> committed to the Apache SVN repository.
>
>
> Source and Intellectual Property Submission Plan
> The code base will be licensed to the ASF using a software grant from
> Day, allowing Apache to relicense as pure Apache License 2.0 code.
>
>
> External Dependencies
> Besides depending on two Apache projects, namely Jackrabbit and Felix,
> Sling depends on the OSGi API libraries, which are made available as
> part of the Apache Felix project under the Apache License 2.0.
>
>
> Cryptography
> * none
>
> Required Resources
>
> Mailing lists
> * sling-dev at incubator.apache dot org
> * sling-commits at incubator dot apache dot org
> * sling-private at incubator dot apache dot org
>
> Subversion Directory
> * https://svn.apache.org/repos/asf/incubator/sling
>
> Issue Tracking
> * JIRA Sling (SLING)
>
> Java Packaging
> * All Sling classes live inside and below sling. It is foreseen to
> root sling at org.apache such as to have all Sling classes at or
> below org.apache.sling.
>
> Other Resources
> * none
>
> Initial Committers
> * Felix Meschberger (fmeschbe at apache dot org)
> * Carsten Ziegeler (cziegeler at apache dot org)
> * Bertrand Delacretaz (bdelacretaz at apache dot org)
> * Christophe Lombart (clombart at apache dot org)
> * Juan José Vázquez Delgado (juanjo dot vazquez at gmail dot com)
> * ... More to be invited ...
>
> Affiliations
> Of the committers Felix, Carsten and Bertrand are tasked by Day to work
> on Sling. All of them have a professional as well as an personal
> interest to further develop this project. Neither of the other initial
> committers is affiliated with Day in any way.
>
>
> Sponsors
>
> Champion
> * Jukka Zitting (jukka at apache dot org)
>
> Nominated Mentors
> * Jukka Zitting (jukka at apache dot org)
>
> Sponsoring Entity
> * Apache Jackrabbit PMC (vote needed)
>
>
>
Re: [Proposal] Sling
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 08 August 2007 21:23, Felix Meschberger wrote:
> I would like to propose a new Apache project named Sling.
+1, as Incubator PMC member.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Sling
Posted by Alexandru Popescu ☀ <th...@gmail.com>.
Very interesting initiative Felix! Still, I am wondering why this
would not start as a Jackrabbit contrib project, and I don't think I
have seen this in the attached proposal.
tia,
./alex
--
.w( the_mindstorm )p.
On 8/8/07, Felix Meschberger <fm...@gmail.com> wrote:
> Hi all,
>
> I would like to propose a new Apache project named Sling. The proposal
> text is attached to this message and can also be found at [1].
>
> More information on Sling may be found in the Jackrabbit Wiki at [2].
>
> I would like to have the discussion on this proposal to go on in
> parallel in the Jackrabbit Developers and Incubator General mailing
> lists to gather as much feedback as possible. The vote for submission of
> the project will be held on the Jackrabbit Developers list.
>
> Of course we still welcome people willing to contribute to Sling or
> merely serve as additional mentors.
>
> Regards
> Felix
>
> [1] http://wiki.apache.org/jackrabbit/SlingProposal
> [2] http://wiki.apache.org/jackrabbit/ApacheSling
>
>
> Sling Proposal
> ==============
>
> This is a draft version of a proposal to take the ApacheSling to the
> Apache Incubator with a goal of becoming an Apache Jackrabbit
> subproject. Discuss this proposal on the Jackrabbit Dev List. See the
> proposal guide for a description of the expected proposal content.
>
>
> Abstract
> Sling is a framework to develop content centric web applications based
> on the idea of modularizing the rendering of HTTP resources.
>
>
> Proposal
> Sling allows easy development of web application which are centered
> around content which is acted upon. 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. Though
> Content is a Java abstraction, the main source of data is a Java Content
> Repository conforming to the JSR 170 API such as Apache Jackrabbit.
>
>
> Background
> Sling came to live in an effort to rewrite the central request
> processing engine of Day Communiqué 4.0 and make it available for other
> applications requiring an easy to use and flexible web application
> framework. As such, the guidelines to develop Sling can be summarized as
> follows:
>
>
> Modularization:
> Functional blocks of the processing engine should be split to
> enable independent upgrade and replacement. At the same time
> some degree of dependency management amongst the modules is
> required.
>
> Runtime Management:
> Modules must enabled to be separatly started and stopped as well
> as installed, upgraded and removed.
>
> Components:
> Recognizing the need to componentize development of Web
> Applications and have easy mix and match for such components to
> build web pages, the basic building blocks of web pages are
> called components.
>
> Content Repository:
> Leading the Java Content Repository (JCR) initiative a new
> request processing engine must natively support JCR (e.g. Apache
> Jackrabbit) as the store for its content.
>
>
> By leveraging the OSGi core service platform specification the
> modularization and runtime management goals can be more than met. Sling
> is therefore built as a set of bundles. Additionally Sling provides a
> standalone application launcher and a web application to launch Apache
> Felix as its OSGi framework to deploy the Sling bundles into.
>
>
> Rationale
> Content repositories, as defined in the Content Repository for Java
> Technology API (JCR), are well suited to work as content stores of web
> applications. However, the JCR API deals with generic Nodes and
> Properties and not with business objects that would be more meaningful
> to application developers. Therefore one of the building blocks of Sling
> is the integration of a content mapping infrastructure, namely
> Jackrabbit Object Content Mapping.
>
> Another cause of regular headaches in current web application frameworks
> is managing the life cycle of long-running applications: Add new
> functionality, fix bugs, starting and stopping modules. This is where
> the OSGi service platform comes into play. This specification provides
> both help in the area of modularization and lifecycle management (and
> more, actually) and definitions of services, so called Compendium
> Services, which help concentrate on the core application and not worry
> about issues such as logging, configuration management etc. Sling uses
> Apache Felix as the OSGi framework.
>
> Third, a request will generally not be handled by a single Component but
> a series Components. The idea is that a request URL addresses a Content
> object, which is mapped from a JCR Node and which is serviced by a
> Component. The Component may then access child Content objects, aka
> child nodes, and have Sling service those Content objects through their
> Components again. Using this mechanism, each Component only contributes
> to part of the final web page.
>
> The advantage of this mechanism is, that Sling does not require tons of
> templates or scripts to render different pages. Rather the developer may
> provide a tool box of Components which may be mix-and-matched as
> required. In addition this even allows for easy content authoring.
>
> In short, the main features of Sling may be summarized as follows:
>
> * Uses a JCR Repository as its data store
> * Uses Jackrabbit OCM to map Repository Items to Java Objects
> * Internally deals with Java Objects
> * Built as OSGi Bundles supporting any compliant OSGi framework
> * Provides integration into Apache Felix for launching and OSGi
> services support
> * Componentized data model allowing flexible web application
> building
> * Based on standard Servlet API
> * Open to allow support for web application complying with REST
> architectural style
> * Each Node for which a valid Jackrabbit OCM mapping exists may be
> addressed by URL
>
> Initial Goals
> Establish Sling as the content centric web application framework for JCR
> repositories. As such, it is intended for Sling to mature into a
> subproject of Apache Jackrabbit.
>
>
> Current Status
> Meritocracy
> We plan to do everything possible to encourage an environment that
> supports a meritocracy.
>
>
> Community
> By proposing this project to the Incubator for inclusion as subproject
> of Apache Jackrabbit we hope grow Sling into first class web application
> framework which leverages the know-how of the Apache community.
>
>
> Core Developers
> The project was founded be Felix Meschberger in late 2006 at Day.
> Currently only Day employees work on this project, though this will
> change as soon as we get a chance to invite more people to join this
> effort. In fact the initial committer list already contains several
> people not related to Day.
>
>
> Alignment
> Sling is targeted to be deployed into any compliant OSGi framework. To
> support HTTP requests Sling interoperates with the OSGi HttpService.
> This allows deployment of the framework inside a Servlet API compliant
> servlet container given appropriate bridging or the framework may be run
> as a standalone application, where an implementation of the OSGi
> HttpService handling the HTTP requests is deployed.
>
> To access content addressed by URLs, Sling depends on any compliant
> implementation of the JCR API, such as Jackrabbit, plus the Jackrabbit
> Object Content Mapping.
>
>
> Known Risks
> Orphaned products
> This is an active project within Day Software and will be the basis of
> ongoing work of Day's own content management products, such as Digital
> Asset Manager. In addition, it is foreseen, that Web services of
> Jackrabbit may be ported to Sling.
>
>
> Inexperience with Open Source
> All committers have experience working on open source projects and
> several are veterans at Apache.
>
>
> Homogenous Developers
> Sling is currently being developed only by Day employees, but we hope
> that the framework will attract interest from other individuals and
> companies.
>
>
> Reliance on Salaried Developers
> Most of the developers are paid by their employer to contribute to this
> project, but given the anticipation from the Java community for Sling
> the committers' sense of ownership for the code, the project would
> continue without issue if no salaried developers contributed to the
> project.
>
>
> Relationships with Other Apache Products
> * Apache Jackrabbit
> * Apache Felix
>
> A Excessive Fascination with the Apache Brand
> Day actively contributes to Apache Jackrabbit and other Apache projects,
> and the individuals behind the Sling project feel that an Apache
> community would be the best environment for the codebase to grow and
> attract new users and contributors.
>
>
> Documentation
> Initial Documentation is made available on the Jackrabbit Wiki pages at
> ApacheSling.
>
>
> Initial Source
> Currently Sling is a closed source project. For this reason the source
> can only be opened upon the acceptance of the project as an Apache
> Incubator project by the IPMC. Upon the acceptance of the project and
> submission of the Software Grant by Day, the source code will be
> committed to the Apache SVN repository.
>
>
> Source and Intellectual Property Submission Plan
> The code base will be licensed to the ASF using a software grant from
> Day, allowing Apache to relicense as pure Apache License 2.0 code.
>
>
> External Dependencies
> Besides depending on two Apache projects, namely Jackrabbit and Felix,
> Sling depends on the OSGi API libraries, which are made available as
> part of the Apache Felix project under the Apache License 2.0.
>
>
> Cryptography
> * none
>
> Required Resources
>
> Mailing lists
> * sling-dev at incubator.apache dot org
> * sling-commits at incubator dot apache dot org
> * sling-private at incubator dot apache dot org
>
> Subversion Directory
> * https://svn.apache.org/repos/asf/incubator/sling
>
> Issue Tracking
> * JIRA Sling (SLING)
>
> Java Packaging
> * All Sling classes live inside and below sling. It is foreseen to
> root sling at org.apache such as to have all Sling classes at or
> below org.apache.sling.
>
> Other Resources
> * none
>
> Initial Committers
> * Felix Meschberger (fmeschbe at apache dot org)
> * Carsten Ziegeler (cziegeler at apache dot org)
> * Bertrand Delacretaz (bdelacretaz at apache dot org)
> * Christophe Lombart (clombart at apache dot org)
> * Juan José Vázquez Delgado (juanjo dot vazquez at gmail dot com)
> * ... More to be invited ...
>
> Affiliations
> Of the committers Felix, Carsten and Bertrand are tasked by Day to work
> on Sling. All of them have a professional as well as an personal
> interest to further develop this project. Neither of the other initial
> committers is affiliated with Day in any way.
>
>
> Sponsors
>
> Champion
> * Jukka Zitting (jukka at apache dot org)
>
> Nominated Mentors
> * Jukka Zitting (jukka at apache dot org)
>
> Sponsoring Entity
> * Apache Jackrabbit PMC (vote needed)
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Sling
Posted by Alexandru Popescu ☀ <th...@gmail.com>.
On 8/11/07, Noel J. Bergman <no...@devtech.com> wrote:
> Felix Meschberger wrote:
>
> > Noel J. Bergman:
>
> [... snip ...]
>
>
> 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.
>
IMO, if we want to keep this framework generic enough, I would
recommend no initial bindings, but rather a generic plugable
architecture that will further allow usage in component based apps
(being it JSF/Wicket/Portlet) or command based apps
(Struts2/WW/SpringMVC/etc.).
./alex
--
.w( the_mindstorm )p.
> --- Noel
>
>
>
Re: [Proposal] Sling
Posted by Alexandru Popescu ☀ <th...@gmail.com>.
On 8/11/07, Noel J. Bergman <no...@devtech.com> wrote:
> Felix Meschberger wrote:
>
> > Noel J. Bergman:
>
> [... snip ...]
>
>
> 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.
>
IMO, if we want to keep this framework generic enough, I would
recommend no initial bindings, but rather a generic plugable
architecture that will further allow usage in component based apps
(being it JSF/Wicket/Portlet) or command based apps
(Struts2/WW/SpringMVC/etc.).
./alex
--
.w( the_mindstorm )p.
> --- Noel
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Concern over JSR-311 and any other Sun-led JSRs
Posted by "Noel J. Bergman" <no...@devtech.com>.
Roy T. Fielding wrote:
>>> I would just add that JSR-311 might also be an option.
>> As an aside (and since you folks are on the Expert Group), do we
>> know if JAX-RS will be under a suitable specification license,
>> or has Sun encumbered it as they have other Sun-led specifications?
> We don't know. We won't implement JSR-311 if it isn't open, but at
> this point I wouldn't trust Sun even if they promised a BSD license.
Then why, for crying out loud, are we in the Java Community permitting Sun
to lead any JSRs? We hardly need them for this JSR -- as if Sun are even
remotely subject matter experts -- much less many others. Let's boot Sun
out of the specification process, and return to OPEN Specifications. Surely
Day Software and others are qualified -- more qualified than Sun in fact --
to lead a JAX-RS effort.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Sling
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
>> I would just add that JSR-311 might also be an option.
>
> As an aside (and since you folks are on the Expert Group), do we
> know if
> JAX-RS will be under a suitable specification license, or has Sun
> encumbered
> it as they have other Sun-led specifications?
We don't know. We won't implement JSR-311 if it isn't open, but at
this point I wouldn't trust Sun even if they promised a BSD license.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Sling
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
>> I would just add that JSR-311 might also be an option.
>
> As an aside (and since you folks are on the Expert Group), do we
> know if
> JAX-RS will be under a suitable specification license, or has Sun
> encumbered
> it as they have other Sun-led specifications?
We don't know. We won't implement JSR-311 if it isn't open, but at
this point I wouldn't trust Sun even if they promised a BSD license.
....Roy
RE: [Proposal] Sling
Posted by "Noel J. Bergman" <no...@devtech.com>.
Felix Meschberger wrote:
> As Alex also pointed out, the goal is to have a flexible framework to
> allow for different bindings.
Ah, that was not clear from the proposal. I thought that you were planning
to define your own, new, component model for delivering the content back to
the requestor. So I am glad that we have had this discussion.
> I would just add that JSR-311 might also be an option.
As an aside (and since you folks are on the Expert Group), do we know if
JAX-RS will be under a suitable specification license, or has Sun encumbered
it as they have other Sun-led specifications?
--- Noel
RE: [Proposal] Sling
Posted by "Noel J. Bergman" <no...@devtech.com>.
Felix Meschberger wrote:
> As Alex also pointed out, the goal is to have a flexible framework to
> allow for different bindings.
Ah, that was not clear from the proposal. I thought that you were planning
to define your own, new, component model for delivering the content back to
the requestor. So I am glad that we have had this discussion.
> I would just add that JSR-311 might also be an option.
As an aside (and since you folks are on the Expert Group), do we know if
JAX-RS will be under a suitable specification license, or has Sun encumbered
it as they have other Sun-led specifications?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [Proposal] Sling
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Noel,
> 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.
As Alex also pointed out, the goal is to have a flexible framework to
allow for different bindings. I would just add that JSR-311 might also
be an option.
Perhaps, those bindings will be required sooner or later but should be
"easy" to do.
Regards
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [Proposal] Sling
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Noel,
> 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.
As Alex also pointed out, the goal is to have a flexible framework to
allow for different bindings. I would just add that JSR-311 might also
be an option.
Perhaps, those bindings will be required sooner or later but should be
"easy" to do.
Regards
Felix
RE: [Proposal] Sling
Posted by "Noel J. Bergman" <no...@devtech.com>.
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
RE: [Proposal] Sling
Posted by "Noel J. Bergman" <no...@devtech.com>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [Proposal] Sling
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Noel,
Am Mittwoch, den 08.08.2007, 23:12 -0400 schrieb 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). When the Component is called, the data is provided to
the Component and the Component does not have to care about getting to
it.
> > Recognizing the need to componentize development of Web
> > Applications and have easy mix and match for such
> > components to build web pages, the basic building blocks
> > of web pages are called components.
>
> Differing from JSR-168/JSR-286 Portlets, how? Other than "by leveraging the OSGi core service platform specification"?
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.
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. Include means, the data (in terms of a Java object
implementing the Content interface) is given to Sling to resolve the
Component to call. At the end of the page rendering process, Sling has
just actively resolved the initial data/Component and was involved in
further processing but did not control the actuall process.
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.
>
> Obviously, looking for some details. But not such that I'm voting on the answer.
I hope, this helps shed some more light on it.
Regards
Felix
RE: [Proposal] Sling
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Noel,
Am Mittwoch, den 08.08.2007, 23:12 -0400 schrieb 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). When the Component is called, the data is provided to
the Component and the Component does not have to care about getting to
it.
> > Recognizing the need to componentize development of Web
> > Applications and have easy mix and match for such
> > components to build web pages, the basic building blocks
> > of web pages are called components.
>
> Differing from JSR-168/JSR-286 Portlets, how? Other than "by leveraging the OSGi core service platform specification"?
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.
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. Include means, the data (in terms of a Java object
implementing the Content interface) is given to Sling to resolve the
Component to call. At the end of the page rendering process, Sling has
just actively resolved the initial data/Component and was involved in
further processing but did not control the actuall process.
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.
>
> Obviously, looking for some details. But not such that I'm voting on the answer.
I hope, this helps shed some more light on it.
Regards
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [Proposal] Sling
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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?
> Recognizing the need to componentize development of Web
> Applications and have easy mix and match for such
> components to build web pages, the basic building blocks
> of web pages are called components.
Differing from JSR-168/JSR-286 Portlets, how? Other than "by leveraging the OSGi core service platform specification"?
Obviously, looking for some details. But not such that I'm voting on the answer.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org