Hopbot log for 2007-08-02 - Helma IRC channel: #helma on irc.freenode.net

2007-08-02:

[0:39] <rjb> is the unparsed query string available in the req object?
[1:27] <rjb> var queryString = req.getServletRequest().getQueryString() || "";
[1:27] <rjb> solves my question
[20:04] <rjb> does helma support path_info?
[20:04] <jsp> ?
[20:05] <rjb> huh?
[20:06] <jsp> what's path_info?
[20:06] <jsp> /myaction, but accessed via /myaction/and/more/stuff ?
[20:07] <rjb> right
[20:07] <rjb> http://hoohoo.ncsa.uiuc.edu/cgi/env.html
[20:07] <rjb> PATH_INFO
[20:07] <jsp> lol--I'm looking at it
[20:08] <zumbrunn> http://helma.org/bugs/show_bug.cgi?id=522 ?
[20:08] <jsp> you could fake something up with getChildElement
[20:09] <jsp> not that, Chris
[20:09] <zumbrunn> and req.getServletRequest().getQueryString() doesn't do the trick either?
[20:10] <rjb> http_get_remainder
[20:10] <rjb> res.data.http_get_remainder actually
[20:10] <rjb> is good enough
[20:10] <zumbrunn> that's what I thought
[20:10] <rjb> (i think)
[20:10] <jsp> for the path_info, or in place of the req.getServletRequest().getQueryString() ?
[20:11] <zumbrunn> just to be able to get at the stuff behind the action that was resolved
[20:13] <zumbrunn> but I'm not sure if it does the trick
[20:13] <jsp> isn't Helma going to try to turn /a/b/c into root.a.b.c_action or root.a.b.c.main_action ?
[20:13] <jsp> I thought the problem was with stopping at root.a and letting it handle interpretting the rest
[20:13] <zumbrunn> I don't expect it to, because /myaction/and/more/stuff doesn't resolve to /myaction
[20:13] <zumbrunn> it gives a 404
[20:14] <zumbrunn> depends on what rjb is looking for
[20:14] <jsp> right. that's what I'm saying. you'd have to fake something with getChildElement and transient HopObjects
[20:15] <jsp> as in http://helma.org/docs/examples/getChildElement/
[20:15] <rjb> hmm
[20:15] <jsp> which isn't bad, really
[20:15] <rjb> ok, so the answer is basicaly D.I.Y.
[20:15] <jsp> yeah
[20:16] <jsp> afaik
[20:18] <zumbrunn> depends on what you want and there is probably more than one way to D.I.Y.
[20:19] <rjb> there always is
[20:23] <rjb> well too bad, it would seem to make sense that if in the path /a/b/c b can be resolved to a function root.a.b_action, then that is run to service the request
[20:23] <rjb> instead of returning a 404
[20:23] <rjb> but maybe i'm wring
[20:23] <rjb> wrong even
[20:24] <zumbrunn> nothing stops you from implementing that
[20:25] <zumbrunn> you have the handlers
[20:25] <jsp> yeah, I think it could be done generically without a lot of trouble
[20:25] <zumbrunn> notfound_action, error_action, onRequest handler and getChildElement come to mind
[20:26] <zumbrunn> (although "not found" currently always resolves to the Root prototype)
[20:27] <jsp> I don't think I would want that as the default behavior, 'cause then unaware pages automatically have an infinite number of addresses. E.g. /about can also be /about/if/I/link/to/enough/of/these/on/your/site/I/might/get/Google/to/penalize/you/for/duplicate/content/ and /about/our/white/supremacist/policies or something else offensive
[20:29] <zumbrunn> I meant, 404 always resolves to the notfound action of the Root prototype
[20:29] <jsp> right--not what you said, Chris.
[20:29] <zumbrunn> ok :-)
[20:30] <jsp> I mean re: "it would seem to make sense that if in the path /a/b/c b can be resolved to a function root.a.b_action, then that is run to service the request"
[20:31] <rjb> well i thought that is the default in most servers
[20:32] <rjb> if b is a file or script the server knows to run, that is used to service the request and the remainder is passed as PATH_INFO
[20:32] <rjb> but jsp has a valid objection here
[20:33] <rjb> (one nobody would have thought of 5 or more years ago, but hey)
[20:33] <jsp> that may be true of cgi scripts by default (though I'm not sure), but I'm pretty sure it is not true by default of static content, which used to be much more common than scripts and more sharply distinguished
[20:34] <jsp> in helma, everythings a script
[20:35] <jsp> (fyi, apache docs say cgi-script and isapi-handler accept path_info requests by default but normal files do not http://httpd.apache.org/docs/2.2/mod/core.html#acceptpathinfo)
[20:49] <rjb> yeah static files usually don't, right
[20:52] <rjb> path_info is just a cheap way to have "friendly" urls
[20:53] <jsp> *nods* I had implemented it in my PHP framework without knowing the name of it.
[20:54] <rjb> except that when you need to implement it by yourself, it's no longer quite as cheap;)
[21:12] <jsp> zumbrunn, I'm pretty sure e4x provides some kind of iteration construct for going through XMLList's, but I don't know it. do you? (standard for loops work, but I don't like for loops)
[21:16] <rjb> actually, what is the scope the code in Global/*.js is evaluated in?
[21:17] <jsp> seems to be application scope
[21:17] <rjb> this == app ?
[21:18] <jsp> dunno. I never tried using this
[21:19] <jsp> my guess is, no. this == nothing or this == root, I think
[21:20] <jsp> in helma, root, iirc, is the root object which JavaScript spec says must exist but doesn't define. In the browser it's window
[21:24] <rjb> hmm no that wasn't the right question to ask
[21:26] <rjb> i'd like to extend the req object with a queryString property, for later convenience
[21:26] <rjb> but it seems i can't do that in javascript, or am i wrong?
[21:28] <jsp> it'd be a dynamic property, so you'd need to have req.prototype.getQueryString = function(){} or req.prototype.__defineGetter__('queryString',function(){});
[21:28] <jsp> but either of those should work
[21:29] <rjb> too bad req.prototype is undefined
[21:29] <jsp> then try just req.
[21:29] <jsp> dunno if it will persist, but it's worth a shot
[21:31] <jsp> (the java objects that Helma brings into JavaScript land behave like true JS objects in varying degrees)
[21:32] <jsp> (the limitation is of the Java stuff here, not JavaScript. Not that that helps you any.)
[21:44] <rjb> i assume there
[21:44] <rjb> 's a fresh instance of req created for every request
[21:45] <jsp> one would think
[21:45] <rjb> but the code in Global/ probably gets re-executed only when it changes
[21:45] <jsp> probably. so put it in Global.onRequest
[21:50] <rjb> another doc bug:
[21:50] <rjb> in the description of app.log(), the example shows a call of app.debug() instead
[22:07] <rjb> nope, neither adding a queryString property, nor a getQueryString() method to req in onRequest() seem to work properly
[22:10] <rjb> when a macro then refers to req.queryString, it finds it's null
[22:15] <rjb> it may be that onRequest() is called to early, or something
[22:19] <jsp> or maybe req doesn't do expando
[22:22] <rjb> bummer, there seem to be no function to urlencode a string
[22:23] <jsp> it's built into javascript
[22:24] <jsp> escape() is a toplevel function
[22:27] <rjb> duh, indeed
[22:39] <jsp> re: onRequest
[22:40] <jsp> Global.onRequest doesn't seem to get called at all, and trying to set a new property on req yields: Java class "helma.framework.RequestBean" has no public instance field or method named "bob".
[22:42] <rjb> so much for that
[23:07] <zumbrunn> rjb, the scope of the code in Global/* is the global scope
[23:07] <zumbrunn> not app or root
[23:07] <zumbrunn> just "this"
[23:07] <zumbrunn> or "global"
[23:15] <jsp> (I just noticed that a bit ago, too)
[23:16] <zumbrunn> jsp, e4x offers "for each" in addition to "for"
[23:17] <zumbrunn> but I don't know of a way to could iterate without one of these for constructs
[23:18] <zumbrunn> and you can't extend the XML prototype since it isn't a real Javascript prototype either
[23:23] <zumbrunn> the docs might be wrong about global.onRequest
[23:24] <zumbrunn> setting an onRequest handler in the HopObject prototype really would have the same effect anyway
[23:24] <zumbrunn> you *can* set req.data.* properties
[23:30] <zumbrunn> (not for what rjb wanted to do, though... like you said, the req object is fresh for every request and wouldn't keep a custom property anyway)
[23:41] <jsp> I thought there was a for each--what's the syntax? (I love my lambda, but if I can iterate without a counter variable, that's better than for)
[23:42] <jsp> onRequest on HopObject will break if you setup onRequest on other specific types
[23:42] <jsp> (and now I'm afk again)

 

 

In the channel now:

Logs by date: