jfwittmann | 1 Apr 23:22
Picon
Picon
Gravatar

Re: __defineGetter__

Michael Platzer schrieb:
> Hi list,
>
> One of the cool new features of Helma 1.6.0 will be the ability to 
> define methods for retrieving and setting properties throught the use of 
> defineGetter, and defineSetter.
> -> 
> http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Creating_New_Objects:Defining_Getters_and_Setters
>   

In the Mustang includes Rhino JavaScript engine it's already possible.
this was a little test by me with the known  prototype lib on server side.
....
function MapAdapter(map) {
    this.__has__ = function(name) {
       return map.containsKey(name);
    }
    this.__get__ = function(name) {
        return map.get(name);
    }
    this.__put__ = function(name, value) {
        map.put(name, value);
    }
    this.__delete__ = function(name) {
        map.remove(name);
    }
    this.__getIds__ = function() {
        var result = [];
        for (var keyIterator = map.keySet().iterator(); 
keyIterator.hasNext();) {
(Continue reading)

Hannes Wallnoefer | 2 Apr 13:55
Picon
Gravatar

Re: __defineGetter__

Hi Felix,

2007/4/1, jfwittmann <neokolor <at> gmx.de>:
>
> In the Mustang includes Rhino JavaScript engine it's already possible.
> this was a little test by me with the known  prototype lib on server side.
> ....
> function MapAdapter(map) {
>     this.__has__ = function(name) {
>        return map.containsKey(name);
>     }
>     this.__get__ = function(name) {
>         return map.get(name);
>     }
>     this.__put__ = function(name, value) {
>         map.put(name, value);
>     }
>     this.__delete__ = function(name) {
>         map.remove(name);
>     }
>     this.__getIds__ = function() {
>         var result = [];
>         for (var keyIterator = map.keySet().iterator();
> keyIterator.hasNext();) {
>             var key = keyIterator.next();
>             result.push(key);
>         }
>         return result;
>     }
> };
(Continue reading)

Hannes Wallnoefer | 2 Apr 14:00
Picon
Gravatar

Re: __defineGetter__

2007/4/2, Hannes Wallnoefer <hannesw <at> gmail.com>:
> Hi Felix,
>
> 2007/4/1, jfwittmann <neokolor <at> gmx.de>:
> >
> > In the Mustang includes Rhino JavaScript engine it's already possible.
> > this was a little test by me with the known  prototype lib on server side.
> > ....
> > function MapAdapter(map) {
> >     this.__has__ = function(name) {
> >        return map.containsKey(name);
> >     }
> >     this.__get__ = function(name) {
> >         return map.get(name);
> >     }
> >     this.__put__ = function(name, value) {
> >         map.put(name, value);
> >     }
> >     this.__delete__ = function(name) {
> >         map.remove(name);
> >     }
> >     this.__getIds__ = function() {
> >         var result = [];
> >         for (var keyIterator = map.keySet().iterator();
> > keyIterator.hasNext();) {
> >             var key = keyIterator.next();
> >             result.push(key);
> >         }
> >         return result;
> >     }
(Continue reading)

Joshua Levy | 3 Apr 00:37
Favicon

Re: Helma OutOfMemory


Hi Michi and all,
In a similar vein, in case anyone's not tried them yet:  The JMX tools
[1,2] have become really helpful for monitoring and debugging servers
like Helma, especially in Java 6.  jconsole monitors and graphs
memory, threads, CPU, and other info in real time and can indicate
leaks and performance issues, and jmap can do the heap dumps
at any time.  (Note also you get some benefits by using Java 6's
jconsole even if you run Helma with Java 5.)

Cheers,
Joshua

[1] http://java.sun.com/developer/technicalArticles/J2SE/monitoring/
[2] http://java.sun.com/javase/6/docs/technotes/guides/management/agent.html
--

-- 
View this message in context: http://www.nabble.com/Helma-OutOfMemory-tf3472719s2589.html#a9800402
Sent from the Helma - User mailing list archive at Nabble.com.
Michael Platzer | 3 Apr 18:02
Picon

Re: __defineGetter__


> The reason this doesn't work is that property inspection from macros
> on HopObjects only supports collections and properties defined in
> type.properties. Since first and last are not in type.properties, the
> resolution failse. Let's think about this restriction.
>   
Any more thoughts on this? I would say +1 for dropping this restriction.
I never fully understood its purpose anyways.

   michi
Kris Leite | 3 Apr 21:47

Suggestion: onPersist function call

I had a need to do some changes on a HopObject before it was
written into storage.  So I made a customized version Helma 1.5.3
to call 'onPersist' function when a HopObject was being written
into the embedded or relational database. 

It would be nice if this was added as a new feature for Helma 1.6.

The way I implemented it was very similar to the 'onInit()' function
by making a copy of the "invokeOnInit" function in Node.java
and changing the names to 'OnPersist' then adding a call to
'invokeOnPersist' in the NodeManager methods 'insertNode' and
'updateNode'.

I will be happy to provide the patches if you like.

Thanks,
Kris
Kris Leite | 3 Apr 21:54

Re: __defineGetter__


>> The reason this doesn't work is that property inspection from macros
>> on HopObjects only supports collections and properties defined in
>> type.properties. Since first and last are not in type.properties, the
>> resolution failse. Let's think about this restriction.
>>   
>>     
> Any more thoughts on this? I would say +1 for dropping this restriction.
> I never fully understood its purpose anyways.
>
>    michi
>
> _______________________________________________
> Helma-user mailing list
> Helma-user <at> helma.org
> http://helma.org/mailman/listinfo/helma-user
>
>   

+1 for dropping!  I just came across this issue yesterday when I was 
trying to
enumerate over a HopObject that had properties other than what was defined
in type.properties file.  I was very confused on what was going on. 

Thanks,
Kris
Hannes Wallnoefer | 3 Apr 22:57
Picon
Gravatar

Re: Suggestion: onPersist function call

Hi Kris,

2007/4/3, Kris Leite <kleite <at> imcsoftware.com>:
> I had a need to do some changes on a HopObject before it was
> written into storage.  So I made a customized version Helma 1.5.3
> to call 'onPersist' function when a HopObject was being written
> into the embedded or relational database.
>
> It would be nice if this was added as a new feature for Helma 1.6.
>
> The way I implemented it was very similar to the 'onInit()' function
> by making a copy of the "invokeOnInit" function in Node.java
> and changing the names to 'OnPersist' then adding a call to
> 'invokeOnPersist' in the NodeManager methods 'insertNode' and
> 'updateNode'.
>
> I will be happy to provide the patches if you like.

Yes, please send a patch.

hannes

> Thanks,
> Kris
>
>
> _______________________________________________
> Helma-user mailing list
> Helma-user <at> helma.org
> http://helma.org/mailman/listinfo/helma-user
(Continue reading)

Kris Leite | 4 Apr 07:43

Re: Suggestion: onPersist function call

Hi Hannes,

Attached is a patch for the 'onPersist' function call.  In version 1.6 I 
found that
the 'onInit' was moved from the Node class to NodeManager.  So I put the
'invokeOnPersist' in the NodeManager class to be consistent.  I also 
removed
the check for 'dbmap' in the 'onInit' section since that would only 
allow the routine
to be activated for only database configuration.  The documentation for 
'onInit'
indicated it was to be activated for both embedded and database persistence
storage.

Thanks,
Kris

Hannes Wallnoefer wrote:
> Hi Kris,
>
> 2007/4/3, Kris Leite <kleite <at> imcsoftware.com>:
>   
>> I had a need to do some changes on a HopObject before it was
>> written into storage.  So I made a customized version Helma 1.5.3
>> to call 'onPersist' function when a HopObject was being written
>> into the embedded or relational database.
>>
>> It would be nice if this was added as a new feature for Helma 1.6.
>>
>> The way I implemented it was very similar to the 'onInit()' function
(Continue reading)

Hannes Wallnoefer | 4 Apr 09:14
Picon
Gravatar

Re: __defineGetter__

2007/4/3, Michael Platzer <michael.platzer <at> knallgrau.at>:
>
> > The reason this doesn't work is that property inspection from macros
> > on HopObjects only supports collections and properties defined in
> > type.properties. Since first and last are not in type.properties, the
> > resolution failse. Let's think about this restriction.
> >
> Any more thoughts on this? I would say +1 for dropping this restriction.
> I never fully understood its purpose anyways.

I guess it just reflected the thinking of the time of HopObject as
cearly typed objects. I still am unsure whether having extra
properties on persistent HopObjects is good design.

I'd like to hear more opinions on this, specifically regarding
exposure of non-defined properties to skins.

hannes

Gmane