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

2007-11-19:

[0:31] <philmaker> So I think some simple standalone AJAX examples will be useful.
[0:32] <philmaker> E.g. the problem I'm having with toJSON() now - the fact that writing an object to XML for an AJAX request requires Jala, etc
[0:32] <philmaker> Ideally I want to get some simple AJAX requests working with Helma alone and the internal database.
[0:33] <philmaker> Then I might move on to Rabbit/Rocket and maybe Junction some. The Junction project needs some organizational improvement it seems. I'm looking at Junction too eventually in case I want to use Gears.
[3:19] <philmaker> Hi Christoph - it's probably in the middle of the night for you right now - I have some more thoughts....
[3:20] <philmaker> I think a document "Helma in a nutshell" would be nice to have...
[3:20] <philmaker> I did create an account on helma.org but I don't see how to add a page in the wiki so far....
[3:21] <philmaker> Initially I'd be interested in writing "Helma in a Nutshell" and "Helma for AJAX (using internal XML/HopObjects)"
[3:23] <philmaker> Here is my goal for using Helma atm: I am also ramping up using ExtJS and I would like to focus on the client side and somewhat lazily develop the server-side.
[3:23] <philmaker> I suppose Filemaker, Inc. comes to mind as an influence.
[3:24] <philmaker> Couck DB comes to mind as an influence.
[3:24] <philmaker> Sorry, CouchDB comes to mind as an influence.
[3:26] <philmaker> Also, here is another though regarding client-driven web development: when I am working on my computer and go to save a document and it does not exist, my Mac offers to saveas/ create a new file. For client-side driven web development, I wish the development process where as simple as that. If an appropriate table/database/file can not be found to handle an AJAX post request, have Helma, etc offer to CRUD it for you.
[3:27] <philmaker> All of this may relate more to Rabbit/Ricket/Junction, etc so far maybe
[3:27] <philmaker> er: Rocket
[3:48] <philmaker> Sidenote: I'm a little confused about the usage of HopObjects. For instance, in the primary demo, there is a 'HopObject' directory. Is it necessary in this primary demo that the folder 'HopObject' be named 'HopObject'? If this is not the case, that it is named 'HopObject' might be a source of confusion for many. If it is indeed necessary to name that folder 'HopObject', is it simply extending the definition of a HopObject?
[3:50] <philmaker> I understand that HopObjects can be used primarily as hierarchical page request mappings - however I don't quite understand how their secondary use: containing data and persisting data (internal XML database for example) relates to their nature for hierarchical page requests.
[3:59] <philmaker> I figured out how to create a wiki page - doh duh
[7:01] <philmaker> I'm starting to do some work here: http://dev.helma.org/wiki/Workspace/philmaker/list
[7:01] <philmaker> I made my own little workspace to do drafts and brainstorming
[7:26] <zumbrunn> hi philmaker
[7:26] <zumbrunn> the wiki workspace is a good idea
[7:27] <philmaker> HI - I've been busy...
[7:27] <philmaker> just so I don't barf all over the wiki until I'm finished with my articles
[7:27] <zumbrunn> I have to first go get a cup of coffee, but I'll be right back and read through the log....
[7:28] <philmaker> I sent you some emails too. Enjoy the coffee first.
[7:28] <philmaker> I'm up late again tonight (Sunday night for me 1:30am)
[7:29] <philmaker> probably going to bed at 3 or 4...
[7:31] <philmaker> brb
[7:47] <philmaker> Anyway - you don't have to reply to those emails I sent you - they are a little offtopic. The issues I'm working on are in here (IRC) and in my wiki pages.
[7:48] <zumbrunn> I got the mails, thanks!
[7:49] <zumbrunn> the HopObject directory *does* need to be called "HopObject"
[7:49] <zumbrunn> so, yes, it extends the built-in HopObject prototype
[7:51] <zumbrunn> on one side, hopobjects map to a db, on the other side they map to the URL request
[7:52] <zumbrunn> with the combination of the two, you get an indirect mapping from the url to the data stored in the db
[7:52] <zumbrunn> so, the two aspects do relate to each other, no?
[8:02] <philmaker> hi
[8:04] <philmaker> thanks
[8:05] <philmaker> I have a few other questions - some of these are in my pages. Here we go...
[8:07] <philmaker> when there is a *.js file, where is that code normally being called from? Are those just functions which get loaded which you can call from a hac?
[8:07] <philmaker> Why not define them inside the hac? So they can be shared?
[8:07] <philmaker> BTW, let me know if you are busy atm....
[8:10] <philmaker> also, where is the global directory documented? For instance, the main example has a file called init.js which has an onStart function. Is this documented somewhere? Also, the helmaTools.zip has a Global directory I noticed. What does the Global directory provide in these examples? I do understand the general concept of global btw. :-)
[8:13] <philmaker> Global is documented here: http://helma.zumbrunn.net/reference/core/global.html
[8:13] <philmaker> D'oh
[8:13] <philmaker> So I've seen directories for HopObject and Global.
[8:15] <philmaker> If I were to create a directory in an app called Response, would it "extend" the Helma response proptype? Or the Image or Database protptype for that matter?
[8:16] <zumbrunn> yes, a function inside a hac would just live inside the closure of the action function generated by the hac
[8:16] <zumbrunn> that can be useful, I guess, but the "normal" way is to keep the code inside the hac to a minimum
[8:16] <philmaker> cool
[8:17] <philmaker> If I were to create a directory in an app called Response, would it "extend" the Helma response proptype? Or the Image or Database protptype for that matter?
[8:17] <philmaker> Sorry for repeating...
[8:18] <zumbrunn> I believe HopObject is treated specially
[8:18] <philmaker> And again with mispellings corrected d'oh: If I were to create a directory in an app called Response, would it "extend" the Helma response prototype? Or the Image or Database prototype for that matter?
[8:19] <zumbrunn> I don't remember if I ever tried it with String or Array
[8:19] <zumbrunn> but I suspect it wouldn't work
[8:19] <philmaker> I'm just trying to get a feel for this - so HopObject and Global are the primary API prototypes which can be "extended"
[8:19] <philmaker> ?
[8:19] <zumbrunn> Also, even if that works, Response is a javabean, it might not work because of that
[8:19] <philmaker> thanks
[8:19] <zumbrunn> the same with Database, Image, File etc
[8:20] <zumbrunn> actually, Repsonse doesn't exist at all
[8:20] <zumbrunn> there is only res which is an instance of the Repsonse javabean
[8:20] <zumbrunn> but there is to Response prototype anywhere
[8:21] <philmaker> Can a session have it's own HopObjects?
[8:21] <philmaker> Meaning: a user is going to have their own data to persist. Can a user/session have its own root HopObject?
[8:21] <philmaker> (I'm almost done.) :-)
[8:22] <zumbrunn> A user can for sure, since a user is a hopobject
[8:22] <philmaker> woot
[8:22] <zumbrunn> the session itself, I'm not sure
[8:22] <philmaker> let me look at that
[8:22] <philmaker> in the api baby!
[8:22] <zumbrunn> session.data.foo = new HopObject()
[8:23] <zumbrunn> don't know how that would behave exactly
[8:24] <philmaker> for for persistent data: best to use session.user (HopObject) and not session.data because session data does not persist. Righto?
[8:24] <zumbrunn> session.user is just a reference to the user's hopobject
[8:25] <zumbrunn> session.data wouldn't persist, no
[8:25] <zumbrunn> hence the name session ;-)
[8:25] <philmaker> thanks
[8:26] <zumbrunn> seriously... session.data is just intended as the object to make properties available to skins
[8:26] <philmaker> Also if you're felling like having some fun: can you think of why toJSON is now working for me. See above
[8:27] <zumbrunn> session.data.foo becomes <% session.foo %> in skins
[8:27] <philmaker> cool
[8:28] <philmaker> BTW, I am familar with the servlet API and lots of Java web frameworks - but I'm mainly Java on the desktop lately
[8:28] <zumbrunn> maybe the code that adds that repository wasn't in place yet when you first tested it
[8:29] <zumbrunn> are you sure you included the JSON.js repository file somehow?
[8:29] <philmaker> checking...
[8:30] <philmaker> But JSON.js is in modules/core - I don't understand that I have to include anything...
[8:30] <zumbrunn> yes, you do...
[8:30] <philmaker> ah
[8:30] <zumbrunn> any code in modules is optional
[8:30] <philmaker> I promise all of this will go into my articles :-)
[8:30] <philmaker> where do I do that?
[8:31] <zumbrunn> either in app.properties or using app.addRepository()
[8:32] <zumbrunn> http://helma.zumbrunn.net/intro/applications
[8:32] <philmaker> hehe
[8:32] <philmaker> intro
[8:33] <zumbrunn> http://helma.zumbrunn.net/reference/app.html#addRepository
[8:34] <philmaker> what may have thrown me off is that when I altered Object.js in modules/core, it saw that even though I apparently did not have modules/core as a defined repository.
[8:35] <zumbrunn> maybe you included some other repository that in turn requires Object.js
[8:35] <zumbrunn> this is all not perfect, we know
[8:36] <philmaker> This is all helping tremendously...
[8:36] <philmaker> Do you feel like one more small question?
[8:37] <zumbrunn> sure
[8:37] <philmaker> when an action file is named main.hac....
[8:38] <philmaker> does it need to be named main to be the default action for that HopObject?
[8:38] <zumbrunn> yes
[8:39] <philmaker> OK thanks Christoph - I will study the API more. I have been looking at the examples and the primarily documentation - I think looking at the API will help too
[8:40] <philmaker> When I have some more questions I'll probably put them in my workspace...
[8:40] <zumbrunn> ok
[8:41] <philmaker> Oh but I thought of another
[8:42] <philmaker> If a user has their own HopObject via session.user, why would the application's HopObject ever need to persist?
[8:43] <philmaker> Wouldn't an application's root object be just for handling hierarchical page requests?
[8:44] <zumbrunn> User objects are attached to the root as well
[8:44] <philmaker> Maybe the application's root object could be used for shared data?
[8:45] <philmaker> Maybe I'm not really grasping why HopObjects handle data and persistence but also page hierarchy as well
[8:46] <philmaker> If you coudld expand on "with the combination of the two, you get an indirect mapping from the url to the data stored in the db"
[8:48] <zumbrunn> trying to think of the simplest example...
[8:49] <zumbrunn> http://helma.zumbrunn.net/first/second/hallo/
[8:50] <philmaker> I'll study it more.
[8:50] <zumbrunn> not sure if that's a good example
[8:51] <philmaker> I guess I'm not understanding the relation between using HopObjects for application-wide page requests and 2. using HopObjects for persistence of user data
[8:51] <zumbrunn> but basically, when you create hopobjects there, they are "created" both in the URL and in the db
[8:51] <zumbrunn> so, I guess in a way that does work as an exmaple
[8:52] <zumbrunn> Actually, I do want to extend the welcome app to cover that area
[8:52] <philmaker> when the are created in the db, are they automatically created in a separate space for each user?
[8:52] <philmaker> when they are created in the db...
[8:53] <philmaker> (BTW, you can tell me to RTFM at any time)
[8:53] <philmaker> hehe - I have been
[8:54] <zumbrunn> if you play with http://helma.zumbrunn.net/first/second/ in your local install
[8:54] <zumbrunn> (it's part of the welcome app)...
[8:54] <philmaker> right
[8:54] <zumbrunn> you can watch what helma does when you create new hopobjects
[8:55] <zumbrunn> in the ./db/welcome/ directory
[8:55] <philmaker> maybe digging into the structure of the xml files might help me some too
[8:55] <philmaker> righto
[8:55] <zumbrunn> 0.xml is the root object
[8:56] <philmaker> I have looked around there - I will look harder
[8:56] <zumbrunn> afk for a moment... brb
[8:56] <philmaker> I'll be signing off for the evening soon...
[9:00] <philmaker> Thanks for chatting.
[9:01] <philmaker> And for helping me get up to speed.
[9:09] <zumbrunn> back...
[9:10] <zumbrunn> taking the simple hopobject code in the welcome app as an example...
[9:11] <zumbrunn> when bringing users into this, I think I would add a property to the hopobjects that would point to the user that created the object
[9:11] <zumbrunn> like an author property
[9:12] <zumbrunn> then, if the session.user matches the author property, I could allow the user to edit an existing hopobject
[9:13] <zumbrunn> on the phone...
[9:25] <zumbrunn> back...
[9:26] <zumbrunn> in other words, in many cases, you *would* have the data in a shared space
[9:26] <zumbrunn> both when storing it and when making it accessible through the URL
[9:27] <zumbrunn> and how it relates to users would be based on properties
[9:29] <zumbrunn> even if you have separate url spaces for specfic users, that would relate mainly to *which* data is accessed
[9:30] <zumbrunn> *how* it is access depends on the access rights you want to give the particular user that accessed the data
[9:31] <zumbrunn> I'm not sure exactly where you are thinking about the content/user relationship in a different way
[9:32] <zumbrunn> maybe it depends on how RESTful the app should be structured
[9:39] <philmaker> I've been reading all sorts of more Helma docs...
[9:40] <philmaker> This is nice: http://dev.helma.org/static/files/1577/dancer-anim.gif
[9:40] <zumbrunn> lol
[9:40] <zumbrunn> that's Helma ;-)
[9:40] <zumbrunn> "die alte dame"
[9:41] <zumbrunn> although she doesn't look that old, really
[9:41] <philmaker> hehe
[9:41] <philmaker> lol
[9:42] <philmaker> the old lady
[9:42] <philmaker> http://babelfish.altavista.com/tr
[9:42] <philmaker> :-)
[9:43] <philmaker> I speak a little Français - but it has been some time
[9:43] <zumbrunn> babelfish to the rescue
[9:43] <philmaker> I traveled the France when I was in high school on a school trip
[9:43] <philmaker> to France
[9:44] <zumbrunn> that's quite a far venturing school trip!
[9:44] <philmaker> yep
[9:46] <zumbrunn> anyway... does the whole hopobject/url/db/user relationship make any more sense already?
[9:48] <philmaker> let me reread your last comments....
[9:48] <philmaker> I think it will....
[9:52] <zumbrunn> http://web.archive.org/web/20000829140639/http://helma.org/
[9:52] <zumbrunn> notice the missing image on the bottom left ;-)
[9:53] <philmaker> When you discuss "when bringing users into this, I think I would add a property to the hopobjects that would point to the user that created the object - like an author property" it almost sounds like an example for a dynamic site/wiki/dynamic content
[9:53] <philmaker> ???
[9:53] <philmaker> "home of the Hop" - I love that
[9:53] <zumbrunn> dancer.gif == the unanimated version of dancer-anim.gif
[9:54] <zumbrunn> yes, that's kind of the example I meant
[9:56] <zumbrunn> maybe you should describe the use case that you are thinking about, where the way users relate to the data becomes more confusing
[9:58] <philmaker> I'll revisit the HopObjects later. I think fundementally that they are named HopObects could be part of the problem for me.
[9:58] <philmaker> lol
[10:02] <philmaker> I don't usually use IRC much - I found this application, Colloquy, which I downloaded before I came on #helma. It is quite nice.
[10:02] <philmaker> =http://colloquy.info/
[10:02] <philmaker> http://colloquy.info/
[10:03] <zumbrunn> maybe we should call the HopObjects instead SuperduperObject
[10:03] <zumbrunn> Colloquy is what I'm using as well
[10:03] <philmaker> cool
[10:03] <philmaker> ObjectFantastic!
[10:03] <philmaker> HopObject is good
[10:05] <zumbrunn> they are just special objects the sport some cool features that can be leveraged to super charge your web development
[10:05] <philmaker> word up!
[10:05] <philmaker> slang
[10:06] <philmaker> Thanks for all you help - I really am about to sign out.
[10:06] <philmaker> I'm currenyly doing my Helma and ExtJS research outside of my current daytime work.
[10:07] <philmaker> But I should have some days off later this week due to holidays in the US
[10:07] <philmaker> So I should be back soon.
[10:11] <philmaker> Maybe just maybe an analogy....
[10:11] <philmaker> relating to Java classes....
[10:12] <philmaker> For a HopObject, the path of a HopObject relates to a method of a Java class - and the data of a HopObject relates to a field of a Java class. ??
[10:13] <philmaker> Sorry if this is really basic.
[10:13] <philmaker> correction:
[10:13] <philmaker> For a HopObject, the path of a HopObject relates to a method of a Java class - and the data of a HopObject relates to a field of a Java object.
[10:13] <zumbrunn> the path of a HopObject?
[10:14] <philmaker> as it relates to a url path
[10:14] <zumbrunn> hmm
[10:14] <philmaker> er, name of a HopObject
[10:14] <philmaker> maybe not - maybe I'm off
[10:14] <philmaker> I'm just trying to do an analogy
[10:15] <philmaker> ignore it
[10:15] <philmaker> maybe
[10:15] <philmaker> later
[10:15] <zumbrunn> normally I'm telling people not the draw analogies between js prototypes and java classes, but in this case that would probably be the better analogy
[10:16] <philmaker> is my analogy somewhat correct?
[10:16] <zumbrunn> although that wouldn't help much regarding the way URLs play into it
[10:16] <philmaker> tell me later
[10:16] <philmaker> 'night
[15:38] <hypersmil> is there a planned release date for helma 1.7?
[15:41] <zumbrunn> hypersmil, my guess would be february 2007
[15:41] <zumbrunn> but that's just my guess
[15:42] <zumbrunn> february 2008 I mean, of course
[15:42] <zumbrunn> the roadmap claims it will be still in 2007
[15:43] <zumbrunn> but I could also see it slip beyond february 2008
[15:43] <zumbrunn> first, there should be a 1.6.1 with some bug fixes and small changes
[15:45] <hypersmil> is helma 2 still alive?
[15:45] <zumbrunn> yes, but there is no need for it right now
[15:46] <zumbrunn> most of the things that hannes thought require helma 2 have turned out to be achievable in helma 1.x
[15:47] <zumbrunn> helma 2 is ready for when we think we hit a wall with helma 1
[15:47] <hypersmil> helma 2 would be a complete rewrite?
[15:47] <zumbrunn> yes, pretty much
[15:47] <zumbrunn> a cleaned out fresh core
[15:48] <zumbrunn> http://dev.helma.org/source/browse/helma/trunk/
[15:50] <zumbrunn> the way we currently work, release dates are hard to predict
[15:51] <zumbrunn> often new ideas are introduces shortly before an "almost release"
[15:51] <zumbrunn> and the timeline shifts as a result
[15:52] <hypersmil> like the subskin feature in 1.6?
[15:53] <zumbrunn> not really so far...
[15:53] <zumbrunn> meaning I haven't used it yet
[15:53] <zumbrunn> have not seen the need
[15:53] <zumbrunn> which doesn't mean it's a bad feature
[16:14] <hypersmil> how did you create the helma reference docs?
[16:21] <zumbrunn> with jsdoc (a perl script) and the reference files in the svn repository...
[16:21] <zumbrunn> https://dev.helma.org/trac/helma/browser/apps/reference/trunk
[16:22] <zumbrunn> I'm right now changing it to work with the new rhino based jsdoc-toolkit
[19:13] <zumbrunn> hannes_, any idea what cause the endless loop problem when you tried to render the docs using jsdoc-toolkit?
[19:13] <zumbrunn> it seems to run through fine for me now
[19:14] <zumbrunn> it *will* need some tweaking, but mainly reversing changes that I had to make to work around jsdoc/perl problems before
[19:15] <zumbrunn> what it currently spits out I uploaded here...
[19:15] <zumbrunn> http://helma.zumbrunn.net/reference/toolkit/
[19:16] <zumbrunn> mainly, I need to change the way the app, res, req, etc objects are defined
[19:16] <zumbrunn> (currently they get swallowed completely)

 

 

In the channel now:

Logs by date: