I think that folks at this point tend to frown on using servlets for
rendering. JSP, Velocity, and Freemarker (perhaps ESP ;-) are better
suited for that. Pure servlets, imho, should be used for front
controllers and other such applications but should not do any display
rendering.
-paddy
Hi Felix,
I see scripts mainly as a mechanism to express rendering/behavior and
servlets serve the same purpose, so from my level of abstraction,
there is no conceptual difference.
Lars
Am 31.10.2007 um 22:27 schrieb Felix Meschberger:
Hi Lars,
Am Mittwoch, den 31.10.2007, 22:01 +0100 s
Hi Lars,
Am Mittwoch, den 31.10.2007, 22:01 +0100 schrieb Lars Trieloff:
> Is there a conceptual difference between servlets and scripts?
Yes and no :-) On the one hand scripts are just a special case of
servlets. But then scripts are loaded differently that servlets.
Servlets are registered wit
Hi Bertrand,
As Felix indicates, we have designed something like this in the API
(although it's not yet implemented in microsling) with the
RequestDispatcherOptions class, which is just a Map of options.
This allows you to render either the current Resource, or another one,
and override its res
Hi Felix,
Am 31.10.2007 um 08:54 schrieb Felix Meschberger:
Hi,
Am Dienstag, den 30.10.2007, 17:08 +0100 schrieb Lars Trieloff:
In Sling, we already have a concept of delegation. This means, a
resource delegates the rendering of the children to the children's
scripts by calling
Sling.include
Hi Lars,
On 10/30/07, Lars Trieloff <[EMAIL PROTECTED]> wrote:
> ...Thinking of XSLT, this is similar to ...
hehe, you obviously found the right analogy to get my attention ;-)
> ...My proposal would be to add
>
> Sling.handle()
> Sling.handle(type)
> Sling.handle(type, selector)..
As Felix in
Hi,
Am Dienstag, den 30.10.2007, 17:08 +0100 schrieb Lars Trieloff:
> In Sling, we already have a concept of delegation. This means, a
> resource delegates the rendering of the children to the children's
> scripts by calling
>
> Sling.include(path)
This is only one side of the medal. The oth
Hi Betrand,
this is what we want:
...I still think having a
level of inheriance and aspect-orientation in rendering is something
we want, because it eases the development process
I agree that this might be useful in some cases - but do you think we
can achieve this efficiently and simply
On 10/30/07, Lars Trieloff <[EMAIL PROTECTED]> wrote:
> ...I still think having a
> level of inheriance and aspect-orientation in rendering is something
> we want, because it eases the development process
I agree that this might be useful in some cases - but do you think we
can achieve this e
Hi Felix,
The first candidate is the path denoted by slingResouceType. If this
is not set, we resort to the primaryNode type.
In fact, this is overkill as the slingResourceType is intended to be
either set from a property or the primary node type if there is no
such
property. So just checki
Hi Lars,
Thanks for elaborating and also the nice illustration, it helps alot.
Am Montag, den 29.10.2007, 11:25 +0100 schrieb Lars Trieloff:
> For script resolution, we create a weighted list of candidate paths.
> As soon as a script is found in a candidate path, we start looking for
> refine
hi lars,
thanks a lot for the illustration. i think this is a great
approach. i would like to ask a couple of detailed questions
though.
> If two nodes in the graph have the same distance to the primaryType,
> following rules are applied:
> 1) nt:base has precedence over nt:unstructured
really? m
Hi Felix,
What I would like to work out is how an intelligent script resolution
could work that allows multiple levels of fallbacks and that supports
mixin types.
Cool, would be very interested in such an approach.
Out of my head, here is how I would do it (for an illustration, see http://we
Am Freitag, den 26.10.2007, 14:45 +0200 schrieb Bertrand Delacretaz:
> On 10/26/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
>
> > ...If we then have a mechanism to detect a specific ScriptEngine, I could
> > implement my use case by looking up the ScriptEngine I want (as I know I
> > want the
On 10/26/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> ...this comes down to the question of whether you need script
> resolution for these use cases or not
Even having search paths is a kind of "resolution", so I think that makes sense.
-Bertrand
Bertrand Delacretaz wrote:
> On 10/26/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
>
>> ...If we then have a mechanism to detect a specific ScriptEngine, I could
>> implement my use case by looking up the ScriptEngine I want (as I know I
>> want the javascript or the jruby or whatever script en
On 10/26/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> ...If we then have a mechanism to detect a specific ScriptEngine, I could
> implement my use case by looking up the ScriptEngine I want (as I know I
> want the javascript or the jruby or whatever script engine),
> instantiating a script ob
Felix Meschberger schrieb:
> Hi,
>
> Am Freitag, den 26.10.2007, 11:39 +0200 schrieb Carsten Ziegeler:
>> The proposed SlingScriptResolver is currenly only able to resolve a
>> script based on the current sling request.
>>
>> I think it makes sense to be able to resolve a script based on a path.
>
Hi,
Am Freitag, den 26.10.2007, 11:39 +0200 schrieb Carsten Ziegeler:
> The proposed SlingScriptResolver is currenly only able to resolve a
> script based on the current sling request.
>
> I think it makes sense to be able to resolve a script based on a path.
> A possible use case for this is to
Hi,
Am Freitag, den 26.10.2007, 12:44 +0200 schrieb Lars Trieloff:
> Hi,
> I think the script resolver should resolve scripts based primarily on
> the content. This means based on the sling-content type, the Jcr
> content type, including mixin types and only secondarily based on
> attributes
Hi,
I think the script resolver should resolve scripts based primarily on
the content. This means based on the sling-content type, the Jcr
content type, including mixin types and only secondarily based on
attributes of the request like selectors.
What I would like to work out is how an int
The proposed SlingScriptResolver is currenly only able to resolve a
script based on the current sling request.
I think it makes sense to be able to resolve a script based on a path.
A possible use case for this is to invoke some helper scripts during
request processing, for example if I want to ca
22 matches
Mail list logo
