Mapping of Objects with PROTOTYPE and ID column strange errors

Hi list,

I try the following. Prototype for Mgr:

type.properties
>>>>>
_db = catalog
_table = MGRS

_id = ID
_prototype = PROTOTYPE
#_parent = target

target = object(HopObject)
target.local.1 = MGR_F_TARGET_ID
target.foreign.1 = ID
target.local.2 = PROTOTYPE
target.foreign.2 = MGR_F_TARGET_PROTOTYPE
<<<<<

And in the root prototype:

>>>>>
_db = catalog
_table = ROOT

_id = ID
_prototype = PROTOTYPE

things           = object(Mgr)

Re: Mapping of Objects with PROTOTYPE and ID column strange errors

_______________________________________________
Helma-user mailing list
Helma-user <at> helma.org
http://helma.org/mailman/listinfo/helma-user

Re: Mapping of Objects with PROTOTYPE and ID column strange errors

Hi,

Michael Platzer schrieb:
> I assume that you have to use '$id' and '$prototype' instead of the
> actual name of the column. also see the demo app, which hannes attached
> to this helma bug: http://helma.org/bugs/show_bug.cgi?id=516#c11

Thanks for that but it didn't solve my problem completely. I've attached
a small demoapp that demonstrates my problems.

2 Things are still strange.

First of all I don't understand why I have to map the prototype column
as an additional filter:

things.filter = MGRS.PROTOTYPE = "ThingMgr"

Second helma only mapps ThingMgr. And only sets of the sql for the first
mapping. Just look at the main action.

>    michi
<snip />

Any ideas why this happens?

cu Philipp

_______________________________________________
Helma-user mailing list
Helma-user <at> helma.org
http://helma.org/mailman/listinfo/helma-user

Patches

Hi Hannes,

The attached patches provide the following features:

* NodeManger - Invoke javascript 'onRemove' when a node is being deleted.

* NodeManager - Change the SQL string to use ' around the node id to allow
the node id to be non-numeric.

* Transactor - Enhance Transactor to process additional dirtyNodes created
when processing nodes that call onPersist, onInit, and on Remove functions.

Sorry for waiting so long to submit these patches.

Thanks,
Kris

