1]
http://apache-sling.73963.n3.nabble.com/RE-RTC-ThreadLocal-for-getting-current-request-in-sling-summary-tt4042631.html
>
>> if you call and OSGi service you do not have to know what services this has
>bound internally, OSGi takes care that all are resolved or the service is not
>
Hi Dominik,
It is true that the ClassUseProvider only deals with resource and
request objects, but That's far from the only way to use adaptTo from
Sightly scripts.
Justin
On Fri, Oct 24, 2014 at 10:40 AM, Dominik Süß wrote:
> Hi Justin,
>
> it is not true that no change in sightly would be requ
Hi Justin,
it is not true that no change in sightly would be required sightly use just
tries to adapt resource or request, not any other objects (see
ClassUseProvider L65 ff as to be found in the contribution zip).
I'm currently searching for the option to solve the case with the least
modificati
Hi Dominik,
Anyone is free to define their own objects which implement Adaptable
and their own model classes which can be adapted from those adaptable
classes. This doesn't require any additions to any part of Sling nor
any changes to Sightly.
Regards,
Justin
On Fri, Oct 24, 2014 at 10:20 AM, Do
Hey everybody,
thinking about this again I also realized that changing the Adaptable
Interface or having another one creates more issues then solving. In fact
it would be way easier to have some generic Wrapperclass that can hold the
request and another object and implementing Adaptable.
This w
Hi Stefan,
On Fri, Oct 24, 2014 at 7:53 AM, Stefan Seifert wrote:
>
>>Personally, I don't quite see the use case -- if your AdapterFactory
>>(whether it is generated by Sling Models or hand-coded) needs
>>request-based context, the adaptable is the request.
>
> to shed some more light on my useca
Am 24.10.14 um 13:53 schrieb Stefan Seifert:
>
> i'm not a fan of the proposals to extend the adaptTo() semantic for
> this usecase. not only because its difficult to do it without
> breaking existing code (or leads to an interface like Adaptable2),
> the caller should not have to now the impleme
request filter, so i'll be fine with this way as
well if the community does not want A) or B).
stefan
>-Original Message-
>From: Stefan Seifert [mailto:sseif...@pro-vision.de]
>Sent: Wednesday, October 22, 2014 10:22 AM
>To: dev@sling.apache.org
>Subject: [RTC] Thr
>Personally, I don't quite see the use case -- if your AdapterFactory
>(whether it is generated by Sling Models or hand-coded) needs
>request-based context, the adaptable is the request.
to shed some more light on my usecase an example:
- a sightly template calls a "controller" model, which adap
On 23.10.2014, at 15:39, Alexander Klimetschek wrote:
> BTW, this is what I think is great about OSGi services, that they are based
> on plain Java interfaces and don't have all the complexities of DI frameworks
> such as Sling
I mean "Spring" of course :)
Alex
On 23.10.2014, at 15:14, Dominik Süß wrote:
>
> adding some contexobject is IMHO not hidding anything.
It is - if you never see that behind the scenes a request object is passed
along (and what not else), but in other cases outside the request scope it is
not, this can be confusing. It is impo
Hi Alex,
adding some contexobject is IMHO not hidding anything. There are cases
where you would want to have the context for creation of a model (or any
other adaptable) - so at construction time which disqualifieds some method
to be called afterwards.
What't the issue with someresource.adaptTo(My
On 23.10.2014, at 01:04, Dominik Süß wrote:
>
> While request.adaptTo(Target.class) would enable an AdapterFactory to get
> hold of the currentResource there is no chance to get the the custom
> resource.
Why not have a setter?
MyModel model = resource.adaptTo(MyModel.class)'
model.setRequest(s
Hi,
On Thu, Oct 23, 2014 at 10:04 AM, Dominik Süß wrote:
> ...To get around that I was thinking if it wouldn't be a good idea to add a
> further adaptTo() signature which would allow to add a generic payload
> which could contain contextobjects that an adapterFactory could use for
> construction.
Hi everyone,
didn't follow the whole discussion so I might have missed some poin but if
I get it right the case where it gets problematic is when I essentially
want to adapt to from a resource (that is not the currentResource) without
losing the request scope.
While request.adaptTo(Target.class)
Am 22.10.14 um 23:21 schrieb Alexander Klimetschek:
> On 22.10.2014, at 01:22, Stefan Seifert wrote:
>> i propose to add a new feature to the Sling API and Sling Engine to access
>> to the current request via an OSGi service, using a servlet filter and a
>> thread local internally.
>
> -1
>
>>
On Wed, Oct 22, 2014 at 5:44 PM, Alexander Klimetschek
wrote:
> On 22.10.2014, at 14:36, Justin Edelson wrote:
>> To be clear, Sling Models was designed *not* to have an explicit API
>> and to be a way to implement of AdapterFactories. For version 1.2.0,
>> it does have an API, but this is essent
On 22.10.2014, at 14:36, Justin Edelson wrote:
> To be clear, Sling Models was designed *not* to have an explicit API
> and to be a way to implement of AdapterFactories. For version 1.2.0,
> it does have an API, but this is essentially just a mirror of the
> AdapterManager API plus some utility me
Hi,
On Wed, Oct 22, 2014 at 5:21 PM, Alexander Klimetschek
wrote:
> On 22.10.2014, at 01:22, Stefan Seifert wrote:
>> my current usecases are:
>> - having the ability to inject context objects like request in any sling
>> model, regardless of the adaptable. this is e.g. importing when adapting
>> my current usecases are:
>> - having the ability to inject context objects like request in any sling
>model, regardless of the adaptable. this is e.g. importing when adapting from
>a resource, but in context of a request (SLING-4083)
>
>That should be possible to solve differently, such injecti
On 22.10.2014, at 01:22, Stefan Seifert wrote:
> i propose to add a new feature to the Sling API and Sling Engine to access to
> the current request via an OSGi service, using a servlet filter and a thread
> local internally.
-1
> a proposal for such an implementation is currently part of slin
Am 22.10.14 um 10:52 schrieb Bertrand Delacretaz:
> Hi,
>
> On Wed, Oct 22, 2014 at 10:22 AM, Stefan Seifert
> wrote:
>> ...i propose to add a new feature to the Sling API and Sling Engine to
>> access to the current request via an OSGi service, using
>> a servlet filter and a thread local inte
Hi,
On Wed, Oct 22, 2014 at 10:22 AM, Stefan Seifert wrote:
> ...i propose to add a new feature to the Sling API and Sling Engine to access
> to the current request via an OSGi service, using
> a servlet filter and a thread local internally
+1 in principle, though as Carsten says we can imp
Am 22.10.14 um 10:22 schrieb Stefan Seifert:
> i propose to add a new feature to the Sling API and Sling Engine to access to
> the current request via an OSGi service, using a servlet filter and a thread
> local internally.
I think *if* we're doing this, we should add this into the engine and
av
i propose to add a new feature to the Sling API and Sling Engine to access to
the current request via an OSGi service, using a servlet filter and a thread
local internally.
a proposal for such an implementation is currently part of sling models trunk,
but should be renamed and moved to a more c
25 matches
Mail list logo
