hi, is it possible to stop the processing of a request within the code, like res.abort and res.redirect do, but without their 'sideeffects'? i.e. i neither want to lose data changes, nor do i want to perform a redirect. i just want to stop the processing of the request, and return whatever i have written into the response-buffer to the client. michi
hi hannes, we talked about this a while ago, but i missed to take notes back then. maybe you can provide me the answer here on the list again. the plan is to implement paul's skin debugging feature (which he provided a patch for helma some time ago) directly in javascript, by defining a renderSkin, resp renderSkinAsString-method in JS, which mainly calls Helma's internal renderSkin-method. so, how do i call Helma's internal renderSkin-method in a HopObject method named 'renderSkin'? greets, michi
On Jan 3, 2007, at 4:53 PM, Michael Platzer wrote: > hi hannes, > we talked about this a while ago, but i missed to take notes back > then. > maybe you can provide me the answer here on the list again. > the plan is to implement paul's skin debugging feature (which he > provided a patch for helma some time ago) directly in javascript, by > defining a renderSkin, resp renderSkinAsString-method in JS, which > mainly calls Helma's internal renderSkin-method. > so, how do i call Helma's internal renderSkin-method in a HopObject > method named 'renderSkin'? quoting a mail from August 2006: >>maybe it would be useful to be able to access the original functions _in >>any case_ as __href__ &c.? >Should be easy to do this yourself: > >if (!HopObject.prototype.__href__) > HopObject.prototype.__href__ = HopObject.prototype.href; - stefan
Hi
Is it possible to access the param-object I pass to a skin when
calling renderSkin from a Macro contained in this skin?
I'm rendering a skin like this:
valuesIterator.next().renderSkin( "inEditResourcesList",
{ propertyInstanceUuid : this.getUuidString() } );
and the skin contains again something like this:
<% this.skin name="edit_ajax" dontAddIdPrefix="true" %>
and I'd like to access "param.propertyInstanceUuid" in
"edit_ajax.skin" and would therefore need to be able to hand it over
in "skin_macro"
- stefan
Hi Michi, The (only) way to do this is to return from the main action. IMO adding the feature you request would have negative impact on coding style. hannes 2007/1/3, Michael Platzer <michael.platzer <at> knallgrau.at>: > hi, > > is it possible to stop the processing of a request within the code, like > res.abort and res.redirect do, but without their 'sideeffects'? i.e. i > neither want to lose data changes, nor do i want to perform a redirect. > i just want to stop the processing of the request, and return whatever i > have written into the response-buffer to the client. > > michi > _______________________________________________ > Helma-user mailing list > Helma-user <at> helma.org > http://helma.org/mailman/listinfo/helma-user >
2007/1/8, Stefan Rinner <rist <at> mac.com>: > > Is it possible to access the param-object I pass to a skin when > calling renderSkin from a Macro contained in this skin? Currently, the skin parameter can only be accessed using the <% param.xxx %> macro. I admit this is a shortcoming. If anybody comes up with a way to fix this which doesn't compromise backwards compatibilty, I'll commit it to cvs head. hannes
2007/1/3, Stefan Rinner <rist <at> mac.com>: > > quoting a mail from August 2006: > > >>maybe it would be useful to be able to access the original > functions _in > >>any case_ as __href__ &c.? > > >Should be easy to do this yourself: > > > >if (!HopObject.prototype.__href__) > > HopObject.prototype.__href__ = HopObject.prototype.href; > This approach should also work for renderSkin() and consorts. Please let me know if it doesn't. hannes
> > Currently, the skin parameter can only be accessed using the <% > param.xxx %> macro. I admit this is a shortcoming. If anybody comes up > with a way to fix this which doesn't compromise backwards > compatibilty, I'll commit it to cvs head. One possible way to implement it would be to make the content of the param-object available via res.handlers.param - stefan
Hannes Wallnoefer schrieb: > The (only) way to do this is to return from the main action. IMO > adding the feature you request would have negative impact on coding > style. > I asked for this feature, since i want to implement a serverside caching mechanism, as i mentioned here [1]. I implement the logic, whether to return the response immediately from the cache or not in the onRequest-method. Because I then decided to choose a disk-based mechanism, I use res.forward(..), which has exactly the wanted side-effect of stopping the further processing of the request. So, in that respect I don't really need that feature anymore. But if a developer wants to implement a similar caching mechanism, but stores the response in memory (e.g. in app.data), then she would not have any method at hand to stop the further processing of the request. So, imo this feature still make sense. But, as I mentioned, I personally don't need it for now. thanks for the reply anyways, michi [1] http://helma.org/pipermail/helma-dev/2007-January/003233.html
2007/1/9, Michael Platzer <michael.platzer <at> knallgrau.at>: > Hannes Wallnoefer schrieb: > > The (only) way to do this is to return from the main action. IMO > > adding the feature you request would have negative impact on coding > > style. Ok, in the context of onRequest() this makes sense. (I was thinking inside the action.) > [1] http://helma.org/pipermail/helma-dev/2007-January/003233.html Haven't forgotten this, it's on my list. hannes
RSS Feed1 | |
|---|---|
2 | |
8 | |
1 | |
21 | |
31 | |
13 | |
16 | |
32 | |
27 | |
21 | |
39 | |
23 | |
34 | |
8 | |
16 | |
46 | |
69 | |
24 | |
57 | |
56 | |
56 | |
36 | |
35 | |
26 | |
25 | |
47 | |
25 | |
77 | |
6 | |
57 | |
69 | |
12 | |
76 | |
39 | |
124 | |
33 | |
53 | |
18 | |
32 | |
71 | |
21 | |
15 | |
47 | |
8 | |
19 | |
22 | |
5 | |
6 | |
12 | |
12 | |
28 | |
7 | |
2 | |
27 | |
39 | |
52 | |
33 | |
25 | |
45 | |
69 | |
16 | |
24 | |
58 | |
34 | |
90 | |
74 | |
47 | |
79 | |
77 | |
41 | |
51 | |
75 |