Index: NodeManager.java
*** D:\jRTsrc\helma-1.6.0\hop\helma\src\helma\objectmodel\db\NodeManager.java Base (1.157)
--- D:\jRTsrc\helma-1.6.0\hop\helma\src\helma\objectmodel\db\NodeManager.java Locally
Modified (Based On 1.157)
***************
*** 546,551 ****
--- 546,567 ----
      }

      /**
+      *  calls onRemove function for the HopObject
+      */
+     private void invokeOnRemove(Node node) {
+         try {
+             // We need to reach deap into helma.framework.core to invoke onPersist(),
+             // but the functionality is really worth it.
+             RequestEvaluator reval = app.getCurrentRequestEvaluator();
+             if (reval != null) {
+                 reval.invokeDirectFunction(node, "onRemove", RequestEvaluator.EMPTY_ARGS);
+             }
+         } catch (Exception x) {
+             app.logError("Error invoking onRemove()", x);
+         }
+     }
+     
+     /**
       *  Updates a modified node in the embedded db or an external relational database, depending
       * on its database mapping.
       *
***************
*** 681,686 ****
--- 697,704 ----
       */
      public void deleteNode(IDatabase db, ITransaction txn, Node node)
                      throws Exception {
+         invokeOnRemove(node);
+         
          DbMapping dbm = node.getDbMapping();

          if ((dbm == null) || !dbm.isRelational()) {
***************
*** 691,701 ****
              String str = new StringBuffer("DELETE FROM ").append(dbm.getTableName())
                                                           .append(" WHERE ")
                                                           .append(dbm.getIDField())
!                                                          .append(" = ")
                                                           .append(node.getID())
                                                           .toString();

--- 709,717 ----
              String str = new StringBuffer("DELETE FROM ").append(dbm.getTableName())
                                                           .append(" WHERE ")
                                                           .append(dbm.getIDField())
!                                                          .append(" = '")
                                                           .append(node.getID())
+                                                          .append("'")
                                                           .toString();

              try {

Index: Transactor.java
*** D:\jRTsrc\helma-1.6.0\hop\helma\src\helma\objectmodel\db\Transactor.java Base (1.34)
--- D:\jRTsrc\helma-1.6.0\hop\helma\src\helma\objectmodel\db\Transactor.java Locally Modified
(Based On 1.34)
***************
*** 257,268 ****
              modifiedParentNodes = new ArrayList();
          }

!         if (!dirtyNodes.isEmpty()) {
              Object[] dirty = dirtyNodes.values().toArray();

              // the set to collect DbMappings to be marked as changed
              HashSet dirtyDbMappings = new HashSet();
--- 257,268 ----
              modifiedParentNodes = new ArrayList();
          }

!         while (!dirtyNodes.isEmpty()) {
              Object[] dirty = dirtyNodes.values().toArray();

+             // reset dirty node list
+ 	    dirtyNodes = new HashMap();
+ 
              // the set to collect DbMappings to be marked as changed
              HashSet dirtyDbMappings = new HashSet();

_______________________________________________
Helma-user mailing list
Helma-user <at> helma.org
http://helma.org/mailman/listinfo/helma-user

ANN: Jala 1.2

Hi everybody,

we're proud to announce the release of version 1.2 of Jala. This release
contains a number of enhancements and bugfixes, but first of all an
IMPORTANT NOTICE:

Due to the ongoing stability and performance problems of our former
hosting provider opensvn.csie.org we decided to move the project to a
new home. From now on you'll find Jala at https://dev.orf.at/jala, so
please make sure to update your bookmarks. If you have a local svn
working copy of Jala you'll need to replace it with a fresh check out:

svn checkout http://dev.orf.at/source/jala/branches/release-1.2 ./jala

With release 1.2 Jala got three new modules, most important Stefan's
fabulous Form.js [1]. If you're tired of creating HTML forms and
validating/handling submitted form data over and over again, you'll love
Form.js. Have a look at the documentation [2] for more information on
how to make use of it in your applications.

Second, also developed by Stefan, Jala now includes Mp3.js [3], now
featuring easy read *and* write access to metadata stored in ID3 tags
(both version 1 and 2). This library replaces Mp3Info.js.

Other changes in Jala 1.2 include a new Database module for easy
creation and use of embedded in-memory and file-based relational
databases. Using this module the Jala unit test framework is now capable
to switch an application to an (optionally pre-filled) in-memory test
database during the runtime of a test.

For more information about the above and all other changes please point
your browser to https://dev.orf.at/jala/wiki/Download. As usual this
release comes with complete API documentation [4] and detailed
description of all available modules [5], which should make using Jala a
breeze. We hope you like this new release as much as we do.

kind regards,
Robert

[1]
http://dev.orf.at/source/jala/branches/release-1.2/docs/jala.Form.html
[2] https://dev.orf.at/jala/wiki/JalaModules/Form
[3]
http://dev.orf.at/source/jala/branches/release-1.2/docs/jala.Mp3.html
[4] http://dev.orf.at/source/jala/branches/release-1.2/docs/index.html
[5] https://dev.orf.at/jala/wiki/JalaModules/

Server-side DOM

I came across this on John Resigs blog and it looks like at the very
least it would be useful for doing testing of helma apps within helma
along the lines of whats currently provided in Jala...

http://ejohn.org/blog/bringing-the-browser-to-the-server/

Re: Server-side DOM

Hi,

We have been using the prototype.js on the server-side since over a year
now, but we always had to strip out the dom-related parts before
dropping it into the code-repository. That is a tempting  and impressive
idea, to try to just simulate the window/dom on the server-side.

But for running automated controller-tests, this doesn't bring that much
comfort compared to what jala already provides, does it?

Currently I can write
  var httpClient = new jala.Test.HttpClient();
  var result = httpClient.getUrl(someUrl);
  var doc = new jala.HtmlDocument(result.content);
  var ele = doc.scrape("//html:img[@id='captchaImage']"); //
XPath-expression

With env.js and prototype.js I could write
  window.location = someUrl;
  var ele = $("img.captchaImge");

But a lot of questions remain, like how would i simulate multiple
clients, or how can we support sessions, resp cookies?

Anyways, interesting article, thanks for the pointer!

   michi

p.s. looking at the above sample code, i would even simply suggest
adding methods '$' and '$$' to the jala.HtmlDocument. I don't think that
it would be that hard to implement these, since these are just simple
wrappers for the scrape-method?

Maksim Lin for technical support mailling lists schrieb:
> I came across this on John Resigs blog and it looks like at the very
> least it would be useful for doing testing of helma apps within helma
> along the lines of whats currently provided in Jala...
>
> http://ejohn.org/blog/bringing-the-browser-to-the-server/
> _______________________________________________
> Helma-user mailing list
> Helma-user <at> helma.org
> http://helma.org/mailman/listinfo/helma-user

Re: Server-side DOM

On Jul 11, 2007, at 6:12 , Maksim Lin for technical support mailling  
lists wrote:

> I came across this on John Resigs blog and it looks like at the very
> least it would be useful for doing testing of helma apps within helma
> along the lines of whats currently provided in Jala...
>
> http://ejohn.org/blog/bringing-the-browser-to-the-server/

I've played with it a bit yesterday. One "problem" when using it  
inside of Helma is that is pollutes the global namespace with the  
browser DOM objects and properties (to avoid that, it would need to  
be run inside a separate js scope). Also, since the window.onload  
event fires in its own thread after the document has been loaded/ 
updated, the DOM processing happens asynchronous from the request  
that invoked it.

Anyway, it works   You can drop the unmodified env.js and  
jquery.js files into the Global directory of a Helma app (or load  
them dynamically using app.addRepository()). The only thing you need  
to do is make the global vars sticky using the following  
defineLibraryScope calls:

defineLibraryScope('window');
defineLibraryScope('navigator');
defineLibraryScope('location');
defineLibraryScope('setTimeout');
defineLibraryScope('setInterval');
defineLibraryScope('clearInterval');
defineLibraryScope('addEventListener');
defineLibraryScope('removeEventListener');
defineLibraryScope('dispatchEvent');
defineLibraryScope('DOMDocument');
defineLibraryScope('DOMNode');
defineLibraryScope('DOMNodeList');
defineLibraryScope('DOMElement');
defineLibraryScope('XMLHttpRequest');
defineLibraryScope('document');

Chris

Re: Server-side DOM

Chris Zumbrunn wrote:
> One "problem" when using it  
> inside of Helma is that is pollutes the global namespace with the  
> browser DOM objects and properties (to avoid that, it would need to  
> be run inside a separate js scope).

It would seem like this could be achieved with some minor modifications 
of env.js (and possibly jquery.js) and clever use of closure, don't you 
think?

What I'd really like is jQuery-style XML querying and modification in 
ways that make sense on the server-side.

> make the global vars sticky using the following  
> defineLibraryScope calls:

I'm still trying to get my head around Helma's application model. Can 
you explain what defineLibraryScope does and why it's necessary?

-Joshua

Re: Server-side DOM

On Jul 11, 2007, at 15:44 , Joshua Paine wrote:

> Chris Zumbrunn wrote:
>> One "problem" when using it
>> inside of Helma is that is pollutes the global namespace with the
>> browser DOM objects and properties (to avoid that, it would need to
>> be run inside a separate js scope).
>
> It would seem like this could be achieved with some minor  
> modifications
> of env.js (and possibly jquery.js) and clever use of closure, don't  
> you
> think?

With modifications of env.js and jquery.js it would be possible, yes.  
But that would be a pain to maintain.

jQuery is extreme good about being able to be encapsulated inside of  
closures. But as far as the DOM is concerned, it really counts on  
that being global. I've already tried to work around it with closures  
and still think it might work, but didn't get there when playing with  
it yesterday.

> What I'd really like is jQuery-style XML querying and modification in
> ways that make sense on the server-side.

Yes, like being able to use jQuery to query and modify E4X objects.  
And then use these E4X objects as "skins".

>> make the global vars sticky using the following
>> defineLibraryScope calls:
>
> I'm still trying to get my head around Helma's application model. Can
> you explain what defineLibraryScope does and why it's necessary?

Over the last year or two we went back and forth between whether  
defineLibraryScope is needed or not. It was deprecated and  
undeprecated several times, and it was even removed once completely  
only to be added back in. So, you are not the only one that is  
confused about it 

To top it off, the reason why it is needed has changed over time  
because some default behaviors in Helma changed, regarding how Helma  
handles the global scope for requests AND how it clears the global  
scope when code files of a running application are updated AND when  
an additional code repository is added dynamically during runtime.

Helma now copies the application's global scope to a "global scope  
per request" and disposes of that per-request-scope after the request  
handling has been completed.

Modifications of global vars that are set "in the global  
code" (meaning, not dynamically at runtime, but when a code  
repository is added, at startup, or after a code update) will be  
synched back to the application's global scope. But if you create a  
global var "dynamically at runtime", during the processing of a  
request, it will be cleared and will be undefined in the global scope  
of the next request.

That's where defineLibraryScope comes to the rescue. Using it, you  
can declare that a global var should survive between requests, even- 
though it wasn't defined in the global code.

There are good reasons for the change to using per-request global  
scopes the way it is done now in Helma 1.6, but I think the way this  
all behaves now isn't perfect yet. For example, the new behavior  
breaks the use of closures inside the global code, if the code inside  
those closures needs to add properties to the global object (Is this  
a bug?). That's exactly what env.js and jquery.js try to do.

Having said all that  ...in this particular case we could avoid  
using defineLibraryScope and instead simply define the vars like this:

var window,navigator,location,setTimeout, ...etc

...but that only works in the global code. When global vars need to  
be added later dynamically, we *do* need defineLibraryScope.

Chris