Hi Lars,
Am Freitag, den 21.12.2007, 16:26 +0100 schrieb Lars Trieloff:
> A typical servlet filter has following structure:
>
> - do something with the request
> - call doFilter(request, response);
> - do something with the response
I fear this does not work The request object has no setters
Hi Lars,
Am Freitag, den 21.12.2007, 16:29 +0100 schrieb Lars Trieloff:
> Hi Felix,
>
> I've been thinking about this, but do not see a solution right now.
> The problem with the approach of executing the script with permissions
> of the script owner (whoever this might be) is that in order t
Alex,
I can understand both sides of the discussion because both are needed.
> It just depends on the user's or customer's requirements.
>
>
I agree. Maybe it'd be good if we treated scripting and Java development as
equal citizens, i.e. if we tried to make available all features to both
approach
Hi Felix,
I've been thinking about this, but do not see a solution right now.
The problem with the approach of executing the script with permissions
of the script owner (whoever this might be) is that in order to be
able to observe the whole repository, we have to give read access to
the
A typical servlet filter has following structure:
- do something with the request
- call doFilter(request, response);
- do something with the response
In most of these filters only the request or the response is modified.
With the separation of request.js and response.js I eliminate the
nece
Hi Michael,
Am 21.12.2007 um 14:58 schrieb Michael Marth:
Regarding the sentiment that scripted web apps are "for beginners",
do not
support a structured deployment or development process and do not
perform
well: yes, it is true that compiled code runs 1000x faster than
interpreted
code
Hi Lars,
Sounds simple and usefull.
Just one question: What is the difference betwen the Request filter and
the Response filter ?
And a clarification the script must/may wrap the request and response
objects to inject new data, or do you think that only parameters would
be "overwritten" ?
Regar
Lars,
good suggestion IMO.
re the resource filter scripts:
If the filter scripts reside in a different location than render scripts
anyway, why not apply the same naming schema as for render scripts? (
html.esp, POST.esp, etc)
re the default:
can we just call it "default.esp"?
Michael
--
Michae
Guys,
just like Lars I find that having "everything" scriptable is very desirable.
"Everything" meaning in descending order of importance: render scripts,
filters, event listeners. Building a web app where I start with some render
scripts in Javascript but have to revert to Java for writing a filt
Here is my proposal for scriptable filtering:
== Goal ==
We want to allow users with limited knowledge and interest in OSGi,
Maven and Java to create filters in a similar fashion to creating
scripts for request handling.
== Current Situation ==
Filters are OSGI components, implementing the
Hi Alex,
It will be a great overall feature of Sling to support both
"programming" styles. The only thing missing in the current state is
support for an easy transition from your prototypical script-based
application to a mainly servlet-based and bundled app. There is the
idea to automati
Hi,
Am 21.12.2007 um 12:46 schrieb Lars Trieloff:
Right. But this realization should come from the user, not from the
framework that says for this certain feature, you have to forget
everything you learned about scripting and start using an IDE, Maven
and OSGi, even if you just want to imp
Hi Lars,
Am Freitag, den 21.12.2007, 14:02 +0100 schrieb Lars Trieloff:
> Hi Felix,
>
> I think, we should protect the ability to install scripts or event
> listeners, not limit the power of scripts or event listeners. You
> could rephrase this example: Suppose somebody installs a GET.js scri
Hi Felix,
I think, we should protect the ability to install scripts or event
listeners, not limit the power of scripts or event listeners. You
could rephrase this example: Suppose somebody installs a GET.js script
with bad-side effects and tricks the administrator or power-user into
reque
Hi Lars,
Am Freitag, den 21.12.2007, 13:35 +0100 schrieb Lars Trieloff:
> >> The event is executed with the credentials of Event.getUserId().
> >
> > First it might not work. Of course, given the admin session, you might
> > create a session of the desired user. Second, and more important: the
> >
Hi Felix,
The event is executed with the credentials of Event.getUserId().
First it might not work. Of course, given the admin session, you might
create a session of the desired user. Second, and more important: the
Event.getUserId is the user name of the session which performed the
changes
Hi Lars,
Am Freitag, den 21.12.2007, 12:46 +0100 schrieb Lars Trieloff:
> > request-level or resource-level filters.
> >
> > The problem with filtering is, that it imposes certain performance
> > degradation. So if you (or Michael) would be able to present a
> > conceptor
> > even a patch, we ma
Hi Felix,
- request handling
- error handling
We have both, right ?
Right. And this is great.
- request filtering
- response filtering
There is no difference in request and response filter - there is just
filtering. Currently we implement this by requiring the registration
of
request-
Hi Lars,
Am Freitag, den 21.12.2007, 11:51 +0100 schrieb Lars Trieloff:
> Hi Michael, Felix,
>
> I think what Michael needs when he refers to Microsling is a
> scriptable Sling. This means that all the core aspects of Sling:
>
> - request handling
> - error handling
We have both, right ?
> -
Hi,
On Dec 20, 2007 4:27 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, den 20.12.2007, 09:47 +0200 schrieb Jukka Zitting:
> > PPS. For special circumstances (e.g. GSoC students, temporary
> > cross-project integration, etc.) it is good to reserve the option of
> > granting some
Hi Michael, Felix,
I think what Michael needs when he refers to Microsling is a
scriptable Sling. This means that all the core aspects of Sling:
- request handling
- error handling
- request filtering
- response filtering
- repository events
- timed events (cron jobs)
are scriptable. I think
Hi Michael,
Am Donnerstag, den 20.12.2007, 17:07 +0100 schrieb Michael Marth:
> at the moment one can only use the microjax post servlet in an
> all-or-nothing way. This means that my app needs to decide: I either send
> POSTs to the microjax servlet and that's all there is. Or I implement
> POST.
Hi Michael,
Am Donnerstag, den 20.12.2007, 16:59 +0100 schrieb Michael Marth:
> you might have lost me in this discussion, but may I ask anyway:
Hm, I thought it would be clear from my description :-)
> We now have three orthogonal pieces in resolving a script: http method,
> requested mime type
23 matches
Mail list logo
