initialize and the HTTP Interface

0 views
Skip to first unread message

Gabriel Birke

unread,
Nov 3, 2009, 6:13:40 AM11/3/09
to Persevere
Hello,

is it possible to read the values of the JSON that was posted via HTTP
inside the initialize function? I would like to generate some
additional properties for my class, depeding on the properties that
were posted. The parameters of the initialize function are empty when
using the HTTP interface.

Greetings,m

Gabriel

Dean Landolt

unread,
Nov 3, 2009, 10:04:46 AM11/3/09
to persevere...@googlegroups.com

"request" as a free variable should be available to you -- it's just a servlet request [1] so using that interface you should be able to get at pretty much everything you need.

[1] http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/http/HttpServletRequest.html

Sean Garner

unread,
Nov 3, 2009, 10:07:24 AM11/3/09
to persevere...@googlegroups.com
Doesn't the `this` reserved word also contain the object.  Initialisation then work on top of those values.

Sean


2009/11/3 Dean Landolt <de...@deanlandolt.com>

Dean Landolt

unread,
Nov 3, 2009, 11:04:25 AM11/3/09
to persevere...@googlegroups.com
On Tue, Nov 3, 2009 at 11:07 AM, Sean Garner <seanl...@gmail.com> wrote:
Doesn't the `this` reserved word also contain the object.  Initialisation then work on top of those values.

As I understand it, Gabriel wants to pass additional params via http (presumably via the querystring or headers). The `this` object will only have what was supplied as the object, so he'd need to drop down to the http level (via request, or via JSGI middleware) to get at the request.

Also note that (per my other email regarding coreApp) while I think using middleware is the Right Thing here, there's currently no way to alter an inbound request via middleware, only intercept it and do things programmatically. Persevere's core uses the data in the servlet request and ignores JSGI environment, so altering it does nothing for you. I'm investigating ways to hack persevere to use the supplied JSGI environment to bypass this problem. If and when that happens, Gabriel's request would be simple, and would happen before initialize is ever called. I think it's cleaner to keep all my http contextual stuff separate from core behavior (to avoid fluky effects when doing things without a request context, like from the console).


Sean Garner

unread,
Nov 3, 2009, 6:58:10 PM11/3/09
to persevere...@googlegroups.com
I interpreted "read the values of the JSON that was posted" as the initialisation of the object and not HTTP headers.  Apologies if I'm wrong.

One thing you wrote that's tweaked my interested though, I don't have any experience except as using Persevere from the browser (dojo specifically) but doesn't the initialize constructor also work when called from the console?  I've possibly misunderstood because almost everything else you said went over my head :)

Dean Landolt

unread,
Nov 3, 2009, 7:46:54 PM11/3/09
to persevere...@googlegroups.com
On Tue, Nov 3, 2009 at 6:58 PM, Sean Garner <seanl...@gmail.com> wrote:
I interpreted "read the values of the JSON that was posted" as the initialisation of the object and not HTTP headers.  Apologies if I'm wrong.

One thing you wrote that's tweaked my interested though, I don't have any experience except as using Persevere from the browser (dojo specifically) but doesn't the initialize constructor also work when called from the console?  I've possibly misunderstood because almost everything else you said went over my head :)

Sorry about that -- I should have been more clear. Yes, the constructor also works when called from the console -- that's the beauty of it. So if you're tacking on dependencies on some request context (that wouldn't exist) you're mucking up that elegance. I was just arguing that stuff related to the http request should be handled before initialize so that there's not a bunch of special-case request handling in initialize.

Gabriel Birke

unread,
Nov 3, 2009, 12:36:56 PM11/3/09
to Persevere
On 3 Nov., 16:07, Sean Garner <seanlgar...@gmail.com> wrote:
> Doesn't the `this` reserved word also contain the object. Initialisation
> then work on top of those values.

What I meant was the following functionality:

Class{id:'MyClass',
prototype: {
initialize:function(obj) {
if(obj.line) {
var parsedLine = MyExternalLibrary.parse(obj.line);
for(var prop in parsedLine) {
this[prop] = parsedLine[prop];
}
}
}
},
properties: {
// Some properties here ...
},
methods: {
}
});

Now I POST the JSON object {line:'Some external data to be parsed'} to
http://myserver/MyClass

The initialize method is called during the process of this POST
request, but I want to access the line property of the JSON object
that got posted. The "obj" parameters of "initialize" is undefined
when I use the HTTP interface. This came as a surprise to me, because
instantianting from the JS command line with exactly the same JSOn
object worked. "this.line" is also empty, so it seems that when
"initialize" is called, the data from the request has not been set and
is not given as the function parameter.

Is this by design and if yes, what are the reasons for the design?

I have now circumvented the problem by using the "onSave" prototype
function. Maybe you can add some more clarification to the
documentation in which order data is set.

Thanks to all for your replies.

Dean Landolt

unread,
Nov 3, 2009, 10:16:00 PM11/3/09
to persevere...@googlegroups.com

Hmm. I assumed exactly what you did, and so jumped to an incorrect conclusion. I should have tested it first, but I could swear I've done something similar in the past. I'll poke around a bit and see if there's something I'm forgetting.


Reply all
Reply to author
Forward
0 new messages