Nabble - Helma - Dev

[Bug 641] New: Exception in renderSkin() cannot be caught

2008-10-02T15:14:21Z

http://helma.org/bugs/show_bug.cgi?id=641

Summary: Exception in renderSkin() cannot be caught
Product: Helma
Version: CVS trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P1
Component: Web Support
AssignedTo: helma-dev@...
ReportedBy: interface@...

If a skin is "sandboxed" by using the Skin.allowMacro() method, Helma throws an
exception if the skin contains a forbidden macro.

Unfortunately, this exception cannot be caught with a try/catch block:

var foo_macro = function() { return "foo" }
var skin = createSkin("<% foo %>");
skin.allowMacro("bar");
try {
renderSkin(skin);
} catch (ex) {
writeln("This will never be displayed");
}

It would be nice if that exception could be caught this way.

If that should be too complicated I suggest the exception should not be logged
on error level but rather on debug level to avoid flooding the log file with
long, fatal looking stacktraces which actually are pretty harmless.

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

org.mozilla.javascript.NativeArray toJSON error

2008-09-30T22:30:25Z

Sometimes when I have an object with arrays

I'm doing

if(!session.data.jobulousSurvey.Review.responses) session.data.jobulousSurvey.Review.responses = []

if I uneval.

uneval(session.data.jobulousSurvey.Review.responses) // this is end up to be org.mozilla.javascript.NativeArray

1. why is this happening?
2. this doesn't work with session.data.jobulousSurvey.Review.toJSON()

I don't really mind using a mozilla array, as long as I can use toJSON method on it.

Any recommendation or insight as why this is happening? Is this a bug?

Julian

_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 625] format() enkodiert Makro-Parameter

2008-09-27T01:59:15Z

http://helma.org/bugs/show_bug.cgi?id=625

------- Comment #3 from interface@... 2008-09-27 10:59 -------
A potential fix could be replacing line 637 of helma.util.HtmlEncoder.java [1]
with the following lines:

if (insideMacroTag) {
ret.append("&");
} else {
ret.append("&");
}

I did not test this thoroughly, yet, but at least noticed that line 637 is
always executed when encode() is coming across an ampersand in a macro (no
matter if in the macro handler, the macro name or in the name or value of a
named parameter or in the value of a positional parameter).

--

[1]
https://dev.helma.org/trac/helma/browser/helma/helma/trunk/src/helma/util/HtmlEncoder.java?rev=8936#L637

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 636] add support to helma.File to open files with non default charset

2008-09-21T16:00:55Z

http://helma.org/bugs/show_bug.cgi?id=636

------- Comment #5 from maksim.lin@... 2008-09-22 01:00 -------
I'm all for keeping helma-ng as close as possible to helma 1.x to ease eventual
porting and I too prefer the throw exceptions style vs the old check-for-error
style so would be happy to have the backport to helma 1.x and test/fix any
existing app code.
Because helma.File is used some much in app code, it would be good to make this
change and then advertise the changes in the release of 1.6.4 so that people
know to test their thoroughly apps before deploying 1.6.4

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 625] format() enkodiert Makro-Parameter

2008-09-21T11:16:00Z

http://helma.org/bugs/show_bug.cgi?id=625

interface@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|1.6.4 |1.6.3

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 625] format() enkodiert Makro-Parameter

2008-09-21T11:15:03Z

http://helma.org/bugs/show_bug.cgi?id=625

interface@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
Target Milestone|--- |1.6.4

------- Comment #2 from interface@... 2008-09-21 20:15 -------
Sorry for the delay, but unfortunately, this bug is not completely fixed, yet;
calling format on a macro containing an ampersand still encodes this to
"&":

format("<% foo 'hasi&mausi' %>");
// <% foo 'hasi&mausi' %>

Would be nice if this could be fixed in the 1.6.3 milestone.

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 636] add support to helma.File to open files with non default charset

2008-09-20T13:48:20Z

http://helma.org/bugs/show_bug.cgi?id=636

------- Comment #4 from hannes@... 2008-09-20 22:48 -------
I forgot to add a link to the changes to the helma.file module in NG:

http://dev.helma.org/trac/helma/log/helma-ng/trunk/modules/helma/file.js

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 629] app.xmlrpcCount is not increased by "new-style" XML-RPC calls

2008-09-20T13:46:10Z

http://helma.org/bugs/show_bug.cgi?id=629

hannes@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

------- Comment #2 from hannes@... 2008-09-20 22:46 -------
Fixed in svn.

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 636] add support to helma.File to open files with non default charset

2008-09-20T13:41:14Z

http://helma.org/bugs/show_bug.cgi?id=636

------- Comment #3 from hannes@... 2008-09-20 22:41 -------
I've made quite extensive changes to the helma.file module in Helma NG. The
most important is that the code now throws/forwards exceptions instead of
catching them and requiring active checks from the client code.

I'm in favor of backporting that to Helma 1.6.3, even at the risk of breaking
some minor code. What do others think?

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 634] provide access to the active skin state

2008-09-20T13:34:52Z

http://helma.org/bugs/show_bug.cgi?id=634

------- Comment #2 from hannes@... 2008-09-20 22:34 -------
Thanks for the patch. How do you access the skin name from the macro? I'm sorry
if this question sounds stupid, but I have currently don't have the details of
Helma 1 macro invocation in my head.

Regarding the ResponseTrans getter, I'd actually prefer to expose the required
functionality in ResponseBean if it it's possible. What functionality do you
need that is hidden in ResponseTrans?

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 633] Unsetting a non-persistable property still marks the node as modified.

2008-09-20T13:23:19Z

http://helma.org/bugs/show_bug.cgi?id=633

hannes@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

------- Comment #3 from hannes@... 2008-09-20 22:23 -------
Thanks Jürg, fixed in SVN, sorry it took that long.

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 545] Java instances break toSource() / eval()

2008-09-20T13:11:13Z

http://helma.org/bugs/show_bug.cgi?id=545

------- Comment #3 from hannes@... 2008-09-20 22:11 -------
Can you provide a concrete example of how to demonstrate the
Spidermonkey/Firefox behaviour?

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 545] Java instances break toSource() / eval()

2008-09-20T13:09:59Z

http://helma.org/bugs/show_bug.cgi?id=545

------- Comment #2 from hannes@... 2008-09-20 22:09 -------
This is indeed a Rhino bug, I'll file it on bugzilla.mozilla.org

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 445] named collection wird nicht aktualisiert

2008-09-09T06:12:55Z

http://helma.org/bugs/show_bug.cgi?id=445

hannes@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED

------- Comment #4 from hannes@... 2008-09-09 15:12 -------
I think the bug is still open in current Helma 1. However, the following
workaround should help:

namedCollection.invalidate(oldAccessname);

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 640] db.properties should get dbPropFile like apps.properties already has

2008-09-07T09:21:32Z

http://helma.org/bugs/show_bug.cgi?id=640

------- Comment #1 from decke@... 2008-09-07 18:21 -------
Created an attachment (id=98)
--> (http://helma.org/bugs/attachment.cgi?id=98&action=view)
Patch to implement dbPropFile configuration

This patch implements dbPropFile in the same way that appsPropFile is.

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 640] New: db.properties should get dbPropFile like apps.properties already has

2008-09-07T09:19:00Z

http://helma.org/bugs/show_bug.cgi?id=640

Summary: db.properties should get dbPropFile like apps.properties
already has
Product: Helma
Version: 1.6.2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P1
Component: Generic/Other
AssignedTo: helma-dev@...
ReportedBy: decke@...

There is no possibility to define where Helma should look for db.properties
if it's not in hopHome. The default path for hopHome is not appropriate because
that is /usr/local/www/helma but configurations should be in
/usr/local/etc/helma.

That is not a problem for apps.properties because we can use "appsPropFile" and
this is exactly what is missing for db.properties.

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 639] Relative paths for repositories are relative to HELMA_INSTALL

2008-09-07T09:02:33Z

http://helma.org/bugs/show_bug.cgi?id=639

------- Comment #1 from decke@... 2008-09-07 18:02 -------
Created an attachment (id=97)
--> (http://helma.org/bugs/attachment.cgi?id=97&action=view)
Workaround

That's a workaround against that problem that i use in the FreeBSD port. It was
not tested if it breaks helma in the standard configuration.

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 639] New: Relative paths for repositories are relative to HELMA_INSTALL

2008-09-07T08:56:24Z

http://helma.org/bugs/show_bug.cgi?id=639

Summary: Relative paths for repositories are relative to
HELMA_INSTALL
Product: Helma
Version: 1.6.2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P1
Component: Generic/Other
AssignedTo: helma-dev@...
ReportedBy: decke@...

While creating a FreeBSD port for Helma 1.6.2 i found that relative paths to
repositories in apps.properties are relative to HELMA_INSTALL but hopHome would
be more appropriate i think.

On FreeBSD the paths look like this:

HELMA_INSTALL = /usr/local/share/java/helma
HELMA_HOME = /usr/local/www/helma

hopHome = /usr/local/www/helma
appHome = /usr/local/www/helma/apps

Additional Modules should be in /usr/local/www/helma/modules but are currently
searched in /usr/local/share/java/helma/modules if you use relative paths for
repositories.

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 626] Function definition does not overwrite variable definition

2008-09-02T03:32:21Z

http://helma.org/bugs/show_bug.cgi?id=626

interface@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED

------- Comment #3 from interface@... 2008-09-02 12:32 -------
Thanks for the clarifications to both of you.

I just went through Crockford's "Good Parts" again – "hoisting" is not
mentioned in the index – and Crockford also explains the hoisting feature
(p.113, "The function Statement Versus the function Expression") and why he
favours the expression over the statement:

"This relaxes the requirement that functions should be declared before used,
which I think leads to sloppiness. It also prohibits the use of function
statements in if statements. It turns out that most browsers allow function
statements in if statements, but they vary in how that should be interpreted.
That creates portability problems."

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 636] add support to helma.File to open files with non default charset

2008-09-02T02:22:59Z

http://helma.org/bugs/show_bug.cgi?id=636

------- Comment #2 from hannes@... 2008-09-02 11:22 -------
Thanks for the patch. The problem is that we already added another optional
argument to File.open in Helma-NG, which is the boolean append argument. I
guess what we really should do is take an option object as argument, so we can
do this:

file.open({charset: 'utf-8', append: true});

and have this consistently on both Helma 1 and NG.

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 633] Unsetting a non-persistable property still marks the node as modified.

2008-09-01T23:56:52Z

http://helma.org/bugs/show_bug.cgi?id=633

maksim.lin@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |1.6.3

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 636] add support to helma.File to open files with non default charset

2008-09-01T23:45:07Z

http://helma.org/bugs/show_bug.cgi?id=636

maksim.lin@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |1.6.3

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 626] Function definition does not overwrite variable definition

2008-09-01T17:51:36Z

http://helma.org/bugs/show_bug.cgi?id=626

------- Comment #2 from breton.slivka@... 2008-09-02 02:51 -------
I agree in principle that it's by design, but not quite in the details. The
unexpected behavior in this bug is due to something javscript has called
"hoisting". What happens is that function definitions get automatically and
transparently moved to the top of the scope (whether that's global scope, or a
function scope), and variable declarations (but not their assignments) get
moved to the top of the scope, just underneath the function definitions.

So if I understand this correctly, this bit of code in the bug

var foo = function() {
return "This is: var foo = function()"; }

function foo() {
return "This is: function foo()";
}

Root.prototype.main_action = function() {
res.write(foo());
}

Gets translated before it's executed into:

function [anonymous1] (){
return "this is: var foo = function()"; }

function foo() {
return "this is: function foo()";
}

function [anonymous2]() {
res.write(foo());
}

var foo;
foo = [anonymous1];
Root.prototype.main_action = [anonymous2]

So as you can see since after hoisting, the variable assignment gets moved
after the function declaration, it takes precedence.

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 627] Inner functions in actions are implicitly async

2008-09-01T16:39:10Z

http://helma.org/bugs/show_bug.cgi?id=627

maksim.lin@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |1.6.3

------- Comment #1 from maksim.lin@... 2008-09-02 01:39 -------
Would be nice to get some feedback if this is really a bug or otherwise should
be documented as a expected behaviour?

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 626] Function definition does not overwrite variable definition

2008-09-01T16:37:34Z

http://helma.org/bugs/show_bug.cgi?id=626

maksim.lin@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

------- Comment #1 from maksim.lin@... 2008-09-02 01:37 -------
This looks like its due to the differences between function declarations and
function expressions.

Perhaps this (about half way down the page) sheds some more light:
http://developer.mozilla.org/En/Core_JavaScript_1.5_Reference:Functions#Function_constructor_vs._function_declaration_vs._function_expression

So I think why this happens is that the function declaration:
function foo() {
return "This is: function foo()";
}

happens when the script is parsed while the function expression:
var foo = function() {
return "This is: var foo = function()";
}

happens *afterward* when the script *runs* hence the assignment of the function
to the variable foo happens after the function declaration which named the
function "foo" in the global scope.

Tricky stuff!!!!!!!
I would never have thought of this with out looking it up myself

Another good explanation can be found in:
http://www.jibbering.com/faq/faq_notes/closures.html
(the relevant section is: "Identifier Resolution, Execution Contexts and Scope
Chains" and the subsection "The Execution Context".

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 624] cannot directly store getOrderedView collections in app.data

2008-09-01T16:15:44Z

http://helma.org/bugs/show_bug.cgi?id=624

maksim.lin@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |1.6.3

------- Comment #1 from maksim.lin@... 2008-09-02 01:15 -------
I think this is again an example of how the difference in they away
getOrderedView operates to normal collections that can trip people up.
So I think this is another flag for fixing getOrderedView to return normal
HopObject collections.

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 623] hop.get(name) doesn't use cache

2008-09-01T16:12:46Z

http://helma.org/bugs/show_bug.cgi?id=623

maksim.lin@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |1.6.3

------- Comment #2 from maksim.lin@... 2008-09-02 01:12 -------
I think the reason is that Helma doesnt keep the kind of index by accessname
that your example code creates and instead still indexes on the in the _id
proeprty, no matter what accessname property is set for a collection.
In my opinion it should and I think it would be a fairly small code change to
fix this.
It would be great to get this fixed soon, so I'm marking this for 1.6.3 and
will try to submit a patch for this soon.

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 623] hop.get(name) doesn't use cache

2008-09-01T16:12:25Z

http://helma.org/bugs/show_bug.cgi?id=623

------- Comment #1 from maksim.lin@... 2008-09-02 01:12 -------
I think the reason is that Helma doesnt keep the kind of index by accessname
that your example code creates and instead still indexes on the in the _id
proeprty, no matter what accessname property is set for a collection.
In my opinion it should and I think it would be a fairly small code change to
fix this.
It would be great to get this fixed soon, so I'm marking this for 1.6.3 and
will try to submit a patch for this soon.

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 599] HopObject.getById should return transient nodes as well

2008-09-01T16:06:29Z

http://helma.org/bugs/show_bug.cgi?id=599

------- Comment #1 from maksim.lin@... 2008-09-02 01:06 -------
Yes helma does assign a "temporary" id to every newly created HobPobject.
You can access these via the std _id property on the transient object. All
transient HopObject IDs start with "t", as in: t9876.
I don't see any reason why transient objects should also not be accessible via
their transient IDs.

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 514] HopObjects and defineGetter / defineSetter

2008-09-01T01:15:10Z

http://helma.org/bugs/show_bug.cgi?id=514

interface@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |1.6.3

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 634] provide access to the active skin state

2008-09-01T01:08:45Z

http://helma.org/bugs/show_bug.cgi?id=634

interface@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |1.6.3

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 616] Problem with accessing mountpoint methods from another application

2008-09-01T01:06:36Z

http://helma.org/bugs/show_bug.cgi?id=616

interface@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |1.6.3

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 445] named collection wird nicht aktualisiert

2008-09-01T01:02:53Z

http://helma.org/bugs/show_bug.cgi?id=445

interface@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Version|CVS trunk |1.6.3

------- Comment #3 from interface@... 2008-09-01 10:02 -------
(Note to self: is this still an issue in Helma 1.6.2?)

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 398] Bugs with high priority

2008-09-01T00:56:40Z

http://helma.org/bugs/show_bug.cgi?id=398

interface@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

------- Comment #2 from interface@... 2008-09-01 09:56 -------
Closing this bug since all dependent bugs of this tracker have been fixed.

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

[Bug 532] HopObject.getOrderedView() should use SQL instead of property names

2008-09-01T00:54:38Z

http://helma.org/bugs/show_bug.cgi?id=532

interface@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |1.7.0

--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev

Nabble - Helma - Dev

[Bug 641] New: Exception in renderSkin() cannot be caught

org.mozilla.javascript.NativeArray toJSON error

[Bug 625] format() enkodiert Makro-Parameter

[Bug 636] add support to helma.File to open files with non default charset

[Bug 625] format() enkodiert Makro-Parameter

[Bug 625] format() enkodiert Makro-Parameter

[Bug 636] add support to helma.File to open files with non default charset

[Bug 629] app.xmlrpcCount is not increased by "new-style" XML-RPC calls

[Bug 636] add support to helma.File to open files with non default charset

[Bug 634] provide access to the active skin state

[Bug 633] Unsetting a non-persistable property still marks the node as modified.

[Bug 545] Java instances break toSource() / eval()

[Bug 545] Java instances break toSource() / eval()

[Bug 445] named collection wird nicht aktualisiert

[Bug 640] db.properties should get dbPropFile like apps.properties already has

[Bug 640] New: db.properties should get dbPropFile like apps.properties already has

[Bug 639] Relative paths for repositories are relative to HELMA_INSTALL

[Bug 639] New: Relative paths for repositories are relative to HELMA_INSTALL

[Bug 626] Function definition does not overwrite variable definition

[Bug 636] add support to helma.File to open files with non default charset

[Bug 633] Unsetting a non-persistable property still marks the node as modified.

[Bug 636] add support to helma.File to open files with non default charset

[Bug 626] Function definition does not overwrite variable definition

[Bug 627] Inner functions in actions are implicitly async

[Bug 626] Function definition does not overwrite variable definition

[Bug 624] cannot directly store getOrderedView collections in app.data

[Bug 623] hop.get(name) doesn't use cache

[Bug 623] hop.get(name) doesn't use cache

[Bug 599] HopObject.getById should return transient nodes as well

[Bug 514] HopObjects and __defineGetter__ / __defineSetter__

[Bug 634] provide access to the active skin state

[Bug 616] Problem with accessing mountpoint methods from another application

[Bug 445] named collection wird nicht aktualisiert

[Bug 398] Bugs with high priority

[Bug 532] HopObject.getOrderedView() should use SQL instead of property names

[Bug 514] HopObjects and defineGetter / defineSetter