Re: [Dojo-interest] New DataStore

[XMaNIaC]

I can easily see up to four stages in the process: the backend, the model mapping, the entity manager and the dojo data store integration. A good solution would allow swapping any of them with a different implementation.

I'm going to focus on the first three where DWR can help to integrate with a JEE server.

1) DWR main functionality is to allow remote access to Java objects. We would just need to have a fixed signature for methods. If we keep the dojo data interfaces I know Joe walker is already working with a some integration code. Otherwise we would need to create an EntityManager interface and some implementations (at least JPA)

2) The model mapping is completely covered with the current implementation. DWR converters generate JS object structures from POJOs (including collections). So you can transparently do:

p = new Person
p.name = 'John'
p.surname = 'Smith'

Probably we would need to add an attribute to converters to automatically register it in the EM.

3) Here's the bulk of the code. We would need some clever code to transform

p = new Person(10)

to

EntityManager.find(model.Person, 10, callback)

But here's where your solution helps, isn't it?

Once we have a JS base (not sure if we are there yet) I'll start the Java implementation

Regards,

On Wed, Jun 25, 2008 at 4:15 PM, Kris Zyp <kris@...> wrote:

As you mentioned in your post, Maulin, JsonRestStore does already handle object persistence, and covers some of the same ground, so I definitely interested in seeing if it could meet your needs, and if there are any additional features you would like to see in JsonRestStore or as modules that could plug in to it, so we have a common module for general use in this area. As I mentioned in the ticket filed for this enhancement request (http://trac.dojotoolkit.org/ticket/6981), JsonRestStore already supports plugging in different services/persistence managers, but I think one of the primary patterns you are suggesting is the addition Javabean style getters & setters and convenience methods (like save()) to store items/model objects. I think your idea of having a module that could autogenerate these methods could be very valuable (well, I actually don't like the Javabean pattern, but it is popular enough that is certainly worth supporting).

 

The JsonRestStore infrastructure supports defining a prototype ([[Proto]]) for all items of a store, and this seems like it would be a very efficient mechanism for including your auto setter/getter and convenience method addition. One could use your generation code to take schemas and create methods and that could be provide the prototype of the store's items. Does that seem like a reasonable integration point?

 

Thanks,

Kris

 

----- Original Message -----

From: maulinpshah@...

To: dojo-interest@...

Sent: Wednesday, June 25, 2008 5:55 AM

Subject: Re: [Dojo-interest] New DataStore

Jose,

 

You read my mind. This is exactly my intent. Actually, my intent is even perhaps a bit more generic – I am in a situation where my backend is not yet decided, and may change with some frequency (argh). So I wanted to put together a solution that made it simple for me to integrate into various backends by simply providing a simple api to the server folks. But clearly DWR was high on my list.

 

I've created the mappings to be "native" as in most of my examples so that you can code them up in javascript very quickly, but I also created a mechanism of plugging in a json object as a mapping. If you have used Hibernate or DWR I could imagine plugging the xml into the EntityManager. Of course, perhaps the set of domain objects you have on the client would be a subset of those on the server, and maybe even the properties might be a subset. This is where DWR could come in, since it already has the mechanism of describing exposed and unexposed properties of your business objects. (I have used DWR once almost 2 years ago, so I am very rusty on its details and its current features…)

 

If we are talking about DWR integration, I would think about how we could implement a representation of the object model and its connection to the EntityManager as *generated* code, so that we could essentially eliminate the "boot time" that the current EntityManager has as it traverses the mappings and instruments your objects. Instead, you could imagine that they could be "pre-instrumented" based on your hibernate/jpa mappings.

 

 

------------------------------

 

Message: 10

Date: Wed, 25 Jun 2008 09:44:23 +0200

From: "Jose Noheda" <jose.noheda@...>

Subject: Re: [Dojo-interest] New DataStore

To: dojo-interest@...

Message-ID:

      <f9fe82630806250044q544e5bb4s3122aa868e7cacb9@...>

Content-Type: text/plain; charset="iso-8859-1"

 

Hi,

 

Very interesting. Hibernate on the client! I think this really has

potential. There's just a thing I dislike and it's the mappings. If I'm

using (let's say) JPA I've already created my model objects. I don't want to

repeat a task that is, in addition, tedious and error prone.

 

So, here's my proposal, integrate this with DWR! You get the conversion from

server side objects for free, automatic registering in the EntityManager and

probably easier communications. Of course, you can keep the client side

dojo.data compatible but this technology really NEEDS a backend to be

useful. And from there, several persistence technologies can be plugged

easily (I'm thinking in JPA, Hibernate at the beginning). Of course, you may

want to develop other backend strategies for ruby or php.

 

I'm a DWR committer so I can probably help a little if you're interested.

I'm posting this in the DWR mailing list as well.

 

Regards,

 

On Tue, Jun 24, 2008 at 9:44 PM, Maulin Shah <maulinpshah@...> wrote:

 

>  I have built a new custom data store that I think people may find

> helpful. It allows you to represent your object model as simple javascript

> objects, and provides the mechanisms to connect to the server transparently.

> Its quite extensible and pluggable, and provides sensible default behavior.

> 

> Conceptually, its like an Object-Relational-Mapper geared towards the

> client as opposed to the server. A lot of the inspiration for it came from

> Hibernate.

> 

> 

> 

> I think it is quite intuitive, but I'd really like to get some feedback...

> 

> 

> 

> Here is a blog post about it:

> 

> 

> 

> 

> http://blog.medryx.org/2008/06/20/an-object-relation-mapper-orm-for-javascript-well-kind-of/

> 

> 

> 

> And I am in the process of posting the source on google code.

> 

> 

> 

> Thanks for your feedback! Hope this helps someone.

> 

> 

> 

> -maulin

> 

> http://blog.medryx.org

> 

> 

> 

> 

> 

> Maulin Shah, MD

> 

> 

> 

> _______________________________________________

> FAQ: http://dojotoolkit.org/support/faq

> Book: http://dojotoolkit.org/docs/book

> Forums: http://dojotoolkit.org/forum

> Dojo-interest@...<http://dojotoolkit.org/forumDojo-interest@...>

> http://turtle.dojotoolkit.org/mailman/listinfo/dojo-interest

> 

> 

---

_______________________________________________
FAQ: http://dojotoolkit.org/support/faq
Book: http://dojotoolkit.org/docs/book
Forums: http://dojotoolkit.org/forum
Dojo-interest@...

http://turtle.dojotoolkit.org/mailman/listinfo/dojo-interest

_______________________________________________
FAQ: http://dojotoolkit.org/support/faq
Book: http://dojotoolkit.org/docs/book
Forums: http://dojotoolkit.org/forum
Dojo-interest@...
http://turtle.dojotoolkit.org/mailman/listinfo/dojo-interest

[mikewse]

Hi Jose,

From the dojo mailing list. Please read the blog post and comment. I think this has potential. Mike, a step beyond for converters?

The article is an interesting exercise, yes.

(Btw, Joe has done the converters and I did the class mapping, but I guess you were thinking about this as an extension to class mapping?)

 

I too think it would be beneficial to make things work more seamless together with JPA/Hibernate, but the architecture proposed in the blog post may be taking things a bit too far IMO. I'm getting a feeling of inviting designs with just a database and JPA on the server side, and no business logic to restrict a client from f ex doing:

for( var i=0; i<1000000; i++ ) {

    var p = new Person(i);

    for( var prop in p ) p[prop] = "nonsense";

    p.save();

}

thereby overwriting a lot of stuff in the database.

 

Also, doing remote requests as part of new:ing objects feels like going towards the undesired parts of old-style CORBA programs, leading to a lot of requests between browser and server.

 

I guess the JPA/Hibernate support I would prefer myself would be more oriented along the lines of better integration of a converter with the PersistenceContext/Session (handling ids and object data sync/merge better), keeping the persistence logic on the server, rather than implementing this stuff on the client.

 

Best regards

Mike

[Robby O'Connor]

Hey,

Reverse ajax is not available in 1.1.x correct?

--rob

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[XMaNIaC]

yes

On Sun, Jun 29, 2008 at 10:04 PM, Robby O'Connor <robby.oconnor@...> wrote:

Hey,

Reverse ajax is not available in 1.1.x correct?

--rob

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[XMaNIaC]

I mostly agree but I think the security/performance issues (that exist) should be let to the developer. If he allows the behavior (ie by configuration) everything should be fine. As a matter of fact I like the abstraction provided by:

p = new Person(10)
p.name = 'Peter'
p.company = new Company('IBM')
p.save()

Even though I know that it's duplicating (at least) the number of requests, transactions et al.

Regards

On Sun, Jun 29, 2008 at 4:55 PM, Mike Wilson <mikewse@...> wrote:

Hi Jose,

From the dojo mailing list. Please read the blog post and comment. I think this has potential. Mike, a step beyond for converters?

The article is an interesting exercise, yes.

(Btw, Joe has done the converters and I did the class mapping, but I guess you were thinking about this as an extension to class mapping?)

 

I too think it would be beneficial to make things work more seamless together with JPA/Hibernate, but the architecture proposed in the blog post may be taking things a bit too far IMO. I'm getting a feeling of inviting designs with just a database and JPA on the server side, and no business logic to restrict a client from f ex doing:

for( var i=0; i<1000000; i++ ) {

    var p = new Person(i);

    for( var prop in p ) p[prop] = "nonsense";

    p.save();

}

thereby overwriting a lot of stuff in the database.

 

Also, doing remote requests as part of new:ing objects feels like going towards the undesired parts of old-style CORBA programs, leading to a lot of requests between browser and server.

 

I guess the JPA/Hibernate support I would prefer myself would be more oriented along the lines of better integration of a converter with the PersistenceContext/Session (handling ids and object data sync/merge better), keeping the persistence logic on the server, rather than implementing this stuff on the client.

 

Best regards

Mike