Philip Weaver | 12 Nov 11:33
Picon

AJAX XML or JSON Questions, Examples?

Is the persistence of HopObjects in Helma automatic - are all HopObjects automatically saved to disk? Or upon a JSON or XML post request, do you have to manually copy data to the HopObject from the req and flush out via the XML object? Is there always one root object or does each user get their own root object? If each user/session gets it's own root HopObject, how is this reflected on disk?

I love the fact that application data can persist to disk without needing an SQL database but I'm still trying to wrap my head around it all. I really wish I could find more examples. I am really interested initially in using Helma for AJAX requests and would love more examples. If I do an HttpRequestObject post does the data automatically persist to a HopObject or so I have to do something?

Thanks,
Philip

_______________________________________________
Helma-user mailing list
Helma-user <at> helma.org
http://helma.org/mailman/listinfo/helma-user
Michael Platzer | 12 Nov 12:36
Picon

Re: AJAX XML or JSON Questions, Examples?

Philip Weaver schrieb:
> Is the persistence of HopObjects in Helma automatic - are all 
> HopObjects automatically saved to disk? 
Just if you call .persist() on that HopObject. Or if you pass it via 
.add() to an already persisted HopObject (just as root for example).
> Or upon a JSON or XML post request, do you have to manually copy data 
> to the HopObject from the req and flush out via the XML object?
You have to manually read out the data from post requests, and have to 
decide on your own what to do with them.
> Is there always one root object or does each user get their own root 
> object? If each user/session gets it's own root HopObject, how is this 
> reflected on disk? 
There is always just one root object.
> I love the fact that application data can persist to disk without 
> needing an SQL database but I'm still trying to wrap my head around it 
> all. I really wish I could find more examples. I am really interested 
> initially in using Helma for AJAX requests and would love more 
> examples. If I do an HttpRequestObject post does the data 
> automatically persist to a HopObject or so I have to do something?
You have to take care of that on your own, but Helma should provide 
enough flexibility to acchieve this quite easily.

greets,
  michi
Hannes Wallnoefer | 12 Nov 12:58
Picon
Favicon
Gravatar

helmaswarm 1.0 release

Hi there,

I just built and uploaded a new helmaswarm release.

http://adele.helma.org/download/helma/contrib/helmaswarm/

Guess what, it's 1.0. The only change compared to 1.0-b is the fix for
bug 536 <http://helma.org/bugs/show_bug.cgi?id=536>, and a minor
change in the standard UDP stack that makes testing on a single
machine easier by setting the port_range to 20.

have fun,
hannes
Kris Leite | 13 Nov 18:48

getCacheUsage suggestion

The Helma documentation indicates that getCacheUsage is the name to use 
to get the number of nodes in the application cache.  To use in a 
javascript function, the method uses getCacheusage().  It appears that 
either the documentation is incorrect or 'ApplicationBean.java' needs to 
be changed to capitalize the 'U' to so that getCacheUsage is defined.

Thanks,
Kris
Picon

__defineGetter__ for existing HopObject properties

Hi,

I can't use __defineGetter__ for properties of a HopObject, which are  
defined in type.properties, can I?
The first quick tests show that the getters or setters are ignored but  
I don't know if this is the way it's supposed to be...

Thanks!
Walter

Attachment (smime.p7s): application/pkcs7-signature, 2445 bytes
_______________________________________________
Helma-user mailing list
Helma-user <at> helma.org
http://helma.org/mailman/listinfo/helma-user
Joshua Paine | 20 Nov 19:10

Re: __defineGetter__ for existing HopObject properties

Walter Krivanek, VividVisions wrote:
> I can't use __defineGetter__ for properties of a HopObject, which are 
> defined in type.properties, can I?

Looks like no. Which is at odds with the treatment of standard 
properties. E.g., in Rhino and Firefox 2,

a = { a:'hi' };
a.__defineGetter__('a',function(){ return 'bye'; });
a.a;

the above code returns "bye". But apparently in Firefox 3 you'll have to 
delete a.a first before you can define a getter for it (which makes 
sense to me). I don't know if that works with HopObjects, and I also 
don't know if it would result in that property actually being deleted.

You can't access the stored value of the original property from the 
getter anyway, so trying to overload the actual property seems like a 
bad idea to me. In one case where I've needed a getter/setter (stored 
the value in the DB as an Int unix timestamp, wanted to work with it as 
a Date object) I just named the property .modified_ and wrote my getters 
and setters for .modified.

-Joshua
Chris Zumbrunn | 20 Nov 19:23
Gravatar

Re: getCacheUsage suggestion


On Nov 13, 2007, at 18:48 , Kris Leite wrote:

> The Helma documentation indicates that getCacheUsage is the name to  
> use
> to get the number of nodes in the application cache.  To use in a
> javascript function, the method uses getCacheusage().  It appears that
> either the documentation is incorrect or 'ApplicationBean.java'  
> needs to
> be changed to capitalize the 'U' to so that getCacheUsage is defined.

Thanks... for now, I'm fixing it in the documentation.

Chris
Breton Slivka | 21 Nov 12:50
Favicon

Invisible steamroller! Applescript+Helma

Hello all, I've been using helma for some weeks now, and I have come
up against a bit of a challenge which is stressing my rather limited
knowledge of Java.

My main goal is being able to execute an applescript from helma. I
know this is possible from Java- and is demonstrated in exhibit a:

http://www.oreilly.com/pub/a/mac/2003/02/25/apple_scripting.html?page=1

The main problem is all this classpath business. My first instinct was
to check that the apple classes are just simply there on Mac systems-
no go. In the article's example, the /system/library/java directory is
added to the -classpath argument both when compiling and executing the
java code.

So, from my previous experience with using databases from javascript-
Adding stuff to Helma's classpath is as easy as dumping jar files in
helma's lib/ext.   Problem is (nearly) all the files in
/system/library/java are .class files, not jar.   On the off chance
that they might work anyway, I tried copying the directory into
helma's lib/ext.  Still no love from helma- the cocoa classes do not
appear in helma. I also tried modifying the start.sh, to add a
-classpath argument, but that didn't really work either.

My next trick will be figuring out how to package all these com.apple
class files up in a JAR, and add that. however, with encouragement
from Chris Zumbrunn, I decided to post here first to see if anyone has
done this before, and could offer some advice and possibly save me
hours of fruitless blind trial and error.

Thanks all,
-Breton
Stefan Rinner | 21 Nov 21:07
Picon

Re: Invisible steamroller! Applescript+Helma

Hi

I investigated the combination of Helma and Applescript some time ago   
- here are some parts from my notes - this stuff worked back then, but  
I have no idea if it still works in Leopard

first you need to package the Applescript class files into a jar:

cd /System/Library/Java
jar -cvf ~/com.apple.cocoa.jar com/apple/cocoa/*

put the com.apple.cocoa.jar into your lib/ext

to execute a piece of Applescript use this in your helm app:

function callAppleScript( scriptSource ) {
	var cocoaFoundation = Packages.com.apple.cocoa.foundation;
	var appleScript = new cocoaFoundation.NSAppleScript( scriptSource );
	var errors = new cocoaFoundation.NSMutableDictionary();
	var result = appleScript.execute( errors );

	if(errors.count() != 0)
		throw( "AppleScriptException" );
	return result;
}

- stefan
Robert Huemer | 21 Nov 21:18

Re: Invisible steamroller! Applescript+Helma

hi breton,

i have done it this way:

    var rr = java.lang.Runtime;
    var rtime = rr.getRuntime();
    var child = rtime.exec("osascript path/to/applescript.scpt");

    var output = new java.io.BufferedReader(new  
java.io.InputStreamReader(child.getInputStream(), "UTF-8"));
    var result = output.readLine();
    output.close();
    return(result);

robert

On 21.11.2007, at 12:50, Breton Slivka wrote:

> Hello all, I've been using helma for some weeks now, and I have come
> up against a bit of a challenge which is stressing my rather limited
> knowledge of Java.
>
> My main goal is being able to execute an applescript from helma. I
> know this is possible from Java- and is demonstrated in exhibit a:
>
> http://www.oreilly.com/pub/a/mac/2003/02/25/apple_scripting.html? 
> page=1
>
> The main problem is all this classpath business. My first instinct was
> to check that the apple classes are just simply there on Mac systems-
> no go. In the article's example, the /system/library/java directory is
> added to the -classpath argument both when compiling and executing the
> java code.
>
> So, from my previous experience with using databases from javascript-
> Adding stuff to Helma's classpath is as easy as dumping jar files in
> helma's lib/ext.   Problem is (nearly) all the files in
> /system/library/java are .class files, not jar.   On the off chance
> that they might work anyway, I tried copying the directory into
> helma's lib/ext.  Still no love from helma- the cocoa classes do not
> appear in helma. I also tried modifying the start.sh, to add a
> -classpath argument, but that didn't really work either.
>
> My next trick will be figuring out how to package all these com.apple
> class files up in a JAR, and add that. however, with encouragement
> from Chris Zumbrunn, I decided to post here first to see if anyone has
> done this before, and could offer some advice and possibly save me
> hours of fruitless blind trial and error.
>
> Thanks all,
> -Breton
> _______________________________________________
> Helma-user mailing list
> Helma-user <at> helma.org
> http://helma.org/mailman/listinfo/helma-user

Gmane