2007-07-19:
[0:16] <midnightmonster> hey--just wasted some time trying to override the toXMLString method[0:18] <midnightmonster> was testing in seamonkey, where the engine doesn't call the method by name when it calls it on child elements, so if you write a modified version that corrects <textarea/>, it only works if you call it on <textarea/> and not <form><textarea/></form>[0:18] <midnightmonster> but it really was a waste of time, because Rhino doesn't let you access the prototype at all[0:21] <doublec> you could probably write your own toHTMLString I guess[0:23] <midnightmonster> yeah, but it'd be slow[2:07] <midnightmonster> also, it appears that Rhino doesn't give access to the prototype at all, so you can't add a toHTMLString method--it's have to be a separate function.[2:27] <doublec> it's __prototype__ isn't it?[2:28] <midnightmonster> is it? on normal objects it[2:28] <midnightmonster> 's just whatever.prototype[2:29] <midnightmonster> I'm still new on helma/rhino, though[2:31] <doublec> sorry, __proto__[2:34] <midnightmonster> so are you saying this should work:[2:34] <midnightmonster> XML.__proto__.cow = function(){ return 'moo'; };[2:34] <midnightmonster> res.writeln((<div/>).cow());[2:34] <midnightmonster> 'cause it doesn't[2:37] <midnightmonster> see http://developer.mozilla.org/presentations/xtech2005/e4x/ and click the left-pointing button to skip to the last slide[2:38] <doublec> ok, I was trying on a normal object, sorry[11:20] <zumbrunn> Helma 1.6 is ready![11:20] <zumbrunn> http://dev.helma.org/weblog/2007/07/announcing+helma+1.6.0/[11:49] <midnightmonster> got the email![11:56] <midnightmonster> btw, I'm pseudo-blogging (prepending articles to a single file as I go) my experience writing my first real Helma app. The page is also partly about a discussion ongoing in another forum about how we figure out estimates for web projects and how well we stick to them, so your mileage may vary. http://letterblock.com/intheopen[12:09] <leobm> hi![12:14] <midnightmonster> hi[12:29] <midnightmonster> any important changes since rc3?[12:54] <zumbrunn> midnightmonster, regarding what's new since rc3...[12:54] <zumbrunn> updated Rhino again[12:54] <zumbrunn> updated docs[12:54] <zumbrunn> improved compatibility with Postgres[12:54] <zumbrunn> and a scope problem was fixed[12:55] <zumbrunn> http://adele.helma.org/download/helma/nightly/changelog.html[12:55] <midnightmonster> did boolean columns in h2 make it?[12:55] <zumbrunn> yes[12:56] <midnightmonster> spiffy :-)[12:56] <zumbrunn> that's probably what I remembered as the Postgres fix[12:56] <midnightmonster> just looked at the changelog--I see it[12:59] <midnightmonster> I think a while ago we were talking about how it would be nice to be able to use E4X for templates and have something jquery-like to work with them... have you played with e4x much? it doesn't look like there would be a lot for a server-side jquery to do.[13:00] <zumbrunn> yes, I've played with e4x, but didn't completely switch to it yet[13:00] <zumbrunn> (I want to use it for skins)[13:00] <midnightmonster> I am using it for skins (or in place of skins) now[13:01] <midnightmonster> (since I never used skins except for the tutorial, I don't really have to 'switch')[13:01] <midnightmonster> e4x blows me away. I've never seen anything like it.[13:02] <midnightmonster> and everything just works. I've had this conversation with my code over and over: me: "hmmm, will this work?" code: yes![13:03] <zumbrunn> :-)[13:03] <midnightmonster> do you know who created it? I know it has been ecma/iso standardized, but I don't know where it came from except that it mostly *wasn't* brendan eich.[13:03] <zumbrunn> BEA[13:04] <midnightmonster> as in bea.com?[13:04] <zumbrunn> yep[13:05] <zumbrunn> http://macupdate.com/info.php/id/21751/helma[13:05] <zumbrunn> Ratings and reviews welcome[13:06] <midnightmonster> (I'm gonna have to send BEA a Christmas card.)[13:06] <midnightmonster> oh--what is an XML-Bean, and why would I want or not want them with my E4X[13:08] <zumbrunn> you need (or needed, I'm not sure) the xml-bean jar in order to have e4x support in Rhino[13:08] <midnightmonster> apparently it's 'needed' to judge from the release notes[13:09] <zumbrunn> certainly, the e4x implementation in Rhino was initially based on xml-bean[13:11] <zumbrunn> nope, that dependency is gone[13:11] <zumbrunn> I just removed my xml-bean jar and e4x is still working[13:12] <zumbrunn> which release notes?[13:13] <midnightmonster> the notes are accurate--I was saying 'needed' in contrast to 'need'. it's the what's new that is on the macupdate page and others[13:14] <zumbrunn> oh, right, it's in there :-)[13:30] <earl> w[13:31] <zumbrunn> earl, you're getting repetitive[14:15] <earl> zumbrunn: yep, sorry for that :)[14:15] <zumbrunn> what happened?[14:15] * earl writes a reminder to self: don't start typing too early on slow connections[14:16] <zumbrunn> oh, regarding the w[14:16] <zumbrunn> I thought you killed the hopbot ;-)[14:16] <earl> nah :)[14:16] * earl pats hopbot on the back[14:17] <earl> he does that all by himself[15:02] <zumbrunn> http://www.versiontracker.com/dyn/moreinfo/macosx/29914[15:02] <zumbrunn> http://www.versiontracker.com/dyn/moreinfo/win/64551[15:02] <zumbrunn> http://freshmeat.net/projects/helma/?branch_id=20067&release_id=258094[15:03] <zumbrunn> Again, ratings/reviews welcome[15:26] <treenyc> hi, is there any way to but all the action in a HopObject in a try/catch statement?[15:27] <treenyc> I'm thinking if any exception is thrown in the .hac file, is there anyway to catch it in the onResponse function[15:29] <zumbrunn> you mean the "try" would be inside the action function and the "catch" inside onRepsonse?[15:29] <zumbrunn> both inside the action function would work, of course[15:31] <zumbrunn> in other words, you would just have to deter acting on the error until onResponse checks for it[15:32] <zumbrunn> catch and flag it inside the action and then check for that in onResponse[15:32] <zumbrunn> is that what you are talking about?[16:18] <zumbrunn> treenyc, you know about the error action, right?[16:18] <treenyc> no what is that?[16:18] <zumbrunn> just to make sure you didn't miss that[16:18] <zumbrunn> http://helma.org/pipermail/helma-user/2007-June/007050.html[16:18] <treenyc> ok thanks[16:19] <midnightmonster> re: that msg, helma doesn't really return 200 on error, does it?[16:19] <midnightmonster> should be 500[16:20] <treenyc> so if "throw "something is wrong" is thrown in main.hac[16:20] <treenyc> there is no try statement in main.hac[16:21] <treenyc> are you saying the function notfound_action() { will catch it?[16:21] <treenyc> oh I see[16:21] <treenyc> I just reread your comments[16:21] <midnightmonster> function error_action[16:21] <zumbrunn> :-)[16:22] <treenyc> I would have have to manually set a global variable in main.hac[16:22] <treenyc> and look for the variable in onReponse[16:22] <treenyc> am I correct?[16:22] <treenyc> there is no trigger for that?[16:22] <midnightmonster> you could, but writing Root.error_action would be easier and should catch the error[16:22] <treenyc> oh ok[16:23] <treenyc> I am going to try it now[16:24] <treenyc> how can I catch the exception inside error_action?[16:25] <leobm> zumbrunn: where can I find the special actions methods in the helma reference ?[16:25] <zumbrunn> don't know if you can[16:26] <zumbrunn> leobm, yes, I thought about that too[16:26] <treenyc> isn't there a way to access the exception stack thrown by javascript?[16:26] <zumbrunn> I should probably add these methods as properties to the HopObject reference[16:27] <leobm> I'm not find it. I found this here: http://michi.knallgrau.at/helma-documentation/documentation.xml[16:29] <leobm> yesterday midnight ask me some questions about mountpoints ans special object values in properties files. in the normal helma documentation you don't find documentation about this. I know it only because i look at the antville code .[16:29] <midnightmonster> yeah. and it was pretty critical.[16:30] <zumbrunn> yes, I saw it ...and I learned from it myself :-)[16:30] <midnightmonster> oi.[16:30] <zumbrunn> feel free to start wiki pages if you think you can contribute something to the docs[16:30] <leobm> for novice helma users it's reallay hard to understand helma[16:31] <zumbrunn> I'll try to arrange what we collect to put together the new docs[16:31] <leobm> yes I will try it. but my english is not so good for it :)[16:31] <zumbrunn> I can fix the english afterwards[16:31] <zumbrunn> don't let that stop you[16:31] <leobm> perhaps we can create a page with keyword what we want see in the helma documentation ...?[16:32] <midnightmonster> it seems like the existing pages that document the .properties files aren't part of the wiki?[16:32] <zumbrunn> not yet, I'll move them over[16:32] <zumbrunn> along with lots of other stuff[16:32] <leobm> and people can add their name to this keyword if they are interested to write a dokumentation for it.[16:32] <midnightmonster> or they can just start writing it[16:33] <zumbrunn> I should probably make a separate wiki area specifically for the docs?[16:33] <leobm> yes.[16:33] <midnightmonster> I think so. right now the wiki is a hidgepodge of experimental whatever and basic documentation[16:33] <leobm> first a brainstorming page.[16:33] <midnightmonster> hodgepodge[16:34] <leobm> or documentation sandbox[16:34] <zumbrunn> the brainstorm page can go in to the current wiki[16:35] <midnightmonster> treenyc, it looks like error_action can be created for each prototype. and I would see if an argument gets passed to it--that would make sense[16:35] <treenyc> interesting[16:36] <treenyc> I'm looking at this now[16:36] <midnightmonster> oh! look, it's right in the documentation[16:36] <midnightmonster> res.error[16:36] <midnightmonster> at least that might be it[16:36] <midnightmonster> so function error_action(){ res.write("There was an error: "+res.error); } ?[16:38] <treenyc> ah[16:38] <treenyc> I see[16:38] <treenyc> I wonder if there are different exception levels we can set[16:38] <midnightmonster> javascript doesn't have exception 'levels'. not sure what you mean[16:39] <treenyc> this error actually out puts the line number of the code[16:39] <midnightmonster> ok, so maybe you won't want to display that to the user :-)[16:39] <treenyc> if I'm displaying to users, sometimes I don't want to[16:39] <treenyc> correct[16:39] <treenyc> i can of course implement some kind of global to allow that[16:40] <treenyc> but I was hoping there is something build in already.[16:40] <midnightmonster> I would just email myself the real error message and display a generic internal server error page. what more do they need?[16:42] <midnightmonster> (I know there *might* be reasons to have more detailed error messages, but if you know enough about the error ahead of time to write a meaningful error message, you should probably handle the exception closer in and do something useful to recover.)[16:42] <treenyc> ok thanks[16:43] <treenyc> I'm throwing a bunch of different kind of exceptions. I would ideally want to display a bit different messages depending on where I'm throwing the exception[16:43] <treenyc> but that is ok[16:43] <midnightmonster> let me/us/someone know what you come up with if you find a solution. I may need it in a month or so.[16:45] <zumbrunn> http://dev.helma.org/wiki/Helma+Modules/Documentation+%26+Training/[16:49] <midnightmonster> it really seems like the possible contents of the *.properties files should be part of the "Reference", even though they're not objects[16:51] <zumbrunn> yes, maybe... I'm not sure[16:53] <midnightmonster> I guess Java people expect their classes and only their classes to be documented in a particular way. But to me "list of built-in things you can do to your classes that affects how they behave" is the same kind of thing as "list of the things the built-in classes can do"[16:57] <zumbrunn> basically, my idea was to make the Reference document everything that lives in the Javascript environment[16:57] <midnightmonster> hm. that makes sense, too[16:58] <zumbrunn> but I guess that *does* include the properties[16:58] <zumbrunn> maybe we could add this reference here...[16:58] <zumbrunn> http://helma.zumbrunn.net/reference/app.html#properties[16:58] <zumbrunn> and here...[16:58] <zumbrunn> http://helma.zumbrunn.net/reference/app.html#getAppsProperties[16:58] <midnightmonster> sort of--they're user-set, and they directly impact the environment, but they're not really javascript and their syntax is only pseudo-javascript[16:59] <zumbrunn> but through these two methods you can get to them as normal object properties[16:59] <midnightmonster> read-only, though, right?[17:00] <zumbrunn> yep[17:01] <zumbrunn> but I don't see yet where we could add docs for the type.properties to the reference[17:02] <zumbrunn> either way, I think all the properties should be documented well as part of the User Guide docs[17:02] <midnightmonster> I dunno. app.properties is pretty straightforward, and you can get started without the details. but type.properties wires your prototypes together--it's essential to the basic operations of your app. so It really needs to be documented well in a very obvious place[17:02] <zumbrunn> and then we maybe just link to these pages from the reference[17:02] <midnightmonster> that works[17:33] <typicaljoe> morning everyone. or evening if you aren't in my area[17:34] <zumbrunn> good morning, typicaljoe[17:34] <midnightmonster> afternoon here[17:35] <typicaljoe> quick question for those who know more than me (everyone here no doubt): what web server does helma run on by default? does it have its own or is it using some version of lighthttp or the like?[17:35] <midnightmonster> jetty[17:35] <midnightmonster> 4.something[17:36] <midnightmonster> it's a java webserver that runs in the same process[17:36] <midnightmonster> if you want to use with lighttpd or apache, set them up to proxy the requests, preferrably over ajp[17:36] <typicaljoe> mm...cool. is there any reason not to use this default jetty setup with a production app? I really like how easy it was to deploy and not having to mess with apache or IIS[17:38] <zumbrunn> to run it on port 80 you have to run it with root privileges[17:39] <zumbrunn> and it runs as http, not https[17:40] <midnightmonster> Lighttpd is presumably faster at serving the static parts. It's easier to setup virtual hosting by proxying through apache (I don't know if it's possible with Jetty alone), and proxying brings up the possibility of caching, which could be very powerful if you have public pages that may get heavy traffic. And like Chris said, the standard procedure in Jetty-land if you want https is to proxy through apache[17:42] <midnightmonster> incidentally, setting up the proxy stuff with apache 2.2 is really easy but not yet (afaik) documented in Helma. Just bug me if you need to do it before I get around to writing it up[17:46] <zumbrunn> or look at the IRC logs ;-)[17:46] <zumbrunn> http://helma.zumbrunn.net/hopbot/2007-07-12[17:46] <midnightmonster> :-P I have not yet revealed the full strength of my apache-fu[17:47] <zumbrunn> you have a wiki page for that now :-)[17:48] <midnightmonster> yes. I'll write the first version in a week or so when I have my first real helma app fully configured and deployed. I want to be able to address at least a couple real-life concerns[17:49] <typicaljoe> cool, that will be great to read.[18:10] <midnightmonster> joe, I'm writing up my progress on this app at http://letterblock.com/intheopen (which focuses on the time it takes to build the app as well as helma stuff--see the intro at the bottom for details)[18:17] <typicaljoe> awesome![18:17] <typicaljoe> so how does e4x work?[18:20] <midnightmonster> title = "My Title";[18:20] <midnightmonster> aTableIGotFromSomewhereElse = <table><tr><td><!-- imagine this had useful data that I built in another function --></td></tr></table>;[18:20] <midnightmonster> x = <html><head><title>{title}</title></head><body><div id="content"/></body></html>;[18:20] <midnightmonster> x..div.(@id=='content').* += <p>See this informative table:</p> + aTableIGotFromSomewhereElse;[18:20] <midnightmonster> res.write(x.toXMLString());[18:21] <midnightmonster> notice the lack of quotes--those are XML literals as javascript objects, like regex literals (/myregex/ == new RegEx('myregex')) are javascript objects[18:23] <midnightmonster> the output of x.toXMLString() will be the string:[18:23] <midnightmonster> <html><head><title>My Title</title></head><body><div id="content"><p>See this informative table:</p><table><tr><td><!-- imagine this had useful data that I built in another function --></td></tr></table></div></body></html>[18:23] <midnightmonster> except pretty-printed[18:24] <typicaljoe> very cool, is there anything you need to do to start using it or just use var a = <table>[18:24] <midnightmonster> this is a decent presentation on it, though I went through it at least once before without "getting" it http://developer.mozilla.org/presentations/xtech2005/e4x/[18:25] <midnightmonster> nothing special--it's built-in. but the XML has to be well-formed[18:25] <midnightmonster> and the XML can go on more than one line like a normal document--I just didn't here[18:26] <midnightmonster> and if you have firefox and the firebug extension (which you absolutely should if you do web development), you can also play with e4x in the firebug console so you can experiment live[18:30] <typicaljoe> I haven't made it all the way through but it might be cool to see a layout of how you put together your app logic. as in if a user goes to /myaccount/ it runs myaccount.hac which creates the edit form via e4x and drops it into default.layout.skin[18:30] <typicaljoe> for example[18:30] <midnightmonster> could do that, but I'm replacing skins entirely[18:32] <typicaljoe> that was my question, maybe you discuss more farther down. wouldn't it still may sense to use a skin for your site layout even if most everything else gets rolled into the .js layer?[18:33] <typicaljoe> lol, a sermon upload site? I've just built one of those in coldfusion, just trying to get the church to launch it[18:34] <midnightmonster> (I'm not doing pretty at all until everything works, so this is super bare-bones:)[18:34] <midnightmonster> ##Root/Templates.js##[18:34] <midnightmonster> Templates = {[18:34] <midnightmonster> main: function(p)[18:34] <midnightmonster> {[18:34] <midnightmonster> var x = <html><head><title>{p.title ? p.title : ''}</title></head><body><div id="head"><p>head</p><hr /></div><div id="content"></div><div id="foot"><hr /><p>footer</p></div></body></html>;[18:34] <midnightmonster> x.body.div.(@id=='content').* += p.body;[18:34] <midnightmonster> return x;[18:34] <midnightmonster> }[18:34] <midnightmonster> };[18:34] <midnightmonster> ##UserMgr/main.hac##[18:34] <midnightmonster> res.write(Templates.main({[18:34] <midnightmonster> title:"All Users",[18:34] <midnightmonster> body:this.asTable() // returns a e4x tabular list of users[18:34] <midnightmonster> }));[18:35] <midnightmonster> (it's in reverse chronological order, so it gets more implementation-detailed toward the top) this site was commissioned by the preacher, so it should launch as soon as I'm ready[18:36] <typicaljoe> very cool, I'm liking Helma more and more[18:38] <midnightmonster> as to why no main skin, since I can write the markup directly into the script, and since I may want to have some logic in the main template display, e.g., include a sidebar if the caller passed content for one but not otherwise, it makes sense to me to do it all in script.[18:40] <typicaljoe> yeah, I've gone back and forth on that. of late I've typically built a single layout file and then drop the content into the layout, but you are right that there is too much logic in the layout and I don't want to repeat that header four times for logged in, logged out, new user, etc[18:40] <midnightmonster> exactly--I think this is the DRYest way[18:41] <midnightmonster> (Don't Repeat Yourself, in case you haven't played buzzword bingo recently)[18:41] <midnightmonster> (also you might see that I pass the XML obj directly to rew.write. it will attempt to convert whatever you pass to a string by calling .toString(), and XML.toString() function basically the same as .toXMLString() except when there's only a single element)[18:41] <typicaljoe> makes good sense...really good sense the more I understand it[18:44] <midnightmonster> also, when you inline a string like I do with <title>{p.title ? p.title : ''}</title>, it automatically escapes it for you. so if p.title="All < Users", it outputs All < Users[18:44] <midnightmonster> and it does the correct escaping for the context if you do the same in an attribute[18:45] <midnightmonster> that's why I have to attach p.body separately, though----oh, crikey[18:45] <midnightmonster> I didn't have to attach p.body separately[18:46] <midnightmonster> I assumed it would automatically get the string version of whatever was put in that way, but <div id="content">{p.body}</div> puts the XML object directly in and doesn't stringify and then escape it[18:47] <midnightmonster> working with e4x has been a repeat of this dialog:[18:47] <midnightmonster> me: I wonder if this will work and do the right thing...[18:47] <midnightmonster> my code: yes![18:51] <midnightmonster> ok, I've spent almost an hour and a half gabbing here. time to get some real work done. I'll be back if I get lost! (and later just to hang out)[18:59] <midnightmonster> oh... and using e4x XML objects all the time means that you can pass XML freely around between functions and even insert strings directly from the user without ever worrying about escaping, because it always does the right thing. it is the most brilliant new thing I have seen in how long[19:01] * zumbrunn thinks midnightmonster is excited about e4x[19:16] <typicaljoe> agreed, but so am I[19:17] <zumbrunn> and so am I[19:17] <zumbrunn> I just have to rewrite everything to leverage all the goodies of Helma 1.6 now[19:18] <zumbrunn> but thanks to the new features in Helma 1.6 I'll probably be able to do it with just 10% of the code[19:19] <typicaljoe> so...this line: x.body.div.(@id=='content').* += p.body;[19:20] <typicaljoe> I'm not sure how to read that, but is that using a dot notation to get access the content of that div?[19:21] <typicaljoe> if so, would that mean that you could store text within XML like that and then pull it out for use later?[19:21] <typicaljoe> have to play with it[19:29] <midnightmonster> and in e4x, I just found that <div/>==<div/>, so if you build the same XML tree twice, they'll equal each other. which is good for testing XML-generating functions, among other things[19:30] <typicaljoe> hey mightnight, question[19:30] <typicaljoe> so...this line: x.body.div.(@id=='content').* += p.body;[19:30] <typicaljoe> are you using dot notating to access the content inside the content div?[19:32] <midnightmonster> yeah div.* means "all the stuff inside div", so div.* += p.body is the same as div.appendChild(p.body);[19:32] <typicaljoe> ahh...cool[19:32] <midnightmonster> and the first part could also be wrtten x..div.(id=='content')[19:33] <midnightmonster> and that would pull out the div with id=content no matter where in x's descendants it was[20:00] <midnightmonster> more things I'm learning: it's <p class={myclass} />, not <p class="{myclass}" />[20:04] <midnightmonster> and <p>{someUndefinedVariable}</p> yields an error[20:04] <midnightmonster> <p>{definedObj.undefinedProperty}</p> yields <p>undefined</p>[20:04] <midnightmonster> <p>{definedObj.undefinedProperty || ''}</p> yields <p></p> (or probably <p/>, really)[20:04] <midnightmonster> so you can do things like <input value={req.postParams.email || this.email || ''} name="email" />[20:10] <typicaljoe> crazy, but very cool[20:11] <midnightmonster> all of that was really just standard javascript in a different context, so not really odd if you're familiar w/ how JavaScript handles such things, but I wanted to find out exactly how it worked.[20:12] <typicaljoe> that is cool, mind blowing. I really like the idea wrapping up your form in such a way that it can receive default values and the like[21:04] <midnightmonster> only... rhino's a4x doesn't seem to be doing the attribute thing correctly[21:04] <midnightmonster> e4x[21:19] <midnightmonster> treenyc--have you tried doing the attribute thing I described? it's working fine in firefox, but helma (rhino) seems to have a bug[21:19] <treenyc> no I have not tried it[21:21] <treenyc> midnightmonster --- however, I don't think I have mentioned anything about attribute[21:21] <midnightmonster> ?[21:21] <midnightmonster> oh, sorry[21:21] <midnightmonster> not you[21:21] <midnightmonster> typicaljoe[21:22] <midnightmonster> names both begin with t[21:22] <midnightmonster> typicaljoe--have you tried doing the attribute thing I described? it's working fine in firefox, but helma (rhino) seems to have a bug[21:35] <typicaljoe> I haven't, haven't had a chance to try e4x yet, but hopefully in another hour or so as work winds down[21:49] <midnightmonster> [attn Chris!] Looks like rhino builds since late March have a serious E4X bug with attribute literals (i.e., they don't work at all) but that they've fixed it in just the last 30 hours.[21:49] <midnightmonster> https://bugzilla.mozilla.org/show_bug.cgi?id=382098[21:49] <midnightmonster> I do not have the know how to build rhino myself, and I don't know what extra patches Helma uses. I think this warrants a respin of Helma 1.6, but failing that is there a kind soul who can build a really new rhino for me with whatever extra patches Helma applies?[21:59] <midnightmonster> d'oh. not March--May[22:30] <typicaljoe> hellp hopbot, what do you do?[23:17] <zumbrunn> midnightmonster, as a workaround you can probably use e4x the "old" way, by putting xml-bean.jar into the ./lib/ext directory[23:17] <zumbrunn> worth a try, anyway[23:31] <midnightmonster> nope--you get a different bug then[23:31] <midnightmonster> or, bug with the same thing, but screws up just a bit differently
In the channel now:
Logs by date: