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

2007-11-20:

[3:56] <philmaker> hello my peeps
[3:56] <philmaker> my peoples
[3:58] <philmaker> How is the old lady today?
[4:26] <philmaker> I'm just chatting here - not sure if anybody is listening - here we go...
[4:27] <philmaker> I took me a little bit to understand that the multi-faceted features of HopObjects relate more to publishing (as in Helma Object Publisher) and implementations for content such as Gobi and Antville.
[4:28] <philmaker> So it took me a little bit to grasp that the HopObject demo (attaching HopObjects dynamically) doesn't necessarily apply to a traditional web app and persisting data for a user (and not application wide content data let's say)
[4:29] <philmaker> I think that is possibly a significant problem with the existing documentation- and with public acceptance of Helma.
[4:29] <philmaker> HopObjects are really cool - but developers who are trying to create traditional, "non-content" webapps may be confused by the multi-faceted features of HopObjects.
[4:31] <philmaker> and that the fact that a HopObject can resolve to a portion of a URL path and that they can contain data (application content data) applies to content-based webapps may be confusing
[4:58] <philmaker> Is anybody awake on here? I have a simple question.
[5:43] <philmaker> I am trying to attach some custom HopObjects to the User HopObject. I passed a regular HopObject to session.login()
[5:45] <philmaker> I am trying to attach other HopObjects to this main user HopObjects. I can do so fine when they are actual/direct HopObject instances. However I am having problems doing so it the object I want to attach "extends" from HopObject.
[5:46] <philmaker> I prefer to do all of this User HopObject attaching directly in code. How do I make my custom object extend from the HopObject prototype directly in code? I'm trying to not have to use the folder scheme/convention.
[5:46] <philmaker> Maybe I need to brush up on my JavaScript - for instance I already tried: Person.prototype = HopObject.prototype
[7:13] <zumbrunn> hi philmaker
[7:13] <zumbrunn> Person.prototype = new HopObject()
[7:13] <philmaker> ah - thanks
[7:13] <philmaker> Take your time - get your morning cafe...
[7:14] <zumbrunn> will do ;-)
[7:14] <philmaker> I'm here for another hour or two. hehe
[7:14] * zumbrunn goes and gets a cup of coffee
[7:14] <philmaker> I am going to the fridge for a:
[7:15] <philmaker> http://www.sierranevada.com/beers/paleale.html
[7:16] <philmaker> brewed in: http://en.wikipedia.org/wiki/Chico%2C_California
[7:18] * zumbrunn would go for this one: http://www.sierranevada.com/beers/stout.html
[7:18] <zumbrunn> (if it's anything like Guinness)
[7:21] <philmaker> still here - but going away -brb
[7:26] <zumbrunn> philmaker, what's an example for what you mean with a "traditional web app" that is centered on user data, not content data?
[7:27] <zumbrunn> wouldn't prefixing the url hierarchy with (for example) the username solve these situations in any case?
[7:27] <philmaker> by content data I mean CMS-like
[7:28] <zumbrunn> vs coming from a db that mainly serves as a read-only data store?
[7:28] <philmaker> by traditional web-app, I mean very little application shared data/content and more user-centric data.
[7:28] <philmaker> ...
[7:29] <philmaker> thinking...
[7:29] <zumbrunn> but starting the url hierarchy with the username would always give you a user centric space
[7:30] <philmaker> HopObjects seem like they are primarily designed to display application-wide data associated with a portion of a url
[7:30] <philmaker> that was another question of mine
[7:31] <zumbrunn> with "application wide" you mean data that is intended to be viewable by anybody?
[7:31] <philmaker> "Do User HopObjects resolve at the URL level" - and you are saying - yes they do
[7:31] <philmaker> sorry if my lingo is bad
[7:32] <zumbrunn> you wouldn't have to directly do it that way...
[7:32] <philmaker> with "application wide" you mean data that is intended to be viewable by anybody? YES, and when I wrote that I didn't realize that User hopobjects could be resolved via the URL request
[7:33] <zumbrunn> for example, you made a space for yourself in the wiki on dev.helma.org
[7:34] <zumbrunn> there is a page directly relating to your user object: http://dev.helma.org/config/users/philmaker/
[7:35] <zumbrunn> but you have your user centric content here: http://dev.helma.org/wiki/Workspace/philmaker/
[7:36] <philmaker> But anybody can edit my pages right? So it is not user centric - I don't own that content right?
[7:36] <zumbrunn> But that's configurable
[7:36] <philmaker> You asked me about my use case yesterday. Here is what I am hoping to do with Helma initially. It's simple really. I just want to use Helma as a simple lazy data store for AJAX requests.
[7:37] <philmaker> Initially
[7:38] <zumbrunn> I think what you mean with user-centric is apps where the same url behaves different for different users, correct?
[7:38] <philmaker> yes, has different user/session data
[7:40] <philmaker> In a nutshell, here is what I have started to understand - the basis for Helma...
[7:40] <philmaker> the design
[7:40] <philmaker> The P in HopObject stands for Publisher (Object Publisher)
[7:41] <philmaker> Some of the foremost Helma projects are content/CMS related (Gobi, Antville)
[7:41] <philmaker> If someone is new to Helma and does not understand the primary original focus/design of the HopObjects, it's very easy to get confused about their usage.
[7:42] <zumbrunn> right, but it's basically called HopObject because back then the project was called HOP (the full name, not just the Helma short name)....
[7:42] <zumbrunn> today the HopObject would probably be named HelmaObject
[7:42] <zumbrunn> or something completely different
[7:43] <philmaker> maybe by traditional webapp I mean RESTful like you mentioned yesterday - but I haven't really studies what REST means much so far.
[7:43] <zumbrunn> probably the other way around
[7:44] <philmaker> We'll stop talking about these concept soon - making my brain hurt
[7:44] <philmaker> lol
[7:44] <zumbrunn> mapping urls to resources that can be bookmarked is an important aspect of REST
[7:44] <philmaker> gotcha
[7:45] <philmaker> REST another freakin acronym : DRY, CRUD, SPOT....
[7:45] <zumbrunn> hehe
[7:47] <philmaker> Repeating... : You asked me about my use case yesterday. Here is what I am hoping to do with Helma initially. It's simple really. I just want to use Helma as a simple lazy data store for AJAX requests.
[7:48] <philmaker> Do you think it's better to approach with: a static URL scheme and copy posted data into User hopobjects chain
[7:48] <philmaker> Or use /user1/toys
[7:49] <philmaker> substitute toys for any other sort of object
[7:49] <zumbrunn> seems right to me
[7:49] <philmaker> the former or the latter?
[7:49] <zumbrunn> I don't see the downside of doing that
[7:49] <zumbrunn> oh...
[7:50] <zumbrunn> the latter, I guess
[7:50] <philmaker> does /toys resolve the same of /user1/toys
[7:50] <philmaker> does /toys resolve the same as /user1/toys? Othewise I don;t see how this is possible
[7:51] <zumbrunn> how do you login the user?
[7:51] <zumbrunn> doesn't the user know its username?
[7:52] <philmaker> I guess I'm asking - do I have to copy all possible/potential HopObject requests to each user when logging in that Users HopObject?
[7:53] <philmaker> Otherwise I don't understand how each URL request would be resolvable.
[7:53] <zumbrunn> are you familiar with amazon S3?
[7:53] <zumbrunn> you could use a data bucket concept similar to S3
[7:53] <philmaker> Re: how do you login the user? Right now, I'm just using session.login(HopObject)
[7:53] <philmaker> I guess maybe I need to give that HopObject a name
[7:54] <zumbrunn> then control which users have which kind of access to which buckets
[7:54] <philmaker> 'I will have to study that
[7:54] <philmaker> not familiar
[7:55] <zumbrunn> what I mean is, I would separate the data containers from the user objects
[7:55] <zumbrunn> and just make a relation between the two
[7:55] <zumbrunn> so one user can have multiple data stores
[7:55] <philmaker> my plan atm is to separate
[7:56] <philmaker> have HopObjects handle URL requests
[7:56] <philmaker> 2. have HopObjects represent user data under the User HopObject
[7:56] <philmaker> but they are separate
[7:56] <philmaker> Re: so one user can have multiple data stores
[7:56] <zumbrunn> right
[7:57] <zumbrunn> you could do that
[7:57] <philmaker> or I could?
[7:57] <philmaker> what's the other alternative?
[7:57] <philmaker> the S3 thing?
[7:58] <zumbrunn> personally, I wouldn't go down the road of attaching the content directly to the user
[7:58] <philmaker> We can stop talking about this topic if you want - because I can mostly work around it all and do my own thing initially
[7:58] <philmaker> itr would be data - not content
[7:58] <philmaker> data from post requests
[7:58] <philmaker> that's all I am doing
[7:59] <zumbrunn> right, still data == content
[7:59] <philmaker> and the entire scope and abilitues of HopObjects perhaps are making this difficult to understand
[7:59] <philmaker> well, data == content in the cspe of the xml database
[7:59] <philmaker> well, data == content in the scope of the xml database
[8:00] <zumbrunn> yep
[8:00] <philmaker> I plan to use the XML database to lazily persist data without needing to connect a database
[8:00] <zumbrunn> yes, good
[8:01] <philmaker> I wrote a little article here...
[8:01] <philmaker> I'm is totally unpolished and I wrote much of this while I was busy doing other thingd at my job...
[8:02] <philmaker> http://dev.helma.org/wiki/Workspace/philmaker/HopObjects+Explained/
[8:02] <philmaker> It's very rought and I haven't even looked at it for several hours to complete.
[8:04] <philmaker> You can tell me if I am smoking crack
[8:05] <philmaker> http://en.wikipedia.org/wiki/Crack_cocaine
[8:07] <zumbrunn> well, it's at least very helpful to see the thought patterns of new users
[8:07] <zumbrunn> it's crucial for improving the docs
[8:07] <philmaker> feel free to critique any misunderstandings
[8:07] <philmaker> brb
[8:10] <zumbrunn> what made you think you have to call persist()?
[8:11] <zumbrunn> in the case you describe, you wouldn't need to call persist
[8:11] <zumbrunn> if the hobj is attached to an already persisted hobj, it will be automatically persisted
[8:12] <zumbrunn> only hobj that are not attached are transient and would need to be persisted using persist
[8:13] <zumbrunn> (or attached to an already persisted hobj, which would be the normal situation)
[8:15] <philmaker> I understand this: if the hobj is attached to an already persisted hobj, it will be automatically persisted
[8:15] <philmaker> maybe I need to review what I wrote...
[8:16] <zumbrunn> like I said before, I think the approach of directly attaching data to the user object is borked
[8:16] <philmaker> I think I understand correctly that you only need to call persist() if you update values on a HopObject or an object which extends HopObject
[8:16] <zumbrunn> I'm quite confidant that storing the data separate and relating it to the user is better
[8:17] <philmaker> What I like about Helma really is that it had this XML database
[8:17] <philmaker> for what I mentioned earlier about being able to sort of lazily persist data without needing to connect to a SQL database, etc
[8:18] <philmaker> Really just for development purposes - when the develeoper might be more focused on the client side of things
[8:18] <zumbrunn> no, you don't need to call persist f you update values on a HopObject or an object which extends HopObject
[8:18] <philmaker> so only call persist if it is not in the root chain?
[8:18] <zumbrunn> right
[8:18] <zumbrunn> which means usually never
[8:20] <philmaker> I have started working on a simple JSON AJAC example - it's small so far ~20 lines
[8:20] <philmaker> for the JSON get request
[8:21] <philmaker> I also started working an HttpRequestObject POST request - but so far I'm not seeing what I posted in...
[8:22] <philmaker> but so far I'm not seeing what I posted in req.data nor in req.postParams
[8:22] <philmaker> I may need to review how the transaction is supposed to work - it's been awhile
[8:22] <philmaker> Hello hannes
[8:22] <philmaker> right now I am seeing nothing in the post data
[8:23] <philmaker> I should probably ignore the AJAX for now and work on a simple, normal form POST request
[8:23] <zumbrunn> the ajax one should work fine though
[8:24] <zumbrunn> use the pastbin if you like to share the code that you are trying to get working
[8:24] <zumbrunn> http://helma.pastebin.com/
[8:27] <philmaker> I probably just need to review/understand how the HttpRequestObject works more
[8:28] <philmaker> Here is the only line I have in jsonpost.hac
[8:28] <philmaker> res.write(req.postParams);
[8:29] <philmaker> maybe the issue is just that I am trying to post raw data over HttpRequestObject instead of key/value pairs
[8:29] <philmaker> but I have tried both
[8:29] <zumbrunn> not sure how postParams serializes to a string
[8:29] <philmaker> hmmm
[8:29] <philmaker> I am simply passing a JSON object
[8:30] <philmaker> with no name/value
[8:30] <zumbrunn> what are the names of the params you send?
[8:30] <philmaker> hehe
[8:31] <zumbrunn> what are you using on the client side?
[8:31] <philmaker> I tried two options: 1. helma=true 2. <just the JSON text>
[8:31] <philmaker> but nothing appeared in session postParams
[8:31] <zumbrunn> session postParams?
[8:31] <philmaker> I can probaly solve this on my own
[8:31] <philmaker> maybe I should try...
[8:32] <philmaker> maybe I should try simple req.get
[8:33] <zumbrunn> if you send helma=true then res.write(req.data.helma) should write "true"
[8:33] <zumbrunn> both for GET and POST
[8:35] <zumbrunn> req.postParams should serialize fine, btw
[8:35] <zumbrunn> just tried it
[8:35] <zumbrunn> so, you should be seeing what you are looking for
[8:35] <philmaker> I will try that
[8:36] <philmaker> did you try that for an AJAX post or a regular post?
[8:36] <zumbrunn> both
[8:37] <zumbrunn> what did you get when you used res.write(req.postParams); ?
[8:38] <philmaker> PasteBin coming up
[8:39] <philmaker> This could just be a problem maybe in this client source page perhaps
[8:39] <philmaker> http://helma.pastebin.com/d978d23b
[8:40] <philmaker> and the only line I have in jsonpost.hac is: res.write(req.data.helma);
[8:40] <philmaker> My intent is to be able to POST JSON data
[8:40] <philmaker> but right now I am just trying with helma=true
[8:41] <zumbrunn> afk brb
[8:41] <philmaker> k
[8:45] <philmaker> maybe I'm not sending enough header info - that may be all
[8:45] <philmaker> enough/any
[8:47] <philmaker> Re: res.write(req.postParams);
[8:47] <philmaker> opps
[8:47] <philmaker> Re: what did you get when you used res.write(req.postParams); ?
[8:48] <philmaker> either empty or 2. {} I think when I posted JSON text alone
[8:49] <philmaker> I might be doing something screwy here - like I might need more header info the the POST request
[8:50] <philmaker> I'm probably signing out here shortly....
[8:57] <philmaker> I did get the basic form post to work OK - I'm just having trouble with my AJAC post at http://helma.pastebin.com/d978d23b
[8:57] <philmaker> probably just headers
[8:58] <philmaker> I'm piecing together scarps of HttpRequestObject code from online - because I haven't done AJAX transitions in awhile
[8:58] <philmaker> scraps
[8:59] <philmaker> sorry about all my typos - I'm tired. I Sierra Nevada isn't helping either. Sorry.
[9:07] <philmaker> New thought: Would be cool if Helma supported servlet filters. That way I could post any data to any random url - and have the posted data persist in the internal XML database at that same branch but under the User HopObject
[9:08] <zumbrunn> yeah, with the version you put in the pastbin I get nothing either
[9:08] <philmaker> e.g. lazy posting of data under an User but no HopObject structure needs to be in place the actually handle the request
[9:09] <zumbrunn> you could do this using getChildElement
[9:09] <zumbrunn> http://helma.zumbrunn.net/reference/HopObject.html#getChildElement
[9:10] <philmaker> If you have any JS code which is posting the AJAX request correctly, can you email that to me?
[9:11] <philmaker> very cool
[9:12] <philmaker> Again, I so appreciate Helma for what it is and what it is designed to be. But I'm initially interested in implementing something lazy for handling AJAX gets and post requests during the development process.
[9:12] <zumbrunn> take a look at the source of the shell
[9:12] <philmaker> And Helma's internal XML database seems ideal for this.
[9:13] <zumbrunn> http://helma.zumbrunn.net/tools/about_shell
[9:13] <philmaker> Thinking about the lines CouchDB perhaps initially
[9:13] <philmaker> Thinking along the lines CouchDB perhaps initially
[9:14] <zumbrunn> http://helma.pastebin.com/m48de1b63
[9:14] <philmaker> If you have any JS code which is posting the AJAX request correctly and you can separate it from your own work, can you email that to me?
[9:14] <philmaker> signing out....
[9:14] <philmaker> oh thanks
[9:15] <philmaker> looks very nice - I'll check it out
[11:00] <zumbrunn> I updated http://helma.zumbrunn.net/reference/toolkit/ with what I currently get from the doc code files as they are right now
[13:21] <kuccello> Looking at the code from both pastebins I am wondering why you don't use a javascript lib like prototype or scriptalicious or rico or moofx for your ajacx calls?
[13:21] <kuccello> http://www.prototypejs.org/
[13:21] <zumbrunn> or jquery
[13:21] <zumbrunn> right
[13:22] <kuccello> I remember doing the calls manually like that and it was always slow and painful
[13:22] <zumbrunn> painful, anyways
[13:22] <kuccello> yep
[13:23] <kuccello> I'm back on writting a blog engine in helma now that I finihsed launching prewonedvehicles.com I can devote some more time to my helma learning experience
[13:25] <kuccello> btw: we have decided to start holding regular Ajax (pending a name change) PubNites for developers in Toronto - and at the next Democamp there will be a demo of helma
[13:26] <zumbrunn> cool!
[13:26] <kuccello> I thought youd like that, I'll see about getting some video up on youtube when it happens
[13:26] <zumbrunn> :-)
[15:06] <Ar34n7> hi
[15:07] <zumbrunn> hi
[15:07] <Ar34n7> I would like to make a question which answer can't see at http://dev.helma.org
[15:07] <Ar34n7> possibly because i didn't look for it fine
[15:08] <Ar34n7> Is there an "official" date of release of Helma 2.0?
[15:08] <Ar34n7> Please, excuse me for my poor english ;)
[15:08] <zumbrunn> no, nothing concrete
[15:08] <Ar34n7> ah, ok
[15:09] <zumbrunn> what do you think you need 2.0 for?
[15:09] <Ar34n7> I was translating a Linux Magazine article about Helma ilustrating an example of RSS reader
[15:09] <Ar34n7> where it is said that it was planned for 2007
[15:10] <zumbrunn> ah, ok
[15:10] <Ar34n7> I guess it will be edited next month, so
[15:10] <zumbrunn> the reason why there is no concrete schedule for 2.0 is that we currently do not see an urgent need for it
[15:10] <Ar34n7> it doesn't make too much sense to say that is will be released on 2007 :)
[15:10] <zumbrunn> some things that were intended for 2.0 already went into 1.6
[15:11] <zumbrunn> nope, definitely not
[15:11] <Ar34n7> fine, I'll make my own modifications to clarify that
[15:11] <kuccello> http://www.helmablog.com/?p=13
[15:12] <Ar34n7> Yes, that's it
[15:12] <Ar34n7> He said that database auto-generation will be included on 2.0
[15:12] <Ar34n7> But i will not tell anything about that, just
[15:13] <zumbrunn> that's been discussed for 2.0, yes
[15:13] <Ar34n7> the part related to the new release
[15:13] <Ar34n7> I paste you the content of the menttioned paragraph
[15:13] <Ar34n7> 1 sec
[15:13] <zumbrunn> but since then there have been some experiments that would bring this kind of functionality already to 1.x
[15:13] <Ar34n7> fine
[15:14] <Ar34n7> Looking Ahead
[15:14] <Ar34n7> The new 2.0 version of Helma is sched-
[15:14] <Ar34n7> uled for release in 2007. The Helma 2.0
[15:14] <Ar34n7> project is a complete rewrite. The devel-
[15:14] <Ar34n7> opers intend to keep the strengths of the
[15:14] <Ar34n7> 1.0 line and take insights from many
[15:14] <Ar34n7> years of deployment into consideration.
[15:14] <Ar34n7> New scripting, extended skins and tem-
[15:14] <Ar34n7> plates, and the capabilities of newer ver-
[15:14] <Ar34n7> sions of the Rhino JavaScript implemen-
[15:14] <Ar34n7> tation are the main focuses of Helma 2.0.
[15:14] <Ar34n7> -------------------
[15:14] <Ar34n7> I could just supress the first two lines
[15:15] <kuccello> ?
[15:15] <zumbrunn> yeah, it's all still true
[15:15] <zumbrunn> just that the lines between 1.x and 2.x got blured
[15:15] <Ar34n7> fine
[15:16] <zumbrunn> from the functionality point of view, the direction hasn't changed
[15:17] <Ar34n7> Maybe just changing 2007 for "ina future"
[15:17] <Ar34n7> and just as a possiblity
[15:17] <Ar34n7> withiut any solid promise
[15:17] <Ar34n7> without*
[15:17] <Ar34n7> That way i would touch the minimum possible
[15:17] <zumbrunn> instead of talking about 2.0, it should probably just talk about "future versions"
[15:18] <zumbrunn> that's really the only difference
[15:18] <Ar34n7> yeah, perfect. I'll review the whole article for possible quotings.
[15:20] <Ar34n7> Fine, thank you very much. See you ;)
[19:07] <midnightmonste1> just me stumping for E4X for "skins" again: http://helma.pastebin.com/d709c2c16
[19:54] <kuccello> i'll check it out - do you have a site with more info?
[20:11] <midnightmonste1> not really
[20:12] <midnightmonste1> don't have a blog yet, and mostly too busy working to write about working :-(
[20:14] <midnightmonste1> I started to do a dev log on the first helma site I built. didn't finish (the log--the site was finished), but you might still find some useful things.
[20:14] <midnightmonste1> http://letterblock.com/intheopen
[22:22] <zumbrunn> to be fair, these days one could define an onUnhandledMacro in order to handle the undefined macro problem you mention in the pastebin
[22:23] <midnightmonste1> I figured that was the case.
[22:23] <zumbrunn> but I'm the first one to say e4x is the way to go!
[22:27] <zumbrunn> to bad you didn't follow through with the intheopen work log, btw
[22:27] <zumbrunn> I was looking forward to that
[22:27] <midnightmonste1> I know... sorry. I published a couple more entries that I hadn't published yet, but ..
[22:28] <zumbrunn> oh, I didn't go and check...
[22:31] <midnightmonste1> what I love about Helma and javascript is how I can make self-contained bits of functionality that fit on a (fairly large) screen but improve my app in significant ways. like my CSRF thing is 56 lines. and I call it with one line in my template manager (60 lines) and it solves CSRF for every form on every app I make forever.
[22:35] <midnightmonste1> the realtime filter/search on http://preachingtheword.net/sermons is 37 lines. it takes advantage of jQuery but could easily be rewritten without it in about the same # of lines.
[22:35] <zumbrunn> flexibility reduced to the max
[22:36] <midnightmonste1> err-right
[22:37] <midnightmonste1> also, mostly unrelated, myisam is super lame for even slightly large data sets, and innodb rocks in comparison.
[22:37] <midnightmonste1> (of mysql storage engines)

 

 

In the channel now:

Logs by date: