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

2007-12-04:

[0:10] <zenpsycho> I have blogged about helma
[0:10] <zenpsycho> http://bustingseams.blogspot.com/
[0:17] <zenpsycho> I should note, for search engine purposes, that my post is about _parent, and the permalink is http://bustingseams.blogspot.com/2007/12/helmas-documentation-is-confusing-heres.html
[0:17] <midnightmonster> yup. that's what _parent does.
[0:19] <zenpsycho> I never would have worked it out if someone already experienced with helma didn't demonstrate what _parent does
[0:20] <midnightmonster> I think I asked on the list myself. so far the only app I've actually built (As opposed to started or thought about) used the built-in object DB, no relational DB. so it was a little different
[0:21] <zenpsycho> doesn't the problem that _parent is meant to solve still come up though, DB or no
[0:21] <zenpsycho> ?
[0:22] <midnightmonster> I don't see _parent as an after-the-fact thing. it's not in that case, anyway. 'cause when you create an object you have to explicitly attach it to something.
[0:23] <zenpsycho> sure, you don't need parent if you only attach it to one thing
[0:23] <zenpsycho> but if you attach it to more than one thing, well..
[0:23] <midnightmonster> well, I often attached to several things, but the first thing you add it to becomes the _parent by default, and that worked fine for me
[0:24] <zenpsycho> how does helma know which one you added it to first?
[0:24] <midnightmonster> I don't understand the question. I do it with code. Helma executes the code. It can't not know.
[0:25] <zenpsycho> oh wiait, are you just atalking about using things like add()
[0:25] <midnightmonster> yes
[0:25] <midnightmonster> that's how you attach objects
[0:26] <midnightmonster> if I'd grocked the _parent property in type.properties at the time, though, there are a couple things I could have done more clearly.
[0:27] <zenpsycho> I still don't know what _parent does when you pspecify more than one property
[0:28] <midnightmonster> if I have a Spoon object and set _parent = silverbox, drawer, placesetting
[0:29] <midnightmonster> then when I create a Spoon but it's stainless not silver, I leave silverbox empty and assign a reference to a Drawer to the drawer property
[0:30] <midnightmonster> Now my Spoon instance's _parent is a Drawer, mySpoon._parent == mySpoon.drawer
[0:30] <midnightmonster> but if it were silver and I assigned something in the silverbox property, mySpoon._parent==mySpoon.silverbox
[0:31] <midnightmonster> even if I also assigned a drawer
[0:31] <midnightmonster> (which wouldn't make that much sense--but I might assign a placesetting and a drawer/silverbox)
[0:32] <midnightmonster> (if I were writing an app about silverware, anyway, which itself is highly improbable)
[0:32] <zenpsycho> writing an app about silverware sounds fun
[0:33] <zenpsycho> as long as it had chunky colorful graphics
[0:33] <midnightmonster> but you really have to be careful about security when you write a silverware app. at any time a dish may run away with one of your spoons.
[0:34] <zenpsycho> Well obviously you'd sandbox the dishes
[0:34] <zenpsycho> sanitize their output
[0:35] <midnightmonster> *sigh*
[0:37] <zenpsycho> What's the matter?
[0:37] <midnightmonster> your pun.
[0:38] <zenpsycho> I don't remember making a pun, but okay
[0:38] <midnightmonster> oh. well you were sanitizing the output of the dishes. like the setting on my dishwasher to sanitize.
[0:39] <zenpsycho> Ah, I didn't think about that.
[0:40] <zenpsycho> I guess I'm more punderful than I realized
[0:46] <zenpsycho> Thanks for that explanation of _parent btwn
[0:46] <midnightmonster> you're welcome
[0:46] <zenpsycho> Filled up the last remaining gap in my understanding
[0:47] <zenpsycho> I should be able to, w ith that information, fill in one of the parent properties on the fly
[0:47] <zenpsycho> just before calling href
[0:48] <midnightmonster> sure
[0:48] <midnightmonster> I think :-)
[0:52] <zenpsycho> apologies for the typos, backspace is broken.
[0:54] <midnightmonster> what're you working on doing with helma?
[0:56] <midnightmonster> (bbl)
[1:17] <zenpsycho> I am doing plenty of things with helma.
[1:18] <zenpsycho> Hey philmaker
[1:18] <zenpsycho> I blogged about helma
[1:18] <philmaker> hi bslivka
[1:18] <philmaker> cool
[1:18] <zenpsycho> heh that's right, I keep forgetting
[1:19] <philmaker> I added you to my Helma community page: http://philmaker.com/Helma/Community/
[1:19] <philmaker> woot
[1:21] <bslivka> neat
[1:22] <philmaker> I made alittle macro for Gobi which extracts source listings from attached zip files and lists them inline in a page.
[1:22] <philmaker> I think maybe I am too proud of myself about this but it's really all I have done with Helma really so far. hehe
[1:22] <philmaker> http://philmaker.com/Gobi/Zip+Attachment+Listings/
[1:22] <bslivka> You told me yesterday
[1:22] <philmaker> ha ha lol
[1:23] <philmaker> " think maybe I am too proud of myself" uhuh
[1:23] <philmaker> I'm a loser
[1:23] <philmaker> moving on
[1:23] <bslivka> it's pretty snazzy
[1:23] <bslivka> I would perhaps find use for it if I used gobi
[1:24] <philmaker> reading you post...
[1:24] <philmaker> hehe yeah
[1:24] <philmaker> maybe only of use for the Helma site
[1:24] <bslivka> You might want to get it to ignore __MACOSX
[1:24] <philmaker> right
[1:25] <bslivka> I don't think mac 's should be adding them to begin with
[1:25] <bslivka> but since they do, well
[1:26] <philmaker> I zipped the file from the desktop/UI and should have done via CLI
[1:27] <philmaker> Are you currently using Helma in any projects?
[1:27] <bslivka> yes, a couple
[1:28] <bslivka> I made a simple helma app that turns applescripts into webservices
[1:28] <philmaker> Soon I'm about to make a small app for lazy storage of AJAX requests. Maybe or maybe not using CouchDB.
[1:28] <bslivka> will be using that in a rather interesting project soon
[1:28] <philmaker> Joshus Paine mentioned that he has an interest in integrating Helma and CouchDB but I haven't followed up.
[1:28] <bslivka> The hype around couchDB is a bit concerning
[1:29] <philmaker> Oh yeah I remember you asking about applescript before
[1:29] <philmaker> re: The hype around couchDB is a bit concerning -- how so?
[1:30] <bslivka> I don't think it's such a great idea to discard the relational model so quicklly
[1:30] <philmaker> I guess it depends on the use case
[1:30] <bslivka> nor is it a good idea to judge the relational model on the supposed implementations which are not implementations
[1:30] <bslivka> IE anything with SQL
[1:31] <philmaker> ??? "nor is it a good idea to judge the relational model on the supposed implementations which are not implementations"
[1:33] <philmaker> I'm not super thrilled about using CouchDB exactly. But I do want to create a Helma tool to allow storage for client-side AJAX development to be super simple.
[1:33] <philmaker> relational or not
[1:33] <midnightmonster> fyi, Joshua Paine == midnightmonster
[1:34] <philmaker> hello mister
[1:34] <philmaker> hi Joshua
[1:34] <midnightmonster> but I'm switching to the laptop--gotta watch the Ravens on the tiny chance they can give the Pats some trouble. brb
[1:34] <philmaker> ok
[1:35] <philmaker> I also am going afk for a bit... back in 30 perhaps
[1:39] <bslivka> that is the most confusing thing I say, most people don't seem to get it
[1:39] <bslivka> but it's absolutely true
[1:39] <bslivka> SQL is not relational
[1:40] <bslivka> and by extension, any product which uses SQL as its primary language is also not relational
[1:40] <bslivka> So for instance, MySQL is not a relational database management system, despite claims that it is
[1:41] <bslivka> This is not a matter of opinion, it's a matter of mathematical definition
[1:42] <bslivka> The relational model is the only practical way to manage large numbers of facts
[1:42] <bslivka> and nobody uses it.
[1:43] <bslivka> And now couch DB comes along and everyone says "Yeah, woo, screw the relational model. I'm going with this!"
[1:43] <bslivka> from people who have never used the relational model, and don't know what it is
[1:44] <bslivka> So that's what concerns me about the hype around couch DB, though it itself looks fine
[1:44] <bslivka> I am concerened about its positioning as better, or useful as a drop in replacement to "relational databases"
[1:45] <midnightmonster> I think we've had this conversation before. IMO it's sort of irrelevant that we're discarding the relational model without trial when there's no trial available.
[1:45] <bslivka> because it may mean that nobody will ever bother to create a relational database management system
[1:46] <midnightmonster> also, the way you have to think about working in couchdb is quite different from the pseudo-relational model, so it's hardly drop-in.
[1:46] <midnightmonster> if two-ish guys working part-time-ish can make a DB so useful that no one feels the need to make any other kind of DB ever...
[1:47] <bslivka> I'm not knocking couchDB itself, of course
[1:47] <bslivka> just the hype around it
[1:47] <bslivka> it looks kind of cool
[1:47] <bslivka> and as long as it's only used for what it's good at, I have no problem with it
[1:48] <bslivka> but i'm concerned it may become one of those things like XML where people start using it in situations where it is not appropriate
[1:48] <bslivka> and better solutions exist
[1:49] <philmaker> yeah XML is way overused
[1:49] <philmaker> that's all I have to say about that
[1:49] <midnightmonster> *glad couchdb switchd to JSON*
[1:49] <philmaker> righto
[1:49] <philmaker> I think that's neat
[1:49] <bslivka> I'd like it if helma switched to json
[1:49] <philmaker> ditto
[1:50] <bslivka> And in that case having couchDB as the built in database may not be a bad idea
[1:50] <bslivka> since it fits helma's model of doing things better than Helma's ORM
[1:50] <philmaker> I have a question about Helma and SQL databases and the ORM...
[1:51] <midnightmonster> helma is built around its orm. there will be a bit of a stretch getting it to work sanely with couchdb
[1:51] <bslivka> It'd be nice if json was used tinstead of java.proprty files as well
[1:51] <philmaker> how does the ORM work if you need to do a select query?
[1:51] <midnightmonster> afaict, all helma does significantly in xml is store the object cache/object db. with all built-in support for XML in java, JSON might not be any more efficient.
[1:51] <philmaker> For example, I have not yet really done the address book tutorial - but that always is going to return all Persons?
[1:51] <philmaker> Unless you provide a SQL query?
[1:52] <midnightmonster> you can do various where conditions through properties, but the ORM's collections can't be created on the fly with arbitrary queries
[1:52] <philmaker> however CouchDB is written in Erlang I think?
[1:52] <midnightmonster> yes
[1:52] <midnightmonster> (brb)
[1:52] <philmaker> thanks
[1:53] <bslivka> You owuldn't switch the JSON db for efficiency
[1:53] <bslivka> it'd be for clarity, succinctness, and a better fit with javascript's object model
[1:53] <bslivka> replace succinctness with brevity there
[1:53] <philmaker> And a better fit with Helma
[1:54] <bslivka> I talk abit on my blog about the mismatch between xml and json
[1:55] <bslivka> philmaker: in regards to your question
[1:55] <bslivka> You can use a .filter property
[1:55] <philmaker> righto
[1:55] <bslivka> which forms the right hand side of the WHERE clause
[1:55] <bslivka> in the select statement that helma uses to retrieve the collection
[1:56] <philmaker> I'm seen that in some pages - need to study it - I haven't even setup a db yet - may go with hsqldb
[1:56] <midnightmonster> i did h2 with the addybook tutorial
[1:57] <bslivka> I think the address book tutorial should not thrust one into using ORM
[1:57] <bslivka> considering that it glosses over setting up the Database and its tables
[1:57] <bslivka> does not even tell you that you should be doing that
[1:58] <midnightmonster> umm... I'm pretty sure it gave code for setting up mysql
[1:58] <philmaker> I used hsql back around 2001 back when it was run by Thomas xxxx. So now it appears one has split off?
[1:58] <midnightmonster> yeah. thomas left hsql and is writing h2 now
[1:58] <philmaker> re: I think the address book tutorial should not thrust one into using ORM -- agreed
[1:58] <bslivka> it gives the db.properties contents
[1:59] <bslivka> that is only one half of setting up the DB for the tutorial
[1:59] <bslivka> I think if helma is going to hype its seamless transition from no DB, to mapping the DB objects to a real database
[2:00] <philmaker> bslivka: are you using h2 embedded or are you connecting to it?
[2:00] <bslivka> the addressbook tutorial should be in two parts
[2:00] <philmaker> I want to try embedded
[2:00] <philmaker> but maybe it doesn't really matter
[2:00] <bslivka> set up the addressbook application completely, without any ORM
[2:00] <midnightmonster> the sql is further down on http://helma.org/docs/tutorial/wiring/
[2:01] <philmaker> Oh I understand what you are saying...
[2:01] <philmaker> I agree that there should be a simpler tutorial w/o database connections
[2:01] <midnightmonster> it dosn't hype that, though. afaict it's not actually well supported to keep your data anyway if you move from built-in to sql
[2:01] <philmaker> and then a part 2 or whatever
[2:01] <bslivka> then a second tutorial that hooks up the application you built to a DB
[2:02] <philmaker> Honestly, I prefer just listing the final source code and commenting on it - over making someone labor through a piece by piece tutorial
[2:02] <philmaker> just seems silly to me
[2:04] <midnightmonster> (bbl)
[2:04] <bslivka> Maybe it doesn't hype the transition on the front page, I'm pretty sure I've seen that boasted about somewhere
[2:04] <bslivka> it does boast about the "simple and codeless mapping of application objects to database tables"
[2:05] <bslivka> that's certainly stretching the truth a bit
[2:07] <philmaker> simple != easy
[2:08] <philmaker> :-)
[2:08] <philmaker> I want to look into Rabitt and SuperRocket more
[2:08] <philmaker> Rabbit and Rabbit the Super Rocket
[2:08] <philmaker> and TrimPath Junction perhaps
[2:09] <philmaker> http://dev.helma.org/wiki/Rabbit/
[2:15] <midnightmonster> I just got an email from steve yegge (no lie) saying: "I think we'll probably try to open-source Rhino on Rails next year (2008). It seems like it's getting close to good enough to open up.  It requires first open-sourcing our servlet engine, so I need to check on how that's going."
[2:18] <midnightmonster> He adds, "Keep fingers crossed!" so I don't know how firm that is.
[2:21] <philmaker> I'm not counting on it or I wouldn't be here. :-)
[2:22] <philmaker> I looked at Phobos and it's even harder to get into the groove than Helma I think.
[2:22] <philmaker> I also don't like Phobo's tie in with NetBeans
[2:23] <midnightmonster> phobos looks too java-y
[2:23] <philmaker> I think that's pretty hilarious that GWT uses Java to hide Javascript and Rhino on Rails uses Javascript on top of Java.
[2:23] <philmaker> What ever will they do next!
[2:24] <midnightmonster> google didn't write and doesn't use gwt. it's cover fire.
[2:24] <philmaker> I know
[2:24] <philmaker> At out local JUG here in Austin, Google did a preso on GWT
[2:25] <midnightmonster> ?
[2:25] <philmaker> I was quite interested in GWT for some time, but now I really like ExtJS
[2:25] <philmaker> Earlier this year at the Austin Java user group meeting, some guy from Google gave a talk on GWT
[2:25] <philmaker> Google opened a site here in Austin back in June
[2:26] <philmaker> Actually - what do you mean: it's cover fire.
[2:28] <philmaker> you mean ming share? YUI vs GWT?
[2:28] <philmaker> you mean mind share? YUI vs GWT?
[2:31] <philmaker> Hey midnightmonster... have you done anything with Helma and CouchDB?
[2:35] <philmaker> off to code....
[2:51] <midnightmonster> philmaker, not yet
[2:51] <midnightmonster> got them both installed on the virtual server, though ;-)
[2:53] <philmaker> what I meant by "lazy" a few days ago was: basically being able to post data at any path on the web server - sort of like a bulletin board
[2:54] <philmaker> so I may first just play around with the internal database
[2:55] <midnightmonster> like a data wiki?
[2:55] <philmaker> sure
[2:55] <philmaker> primary goal is just data persistance for client side JS prototypes
[2:55] <philmaker> client side JS prototype apps
[2:56] <philmaker> do you know of any data wikis for AJAX?
[2:57] <midnightmonster> nope.
[2:57] <midnightmonster> bbl
[3:55] <bslivka> have you seen jspon, philmaker?
[3:55] <philmaker> no - looking...
[3:56] <bslivka> It is basically what you describe
[3:56] <philmaker> sounds interesting
[3:56] <philmaker> http://www.jspon.org/
[3:57] <bslivka> that's the one
[3:57] <philmaker> Really basic question for you...
[3:58] <bslivka> okay
[3:58] <philmaker> For an AJAX request , it's OK to return JSON in a GET request
[3:58] <philmaker> however, using Helma, it is dangerous to post JSON and have the Helma runtime evaluate it no?
[3:59] <bslivka> depends on how you evaluate it
[3:59] <philmaker> Just seems that evaluating JSON in the Helma JS runtime seems dangerous
[3:59] <bslivka> in the JSON rfc there's a regular expression for sanitizing json
[3:59] <philmaker> but all these other tools in other languages may not be as dangerous
[4:00] <philmaker> sanitizing json - ok
[4:00] <bslivka> but if that still makes you nervouse, there are javascript based json parsers as well
[4:00] <bslivka> that do not use eval
[4:00] <philmaker> gotcha - cool
[4:01] <bslivka> the main danger of course is if someone slips in jmalicious javascript code in with the json
[4:01] <bslivka> and helma evaluatioes it
[4:01] <philmaker> that's what I mean
[4:02] <philmaker> is that preventable?
[4:02] <philmaker> that situation?
[4:02] <bslivka> yes of course
[4:02] <philmaker> json parser
[4:02] <bslivka> you just check the post content to be sure there's nothing executiable in it
[4:02] <bslivka> nothing that is not json
[4:03] <philmaker> sanitize - ok
[4:03] <bslivka> the regular expression can do that
[4:03] <bslivka> but
[4:03] <bslivka> to be perfectly honest
[4:03] <bslivka> I'm pretty sure that using the javascript parser is going to be faster and less resource hungry anyway
[4:04] <bslivka> The reason being that eval() opens up a whole new execution context
[4:05] <bslivka> with its own memory requirements and everything. In rhino there's even the additional cost of it running as an interpreter
[4:06] <bslivka> instead of the compiled jar you usually get
[4:06] <bslivka> I'm talking out of my ass to a large extnet here
[4:06] <bslivka> so take it with a grain of salt
[4:06] <philmaker> :-)
[4:07] <philmaker> Thanks for chatting bslivka - good to have you around
[4:08] <philmaker> I'm running downstairs for a bit - then diving in to some dynamic ajax pages stuff...
[4:08] <philmaker> I'll look more at jspon
[4:26] <philmaker> http://www.xucia.com/#Persevere
[4:49] <philmaker> Found an article here: http://www.ibm.com/developerworks/java/library/wa-aj-objmap/index.html?ca=drs-tp4607
[4:55] <midnightmonster> For parsing/evaling JSON in Helma, the function you're looking for is String.parseJSON. built-in to Helma.
[5:01] <midnightmonster> which, as best as I can tell, uses the regex and eval. and though eval is somewhat expensive, I think you underestimate how slow the pure javascript JSON parser is.
[5:02] <midnightmonster> it's best to use the built-in anyway. if you actually found a safe implementation that was faster, you could always overload String.prototype.parseJSON yourself.

 

 

In the channel now:

Logs by date: