Hopbot log for 2008-06-22 - Helma IRC channel: #helma on irc.freenode.net

2008-06-22:

[5:50] <zumbrunn> groovah, .hac files are specific for the definition of actions, the functions that handle url requests
[5:51] <zumbrunn> they are a shortcut and replace a function definition that you would otherwise put in a .js file like this:
[5:51] <zumbrunn> function foo_action(){...}
[5:51] <zumbrunn> see here: http://helma.zumbrunn.com/intro/actions
[5:52] <zumbrunn> it's just a convention
[5:53] <zumbrunn> if you'd want, you could write apps with only .js files and no .hac files
[5:56] <zumbrunn> re: the tutorial at http://helma.org/docs/tutorial/ ...that's already a bit further advanced in the sense that it includes mapping prototypes to relational databases, which you wouldn't necessarily need to do for a simple app
[5:57] <zumbrunn> re: the helpers for form validation, macros would effect what you output in skins, so this might be right if you mean client-side form validation
[5:58] <zumbrunn> for server-side form validation you would do the checking in the action that handles the form submission
[6:29] <groovah> thanks zumbrunn
[6:30] <groovah> I appreciate it
[18:53] <groovah> I'm noticed hopObjects have size() and count() attributes return the same info. Can length() be added to that too?
[19:12] <zumbrunn> groovah, sure, if you want that, you can easily do this:
[19:12] <zumbrunn> HopObject.prototype.length = HopObject.prototype.count;
[19:14] <groovah> touche, thanks
[19:15] <zumbrunn> :-)
[19:15] <groovah> If I wanted that to be universal across the project, does it matter where I put that in the code?
[19:15] <zumbrunn> no, in any js file
[19:16] <zumbrunn> but I assume it makes the most sense in a file inside a HopObject subdir
[19:16] <zumbrunn> or if you would have to create that specifically for this purpose, in the Global subdir
[19:19] <groovah> Do large Helma projects get confusing if there are many types of models? Has anyone ever found the experience of having many directories confusing, or are there different strategies to organize projects?
[19:20] <zumbrunn> there are probably different opinions on that
[19:21] <zumbrunn> that to many type folders gets to confusing, I have heard less than the "problem" of to many action .hac files
[19:22] <zumbrunn> that's why some prefer to define all their actions inside one actions.js file, using the function foo_action(){...} syntax
[19:23] <zumbrunn> but you *could* do that with prototypes as well
[19:23] <zumbrunn> taken to the extreme, you could have your entire app code inside one js file in the Global subdir of your app
[19:35] <groovah> zumbrunn, how would you do that with prototypes? What would it look like? I thought they required folders.
[19:36] <zumbrunn> in the case of the above, you would put that line of code inside a file like ./apps/myapp/Global/foo.js
[19:37] <zumbrunn> to create other custom prototypes you would create them using standard js syntax and make them inherit from HopObject
[19:39] <zumbrunn> function MyProto(){}; MyProto.prototype = new HopObject();
[19:42] <groovah> ok, that's definitely something I'll need look into
[19:43] <zumbrunn> why? how many types are you planning to have in your app?
[19:50] <zumbrunn> one example of an app with quite a large amount of types is antville
[19:50] <zumbrunn> http://code.google.com/p/antville/source/browse/trunk/code/
[19:52] <decke> that is much?
[19:52] <zumbrunn> hehe
[19:52] <zumbrunn> the most I could find right now in a public repository
[19:52] <decke> the new c3k community has about 70 prototypes and not finished yet... am i doing something wrong or is it just big?
[19:53] <zumbrunn> it's just big ;-)
[19:53] <decke> *g* okay then i can leave it as it is...
[19:54] <zumbrunn> I certainly don't think it would get easier to keep the overview one would stick all that into one file
[19:54] <decke> no but subdirectories would be an improvement
[19:55] <zumbrunn> rather, if anything, it might make sense to break things up into different "modules" and include them as separate repositories
[19:55] <zumbrunn> you can have subdirectories, no problem!
[19:56] <zumbrunn> don't remember exactly, but probably since around Helma version 1.5
[19:56] <decke> i am thinking what that would give me...
[19:56] <decke> most of the time i am only working on an "topic" that touches about 5 to 10 prototypes
[19:56] <groovah> Thanks for the antville link. I'll look at that and see what I can learn. Sometimes I think its good to read code especially when you are learning. :)
[19:57] <decke> so i create an Eclipse working set for that
[19:57] <decke> that works most of the time...
[20:06] <groovah> For full-text searches we would probably use custom sql, right?
[20:06] <decke> or you use Apache Lucene ...
[20:07] <decke> that has an helma wrapper somewhere... helma.Search or something
[20:07] <zumbrunn> http://helma.zumbrunn.com/reference/helma.Search.html
[20:07] <zumbrunn> http://helma.zumbrunn.com/reference/jala.IndexManager.html
[20:20] <decke> does anyone know if there are FreeBSD users that use Helma?
[20:20] <zumbrunn> me
[20:20] <decke> or am i the only one?
[20:20] <zumbrunn> nope
[20:20] <decke> you are a FreeBSD user? *g* wow - i thought i am alone
[20:20] <zumbrunn> hehe
[20:21] <decke> i am currently writing some ports for freebsd ...
[20:21] <decke> would a helma port make sense?
[20:22] <zumbrunn> sure!
[20:22] <zumbrunn> why not?
[20:22] <decke> now that we are two... that would make sense yes *g*
[20:22] <zumbrunn> lol
[20:22] <decke> at least for one of us
[20:23] <decke> but i was not sure if all of you use linux and windows... and have ever heard of BSD
[20:23] <decke> and the user and developer group of helma looks pretty small... so i was not sure
[20:24] <decke> but yeah one more port doesn't hurt me *g*
[20:24] <zumbrunn> for the existing users it probably wouldn't make much sense
[20:25] <zumbrunn> the idea would be more to make it more attractive for other bsd users that are new to helma
[20:26] <decke> yes and for better integration in FreeBSD systems that act as helma servers...
[20:26] <decke> currently i don't know such a system.. but maybe there is one out there..
[20:27] <zumbrunn> not sure what you mean with that
[20:27] <decke> all our boxes at c3k are debian and you know...
[20:27] <zumbrunn> oh, for me it's the other way around
[20:27] <decke> so you have freebsd helma servers too?
[20:27] <zumbrunn> I use freebsd on the server only
[20:28] <decke> what a lucky guy you are...
[20:28] <zumbrunn> macosx as the workstation os
[20:28] <decke> with java/jdk16?
[20:29] <zumbrunn> not yet, just the diablo 1.5jre right now
[20:29] <decke> there is a java/diablo-1.6 coming from the freebsd foundation... as a precompiled binary for FreeBSD 7.0
[20:30] <zumbrunn> yes, that's what I'm waiting for
[20:30] <decke> AFAIK from our box the jdk16 is performing way better under high load...
[20:41] <groovah> Helma has a scheduler function !(?)
[20:42] <zumbrunn> http://helma.zumbrunn.com/reference/app.html#app.addCronJob
[20:44] <groovah> Helma seems to have thought of everything. Wow.
[20:44] <zumbrunn> it's quite mature
[20:45] <groovah> I'm surprised it doesn't get the popularity as it deserves
[20:45] <decke> yes and everything that is missing can easily be used thru "var = new Packages.your.package.Class();"
[21:01] <groovah> Do you have to download jala seperately?
[21:05] <groovah> Ah, i had an older version of Helma running that did not ship with it. Nevermind.

 

 

In the channel now:

Logs by date: