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

2007-12-29:

[0:33] <flinja> In production, if you want to serve different domains on the same server, would that be done with differerent instances of the Helma server?
[6:38] <flinja> I'm doing the tutorial, getting "Error retrieving NodeIDs". Checked the DB connection a few times.
[6:50] <flinja> Cool, I got it.
[7:39] <zumbrunn> flinja, re: serving different domains on the same server...
[7:39] <flinja> yeah...
[7:40] <zumbrunn> usually, you would put apache in front, and use mod_proxy to redirect the requests to helma/jetty
[7:40] <zumbrunn> that way you can map the domains to the appropriate helma apps, or whatever
[7:41] <flinja> ok, cool
[7:41] <zumbrunn> no need for separate helma servers
[7:41] <flinja> ok
[16:25] <flinja> Is there a special way to throw 404 pages, or do just use setHeader?
[16:28] <zumbrunn> I would think so, yes
[16:28] <zumbrunn> just setting the header accordingly
[16:28] <zumbrunn> but I have the habit of never throwing a 404 and instead redirecting to something that exists
[16:29] <flinja> like setHeader("404", "Not Fount")?
[16:36] <zumbrunn> I doubt that's the right syntax for the name, value pairs ...and it's res.setHeader(...) of course
[16:36] <zumbrunn> not sure, since I'm not doing it myself
[16:36] <zumbrunn> trying to think where there might be an example of this...
[16:37] <zumbrunn> "404" is a header value itself, or not? Not a header name.
[16:38] <flinja> I think you are right. I'm looking at that, too.
[16:39] <flinja> Is "res" the default or global instance of the helma.Http()?
[16:40] <zumbrunn> helma.Http is not really directly related to the built-in response object at all
[16:41] <zumbrunn> req and res are the built-in ways of handling incoming requests in a helma app
[16:41] <zumbrunn> helma.Http is for making outgoing requests from the helma app environment
[16:42] <flinja> Oh, ok
[16:42] <flinja> Like a remote post?
[16:42] <zumbrunn> yes
[16:43] <zumbrunn> an optional alternative to the built-in global getUrl() function
[16:45] <flinja> ok
[16:53] <zumbrunn> res.status = 404;
[16:53] <zumbrunn> that's what you are looking for, I think
[16:55] <zumbrunn> you can also get direct access to the response header using res.servletResponse()
[16:55] <zumbrunn> http://helma.zumbrunn.net/reference/res.html#res.servletResponse
[16:55] <zumbrunn> http://helma.zumbrunn.net/reference/res.html#res.status
[16:55] <flinja> nice, thanks zumbrunn
[16:56] <flinja> that is what i was looking for
[18:09] <flinja> I was looking for an example of user authentications (sessions). Anyone know any examples for setting up for admin-area?
[18:11] <zumbrunn> not sure what you are looking for...
[18:11] <zumbrunn> can you elaborate
[18:11] <zumbrunn> ?
[18:12] <flinja> yes, if I wanted to build an app that had an admin area, I would want make access to that portion pw protected. That's what I'm curious about, authentication+sessions.
[18:13] <zumbrunn> do you want to use a web based form?
[18:13] <zumbrunn> or basic http auth?
[18:13] <flinja> web based form.
[18:14] <zumbrunn> are you aware how you would handle the login part?
[18:14] <zumbrunn> so that you have session.user associated with a user in your app?
[18:16] <flinja> I would post to a form that would validate, and set the session.user to the person who is logged in?
[18:16] <zumbrunn> nope, take a look at app.registerUser(username, password) and session.login(user, password)
[18:17] <zumbrunn> http://helma.zumbrunn.net/reference/app.html#app.registerUser
[18:17] <zumbrunn> http://helma.zumbrunn.net/reference/session.html#session.login
[18:17] <flinja> awesome, thanks!
[19:02] <flinja> Is there a way to have a file (.hac or .js) speficfy application-wide functions and or variables?
[19:25] <zumbrunn> flinja... hmm...
[19:26] <zumbrunn> aren't they application wide by default?
[19:26] <zumbrunn> what do you mean?
[19:27] <zumbrunn> is the problem that global vars get purged after each request?
[19:28] <zumbrunn> then use app.data properties or defineLibraryScope()
[19:28] <zumbrunn> http://helma.zumbrunn.net/reference/app.html#app.data
[19:28] <zumbrunn> http://helma.zumbrunn.net/reference/global.html#defineLibraryScope
[19:31] <zumbrunn> also, read the description for "global":
[19:31] <zumbrunn> http://helma.zumbrunn.net/reference/global.html#global.global
[19:33] <zumbrunn> (actually, I'm curious to hear whether that description is comprehensible to a newbie, as I just wrote it recently)
[20:44] <flinja> np, I'll take a look in couple of hours. Thanks for response, sorry I wasn't at my computer to read it over sooner.
[22:26] <flinja> I think global is what I'm looking for, but I'm still trying to understand how it is used. So, I naturally, I can asign any arbitrary JS object to a variable and us it, correct?
[22:27] <flinja> Taking the tutorial app as an example, let's say I want to use an identical function/object/whatever in both /Root/main.hac and /Person/edit.hac without manually writing the entire function or object out in both files.
[22:28] <flinja> That's what I mean :-P
[22:31] <flinja> So I need to extend the global object, right?
[22:48] <flinja> I think I got the effect I wanted. I added a "Code" directory to the app with a test.js file with "global.testFunc = function() {}". I then added "" to the apps.properties file and restarted the app. I can know reference the function via "global.testFunc()" without errors. Is this the best, or even a reccomended way, of doing this?
[23:06] <zumbrunn> flinja, what did you add to the apps.properties file? "", an empty string?
[23:06] <zumbrunn> for the way you defined and used the testFunc, you wouldn't need the "global." prefix
[23:06] <zumbrunn> but anyway, I don't think it's the approach you are looking for
[23:07] <flinja> Nothing, I didn't add that, but I'm actaully trying it now, and I think apps.properties(foo) is what I want afterall.
[23:07] <zumbrunn> you can use prototype inheritance to achieve this
[23:07] <flinja> Oh? I saw the documentation on that, but I was still a little confused.
[23:08] <zumbrunn> just reading again your description of what you wanted to do...
[23:10] <zumbrunn> ok, if you want to just reuse a function then defining it as a global function makes sense
[23:10] <zumbrunn> you would do this by placing it in a js file inside a directory called "Global" inside your app's code repository
[23:11] <zumbrunn> how do you have the app configured in your apps.properties now?
[23:12] <flinja> yes I do
[23:13] <zumbrunn> how is it currently configured
[23:13] <zumbrunn> ?
[23:13] <zumbrunn> (maybe you want to just put what you have into the pastebin)
[23:13] <zumbrunn> http://helma.pastebin.com/
[23:14] <flinja> Yea, I would, but its down and it's only two lines: line 1 - addressbook
[23:14] <flinja> line 2 - addressbook.appdir = apps/addresbook/
[23:14] <zumbrunn> lol, yep, it's down
[23:15] <flinja> Anyway, I tried adding the function to a file in the Global dir, and of course it works.
[23:15] <zumbrunn> ok, so you could that function into a file called apps/addresbook/Global/foo.js for example
[23:15] <zumbrunn> ok
[23:15] <flinja> BTW, is there an advantage to the prototypal way of getting that effect?
[23:16] <zumbrunn> not in that particular situation
[23:16] <zumbrunn> I misread your intention the first time I read it
[23:17] <flinja> Cool. Another question: the libraries documented at helma.zumbrunn.net look awesome and offer a lot, but it is possible to use additional JS codebases too, like Mootools, Mochikit, jquery?
[23:17] <flinja> in addition?
[23:18] <zumbrunn> most client-side libs main purpose are to interact with the browser dom
[23:18] <flinja> thats true
[23:18] <zumbrunn> which you don't have on the server-side
[23:19] <zumbrunn> so they are not that useful, unless you simulate the browser dom on the server-side
[23:19] <flinja> true true, but there is datejs.com, too.
[23:19] <zumbrunn> but bits from them can certainly be useful
[23:20] <zumbrunn> and whatever is useful could be a candidate for inclusion in the helma libs
[23:20] <zumbrunn> looking at datejs.com now...
[23:20] <flinja> Yea. I use jquery a lot, but its applications beyond the DOM and into th server side may be limited. It's a great library, but its built for the browser.
[23:21] <zumbrunn> yep, I use jquery as well
[23:23] <zumbrunn> http://grazia.helma.org/pipermail/helma-user/2007-July/007070.html
[23:26] <flinja> Oh, crazy, wow. Thanks for the link.
[23:28] <zumbrunn> at first glance it looks like date.js would just work if you drop it into your helma app's Global dir
[23:28] <zumbrunn> (haven't tried it, though)
[23:29] <flinja> Ok.
[23:32] <flinja> Helma really lets you use Java's libraries without knowing Java?
[23:32] <zumbrunn> as long as you know their api, yes
[23:32] <flinja> like its methods, properties, etc?
[23:33] <zumbrunn> yes, that's what I mean
[23:33] <flinja> That is crazy cool.
[23:35] <flinja> Ok, so I don't know how Java works, but going from the instructions on installing the MySQL connector, you just add the library's jar file to the lib/ext directory?
[23:35] <zumbrunn> yes
[23:36] <zumbrunn> http://helma.zumbrunn.net/intro/javapackages
[23:36] <flinja> thanks.
[23:38] <flinja> Zumbrunn: I think I know the answer to this, but in production, apache would still generate its own log files? I was just looking at my helma installations's logs, which are helpfull, but also don't provide *all* the same details of apache logs.
[23:40] <zumbrunn> right, correct
[23:40] <flinja> cool

 

 

In the channel now:

Logs by date: