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

2007-07-31:

[0:01] <rjb> i also have FotwItem/create.skin
[0:02] <rjb> so i probably must FotwItem.prototype.renderSkinAsString('create') or soomething
[0:03] <zumbrunn> no, that doesn't look right
[0:07] <rjb> it does work, though
[0:08] <zumbrunn> can't argue with that ;-)
[0:09] <zumbrunn> regarding the skin in the tutorial, you probably were referring to the html.skin
[0:09] <zumbrunn> that's a global skin, though
[0:09] <zumbrunn> so I think the tutorial is correct
[0:10] <zumbrunn> (but we definitely need more tutorials)
[0:13] <rjb> well you are right, sort of
[0:13] <rjb> http://helma.org/docs/tutorial/hopobject/
[0:14] <rjb> i'm referring to edit.skin
[0:14] <rjb> but in the example, it's HopObject/edit.skin
[0:15] <zumbrunn> yes, the edit skin is rendered with the this prefix, though
[0:15] <rjb> indeed
[0:16] <rjb> ok looks like i have a handle on that
[0:16] * zumbrunn goes to catch some sleep
[0:17] <rjb> too bad i could find no useful debugging info in the app's event log
[0:53] * rjb sleep();
[10:33] <rjb> is it outlined somewhere, how to do http basic auth in helma?
[11:05] <rjb> if (!req.data.authorization || !session.login(req.username, req.password))
[11:05] <rjb> {
[11:05] <rjb> res.status = 401;
[11:05] <rjb> res.write('Go away. You are not authorized to use this page.<br />');
[11:05] <rjb> return;
[11:05] <rjb> }
[11:05] <rjb> this placed at the top of the action's code seems to work
[11:06] <rjb> oh and also setting res.realm before that
[11:06] <rjb> but is it the 'right' way?
[11:21] <zumbrunn> rjb, not sure... you better ask on the mailing list
[11:22] <zumbrunn> personally, I wouldn't rely on session.login when using basic auth
[11:22] <rjb> why not?
[11:22] <zumbrunn> but that doesn't mean it's not right
[11:23] <rjb> and what other method would you use instead?
[11:23] <rjb> to check the user's credentials?
[11:23] <zumbrunn> I'm just not sure whether there is no side effect when combining the two approaches like that
[11:23] <zumbrunn> just roll my own
[11:24] <rjb> oh you mean that session.user gets set
[11:25] <rjb> that shouldn't matter to me atm
[11:25] <zumbrunn> I think you are right and your approach should work
[11:26] <zumbrunn> I just only used basic auth when I completely worked around the built in user stuff
[11:26] <rjb> ok
[11:27] <zumbrunn> I'm sure you would get more qualified replies on the mailing list
[11:27] <zumbrunn> I would ask there
[11:27] <rjb> you mean the built in stuff that works based on session support, and not www-authenticate
[11:27] <zumbrunn> yes
[11:27] <rjb> got you
[11:31] <rjb> *sigh* mailing lists are sooo 1990's ;-)
[11:42] <rjb> the #1 reason i wanted http basic was being too lazy to create a login form..
[13:11] <zumbrunn> rjb, lol - I think that backfired
[13:13] <rjb> huh?
[13:14] <zumbrunn> wanting to use http basic because you were too lazy to create a login form, I think backfired ;-)
[13:17] <rjb> well, i'd say that if it didn't work
[13:19] <zumbrunn> ok, all the better :-)
[13:20] <rjb> it's a perfectly valid solution imo, if all you want is to lock the casual user out of some finctionality
[13:20] <rjb> functionality even
[13:31] <jerakeen> I'm sure I've seen client-side JS tricks that display a normal-looking login form that actually does an HTTP auth properly. Then it falls back to displaying a normal login box if you have no JS.
[13:31] <jerakeen> http://www.peej.co.uk/articles/http-auth-with-html-forms.html # this sort of thing
[13:36] <rjb> nice gimmick
[13:37] <rjb> it would be neat to use http digest auth
[13:38] <rjb> but afaik browser support is defective (last i heard)
[13:40] <jerakeen> there are plenty of things that are _supposed_ to work, but recently I'm giving up on everything other than https. They're all too clever, therefore too cmoplicated, or badly supported.
[13:40] <jerakeen> I suppose you could use client-side JS to hash the password entered, and pass that as the basic auth password. You lose non-js fallback there, of course.
[13:40] <rjb> true, if you want real security, https is the only option
[13:41] <rjb> anyway, what's the point in secure authentication, if you send back the sensitive data in the clear anyway
[13:42] <jerakeen> right.
[13:47] <rjb> btw client side hashing is useless
[13:47] <rjb> all you achieve is the hash becoming effectively the password
[13:47] <rjb> and transmitted in the clear anyway
[13:49] <rjb> you could devise some challenge-response scheme though
[13:50] <rjb> (i.e. reproduce http digest with client-side scripting)
[14:05] <rjb> but i don't think that inability to style the auth dialog is the main reason http auth is so rarely used nowadays
[14:39] <rjb> http://www.peej.co.uk/articles/no-sessions.html is a pretty good one
[14:41] <jsp> food for thought: it's probably an order of magnitude more likely that your user has a spyware keylogger installed than that someone is sniffing their HTTP traffic for passwords.
[14:43] <rjb> very true
[14:50] <jsp> thus I do not worry about sending stuff in the clear except for financial stuff. at some point, though, I'll work up an extension to the Helma session thing that does a hashed challenge-response without interfering with the rest of the way I work, and then I'll use that
[15:02] <rjb> true, in many cases you're interested in protecting data on the server against unauthorized tampering, rather than in data confidentiality
[16:02] <jerakeen> client-side hashing isn't all bad. you could hash against a salt sent from the server.
[16:06] <jsp> yeah. that's pretty much what I meant
[16:07] <jsp> you just have to invalidate hashes so they can't be replayed
[16:08] <jerakeen> and it's an order of magnitude more likely that I'm being sniffed than I have a keylogger.
[16:09] <jsp> I'd say that both are extremely unlikely for me, but sniffing probably more likely. But I think for the average user my probability wild guess is truer. It depends on who's going to be logging in.
[16:44] <rjb> how easy (or hard) to produce an rss feed in helma?
[16:45] <zumbrunn> http://helma.zumbrunn.net/reference/jala/Rss20Writer.html
[16:51] <rjb> ummm
[16:51] <rjb> i find it rather painful to figure out usage based on these docs
[16:52] <rjb> totally devoid of usage examples as they are
[16:52] <zumbrunn> I haven't used it myself
[16:53] <jsp> if you're familiar with the XML of RSS, it would be easy to just put it in a loop with some e4x--but you don't have that in 1.5
[16:53] <jsp> (and I'm not familiar with the XML myself)
[16:54] <rjb> it's probably easier to dig up a template for an rss feed and fill it in
[16:54] <jsp> yeah (that's what I'd do with e4x)
[16:55] <rjb> whatever, renderSkin can do it fine
[16:55] <zumbrunn> gobi contains an example usage
[16:55] <zumbrunn> (assuming that it uses not it's own implementation)
[16:56] <jsp> yes--renderSkin should definitely do it, too. I meant that as an agreement on the fundamental approach, not pimping e4x (again)
[16:56] <zumbrunn> but, warning, it's GPL:
[16:56] <zumbrunn> http://adele.helma.org/source/viewcvs.cgi/gobi/code/Page/Page.js?rev=1.73&content-type=text/vnd.viewcvs-markup
[17:00] <rjb> 'k, thanks for looking it up for me
[17:01] <rjb> http://peter.michaux.ca/article/3001
[17:01] <jsp> what 'bout it?
[17:02] <jsp> it==michaux blog article
[17:05] <rjb> looks like there's a fad
[17:06] <rjb> nevermind, i guess you've seen it
[17:07] <jsp> yeah :-). Jetty latest seems to have some cool stuff for scaling so I hope Helma upgrades and makes use of it eventually. I actually forget what... I think it was for keeping connections open between browser and server COMET-style without killing the server.
[17:08] <zumbrunn> continuations, yes
[17:08] <zumbrunn> Helma 2 has the newer Jetty version
[17:09] <zumbrunn> Hannes explained once what keeps us from switching the Jetty version in Helma 1.x
[17:09] <zumbrunn> forgot what that was
[17:10] <jsp> I haven't had much chance to think out how that all would be useful, but I imagine it'd be good for something :-). Good on Helma 2, though I have to think of it as vaporware for my purposes.
[17:10] <zumbrunn> rjb, peter was in here the day after posting that on his blog: http://helma.zumbrunn.net/hopbot/2007-07-11
[17:13] <rjb> http://docs.zimki.com/
[17:14] <zumbrunn> zimki is just a hosted service, right?
[17:15] <zumbrunn> not an open source framework
[17:15] <jsp> yeah
[17:19] <rjb> there are hints of plans to release the software as open source
[17:19] <zumbrunn> rjb, for an example of the Rss20Writer usage:
[17:19] <zumbrunn> http://dev.orf.at/trac/jala/wiki/JalaModules/XmlWriter
[17:19] <zumbrunn> but I agree with jsp, e4x seems like the way to go
[17:19] <zumbrunn> why are you still on Helma 1.5?
[17:20] <zumbrunn> (there is no reason I can think of)
[17:20] <jsp> his jvm craps out with 1.6 and he's dragging his feet on upgrading
[17:20] <jsp> ;-)
[17:20] <zumbrunn> hmm
[17:21] <rjb> i'm on vacation, and currently spend most of my day with the kids;)
[17:22] <jsp> :-P ok, good reason. but installing JRE 6u2 on my AMD64 linux server took all of two minutes once I clued in that I need to run the installer as root.
[17:23] <jsp> (JRE-->JDK)
[17:26] <jsp> zimki seems to use an approach like doublec's and peter's but prettied-up and softcode-ified.
[17:27] <zumbrunn> which kind of approach do you mean?
[17:27] <jsp> define some javascript functions and then manually map them to urls.
[17:28] <jsp> zimki.publishPath('/', hello); looks like a pretty version of addServlet(s, "/", HelloWorldServlet);
[17:29] <rjb> hm would it be legal xhtml to minimize a textarea as <textarea />?
[17:29] <jsp> no
[17:29] <jsp> and even if it were, it breaks all browsers
[17:30] <jsp> it's a problem with using e4x and any other xml-oriented thing for generating html
[17:30] <rjb> ok, thx.
[17:30] <rjb> (if it's not legal, no wonder it breaks in browsers)
[17:31] <rjb> then you need to remember to put some default content inside the textarea, so it won't minimize
[17:32] <jsp> (all manner of illegal things, like <ul><li></li><ul><li></li></ul></ul>, work despite being illegal) it's not legal in xhtml-served-as-html. it should be legal in xhtml-served-as-xml, but you can't use that in IE and it makes lots of client-side scripts not work
[17:33] <jsp> my temp workaround is when I want to have an empty textarea, I make its content a single . and then my template function does this at the end:
[17:33] <jsp> res.write(x.toXMLString().replace(/">\.<\/textarea>/g,'"></textarea>'));
[17:34] <zumbrunn> in Helma one could do the manual mapping of functions to urls through implementing an onRequest handler that would take care of that
[17:34] <zumbrunn> (if one would want to do that)
[17:34] <jsp> I know. but I wouldn't want to.
[17:34] <jsp> I like the helma way quite a lot so far
[17:37] <chessguy> jsp, how goes?
[17:37] <jsp> what I've found versus PHP is that complicated and tedious logic is still complicated and tedious, but it's much easier to organize in a sane way so that I can make sense of it later
[17:37] <jsp> good, you?
[17:38] <jsp> there's actually some other people here today :-)
[17:38] <jsp> rjb and zumbrunn are about
[17:38] <zumbrunn> yep
[17:52] <rjb> is session.user available as a macro to skins?
[17:52] <rjb> session.user.name, actually
[18:12] <zumbrunn> rjb, there is a built-in session macro
[18:12] <zumbrunn> but that maps to session.data
[18:14] <zumbrunn> (which means you'd have to set the username in session.data yourself)
[18:15] <zumbrunn> session.data.username = session.user.name
[18:15] <zumbrunn> then you could use <% session.username %>
[18:17] <midnightmonster> hm. hopbot (or someone) seems to have kicked me for trying to post too much text at once
[18:19] <midnightmonster> re php, I had built my own little framework that mapped each url to a page object. that had some benefits--e.g., I could make all pages meant only for admins extend AdminPage and not have to worry about access control on those pages--but did little to help with reflecting my data model.
[18:19] <midnightmonster> I found myself building lots of data-grabbing methods into the parent page objects, which was an improvement over not doing so, but was, I think, a weak solution compared to the helma model where many pages are actually actions of the same object. And the template was a separate object, so any data the template needed had to be fed to it explicitly.
[18:19] <midnightmonster> (maybe it was just the server on its own. or a weird network coincidence)
[18:20] <midnightmonster> But something that was simply not practical in PHP, e4x in javascript makes it easy for methods and objects to pass around page content without having to worry about what needs to be escaped in order to be included in what and without having to complicate any object's display methods with little things like customizing what class is assigned. In most environments, if you have a function or skin or partial template that r
[18:20] <midnightmonster> And if (God help you) you needed to put some content into the middle of some other content, but only sometimes, you'd have to have a parameter (another identifier to remember) and a block in the larger content for that. in all, on any slightly complicated site it quickly becomes impossible to simultaneously avoid repeating yourself and also keep your templates simple enough that it's at all clear what each is supposed to
[18:20] <midnightmonster> e4x changes that completely by giving a natural, even trivial way of safely altering content blocks as necessary. The table-making template can produce simple, clean table markup without knowing that you'll need to assign a class to the table and even without knowing that you're going to insert an extra row with colspan half-way down the table to include an advertisement inline.
[18:23] <midnightmonster> \nick jsp
[18:23] <midnightmonster> no... what's the command to change my name again?
[18:23] <zumbrunn> nick with a forward slash
[18:23] <zumbrunn> not a backward slash
[18:26] <zumbrunn> jps, where do you currently put your e4x?
[18:26] <zumbrunn> do you separate it at all?
[18:26] <zumbrunn> or have it purely in the code
[18:26] <jsp> yeah, mostly
[18:26] <jsp> sorry, yeah to separate it. I have a display.js file in each prototype
[18:27] <zumbrunn> separating it sometimes still would make sense, no?
[18:27] <zumbrunn> ok
[18:27] <jsp> it absolutely makes sense to have some functions for display and others for logic and mangling data
[18:28] <jsp> but I let my display functions freely access the other methods of the object and even the rest of the object tree as necessary
[18:30] <jsp> so the asForm display function for Sermon gets the list of books of the bible from root.nt and root.ot
[18:30] <jsp> (which are collections of the books of the new and old testaments respectively)
[18:30] <chessguy> jsp, ack! sorry, i had to run off to a meeting
[18:31] <jsp> 'salright I was just continuing the conversation that was already going on here
[18:32] <jsp> re: separating display/data/whatever, this is still only my first site, so I'm sure I'll develop my conventions a bit more about where to put what as I go.
[18:33] <chessguy> are you talking about MVC?
[18:33] <zumbrunn> yes... of course, if you would need to render untrusted skins, that would change the game a bit
[18:34] <jsp> uh, yeah. definitely. I don't think you could use e4x to render untrusted skins, since you can inline almost any javascript code you like in e4x.
[18:35] <zumbrunn> I'm planning to do it by using separate rhino scopes to evaluate the e4x skins
[18:35] <jsp> that'd work. I figured that was possible, but I don't know how to do it
[18:37] <jsp> chessguy, MVC as "The Way" doesn't make any sense to me. I've never been able to get over the mental hump of trying to apply a standard gui methodology to web apps. for all I know I'm just reinventing it, though. I do definitely see a need to have some kind of separation between concerns
[18:37] <chessguy> well, i don't see it as "the way"
[18:37] <chessguy> just as something good to keep in mind, and kind of aim for
[18:38] <zumbrunn> I think in an ideal situation, your markup doesn't contain the "view" anyway...
[18:38] <zumbrunn> it's just the structured data
[18:39] <zumbrunn> the view gets built using css and javascript in the browser
[18:40] <jsp> very seaside of you. I've been thinking that's mostly right, too. I'm not quite willing to go seaside all the way and give up meaningful urls.
[18:40] <jsp> I would have to understand what MVC meant for the web before I could aim for it, which I don't think I do. I have even heard that there exist other models of separating concerns and structuring applications, but you'd never know it from most web framework talk
[18:41] <jsp> I'm also separating the functions that produce HTML-structured data from the functions that have to decide how this piece and that piece of structured data get glued together.
[18:42] <jsp> that's what I'm loving e4x for (among other things)
[18:58] <rjb> http://helma.pastebin.com/d6fd9b86f
[18:58] <rjb> this looks like a good solution to me
[18:59] <zumbrunn> you just added the !session.user check, right?
[19:00] <rjb> yes
[19:02] <rjb> (i wonder what an api called 5eX would be for)
[19:03] <jsp> (I don't think that usually has an API. At least not one with consistent behavior.)
[19:05] <jsp> (e.g., you never know when applying the usual functions may create and attach a child object)
[19:22] <jsp> total random thing I just discovered: you can't set an mp3 trackNumber to 154. apparently that's above the limit, which I did not previously know existed.
[19:27] <jsp> helma.file.renameTo() is supposed to accept a string argument, but forgets to create a file object with the string before trying to use it as a file object
[19:36] <zumbrunn> helma.File is supposed to mirror the behavior of the old built-in global.File
[19:36] <zumbrunn> does that take a string argument?
[19:37] <zumbrunn> could be the docs that are wrong
[19:37] <zumbrunn> (for both)
[19:37] <jsp> File.renameTo supposedly also takes a string
[19:37] <zumbrunn> unless the docs lie
[19:37] <jsp> right. checking now.
[19:38] <zumbrunn> looking at the java source code in cvs, it looks like global.File expects a file object
[19:38] <jsp> yup--trying to use a string makes it barf
[19:39] <jsp> java.lang.IllegalArgumentException: argument type mismatch at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ... etc
[19:39] <zumbrunn> ok, so I screwed up when writing the docs
[19:39] <jsp> just fix it, please :-)
[19:39] <zumbrunn> yep :-)
[20:16] <jsp> does helma finish working if the client times out?
[20:16] <jsp> (the client in this case being the apache proxy)
[20:21] <jsp> another minor documentation bug: helma.File.list() returns an Array, not an Object
[20:23] <jsp> (and it's an honest-to-goodness array)
[20:31] <rjb> ok so i got myself a cheap rss feed
[20:32] <jsp> link again?
[20:33] <rjb> http://bobo.fuw.edu.pl/fotw/
[20:34] <rjb> at least it does work in my rss reader
[20:35] <jsp> works in firefox live bookmarks
[20:37] <jsp> the feedvalidator almost loves you: http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fbobo.fuw.edu.pl%2Ffotw%2F
[20:42] <rjb> hmm pretty close, yes
[20:42] <jsp> answer: helma stops when apache times out
[21:18] <zumbrunn> re: helma.File.list() ...this time it's JSDoc acting up when rendering the docs
[21:18] <zumbrunn> not sure yet why it does that
[21:52] <jsp> any way to get helma to send my response as I build it? i.e., it takes 5-6 sec per operation, and I'd like to output a line saying each op completed, but since apache times out after 11 ops, the message never makes it to the user.
[21:53] <jsp> also, any way to tell helma to keep going if apache times out?
[22:05] <rjb> twoday.org is itself powered by php, isn't that ironic?
[22:06] <jsp> well, it's dokuwiki.
[22:07] <jsp> the only helma wiki stuff if relatives of that which powers helma.org, which is not entirely mature
[22:07] <jsp> if=is
[22:34] <jsp> more doc bugs: HopObject.getOrderedView() doesn't return an array. I'm not exactly sure what it is.
[22:37] <jsp> (the extended text is clear that it's something other than an array that's returned) but I can't actually get it to work at all.
[22:41] <jsp> in the shell on one of my objects, this.getOrderedView('title') returns [NodeHandle[[162]], NodeHandle[[164]], NodeHandle[[169]], NodeHandle[[173]], NodeHandle[[210]], NodeHandle[[228]]]
[22:42] <jsp> the ordering is correct, but I have no idea how to access these items.
[22:42] <jsp> for(var i in orderedView) finds nothing. orderedView.length doesn't exist. orderedView[0] doesn't exist
[22:51] <zumbrunn> orderedView.list() ?
[22:52] <jsp> ba-bing!
[22:54] <jsp> there's no slightest hint of that one in the docs, which actually have an incomplete example that doesn't work, so that's another documentation bug for you
[22:54] <jsp> thanks
[22:55] <zumbrunn> if the example would have the line...
[22:55] <zumbrunn> for (var i in orderedByDate.list()) {
[22:55] <zumbrunn> ...it would be correct, right?
[22:56] <jsp> no
[22:56] <jsp> or... hold on
[22:56] <jsp> no.
[22:57] <zumbrunn> why not?
[22:57] <jsp> 'cause for(i in array) returns each index of the array, not the values
[22:59] <zumbrunn> well... you mean the code inside the for loop has to be something like...
[22:59] <zumbrunn> doSomething( orderedByDate.list()[i])
[22:59] <zumbrunn> ...to make this clear?
[23:01] <jsp> yes, except that that's a totally loony way to use it. requires n*2 function calls instead of 1 function call.
[23:01] <zumbrunn> yes
[23:04] <zumbrunn> var collection = orderedByDate.list(); for (var i in collection) doSomething(collection[i]);
[23:04] <jsp> documentation should ideally document what exactly it is that's returned from getOrderedView() and that documentation would show the methods it has, including list() and any others there might be. but if not (and possibly if so), the example should at least show saving the result to a tmp variable:
[23:04] <jsp> var byDate = this.getOrderedView('date').list(); // returns array of all children ordered by date
[23:04] <jsp> yeah, that'll work
[23:04] <zumbrunn> and retur type is now Collection instead of Array
[23:04] <zumbrunn> return type
[23:04] <jsp> does Collection have any other methods?
[23:06] <jsp> 'cause the Collection apparently has a useful property of being bound to the original set, but that's less useful than it might be if you can only use the contents by getting a non-bound array
[23:06] <zumbrunn> being bound to the original set?
[23:07] <jsp> and since collection includes all the children of the object, the same performance concerns about retrieving those all as an array should be present as with HopObject.list()
[23:07] <jsp> bound--according to the documentation anyway. presumably so that if I removeChild() or add() something it automatically gets removed/added to the ordered view, too?
[23:09] <zumbrunn> oh, yes
[23:25] <zumbrunn> looks like it should have pretty much all the relevant methods from the HopObject prototype
[23:27] <zumbrunn> get, getById, prefetchChildren, sizeco ,cunt, add, list, remove, removeChild, invalidate, contains, update and even getOrderedView again
[23:27] <zumbrunn> so, you can get an order view of an ordered view

 

 

In the channel now:

Logs by date: