You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Michael Victorov <m_...@mail.ru> on 2006/08/28 13:31:32 UTC

ROPWSDL

Hello Andrus, Kevin, All.

In the last post we had discussed entity resolving in my project.
-----------------------------------------------------------------------
>> 4. It would be better to remove .driver.xml file (with db info) from
>> client side. But I need working local configuration on client side to
>> map entities to classes and do validateForSave() (etc...). Is there
>> some crorrect way to make configuration work (maybe partly) without
>> .driver.xml class?
> 
> Per my comment on #2, I hope we can still get the mapping from the
> server and avoid this proble all together. Then on the client you can
> create a mapping of abstract entity name (e.g. "Artist") to a client
> class name (e.g. "my.special.Artist") - this can be a hashmap loaded
> from properties or something. Then you can merge it with the
> EntityResolver obtained from the server.
----------------------------------------------------------------------

I  tried  to  get as much entity resolving related data from server as
possible.   I   decided   to   keep  obj-entity  and  obj-relationship
definitions  at  the  client  side  and  all other things are got from
server (through bootstrap request). These "all other things" are query
definitions...

I think the best way is to keep client configuration in slightly
modified *.map.xml format.

Bases:
1. I need to keep entity name to class name mappings on client.
2. I need to keep obj-entity attribute types on client.
3. So I also need to keep info about what obj-entity contains
what attribute.
4. It seems to be good for Cayenne server to have the definition
of what it can do and what classes it can process availbale
fot clients.
5. If I keep mapping info needed for (1) - (3) in fromat
like .properties files (etc...) then client will have strange
configuration files with info which partialy describes server
structure and which is not enough to understand what exactly
objects it can work with.


So I have done following modifications:

 - No "db-entity" elements in *.map.xml files on client side.
 - No "db-relationship" elements.
 - "Obj-entitiy" has no "dbEntityName" attribute.
 - "Obj-relationship" has no "db-relationship-path" attribute.
 - "Obj-relationship" has attribute "toMany". Originally this
   information was in the "db-relationship" declaration.
 - "Obj-relationship" has attribute "reverseRelationshipName"
   which meaning is understood from it's name.
 - "Obj-relationship" has attribute "readOnly".
 - No "query" elements. Query information is loaded directly from
   server.

We have no platfrom-dependend data in the SOAP interchange and also
we have no data base info at the client side.
   
As I understood, all mapping-related Cayenne classes can work normally
without  things  which  I  removed.  Except  ObjRelationship.  You use
package  protected  class org.apache.cayenne.map.ClientObjRelationship
for implementing client entites. I made an analogue.

I  also  created  ClientMapLoader  class  which  can  load client-side
mapping  info  from  this file format. It is the same as your original
MapLoader with few changes.

Loaded client data is merged with info provided from server at the
bootstrap stage.

I  created  an Ant task for generating client configuration files from
server-side   (normal)   configuration   and  a  task  for  generating
client-sied classes from such client configuration.

I think it would be nice to have jar file with client config and
classes available for downloading from web app.

What do you think about it?


  

-- 
Best regards,
 Michael                          mailto:m_victorov@mail.ru


Re: ROPWSDL

Posted by Andrus Adamchik <an...@objectstyle.org>.
Catching up on this....

On Aug 28, 2006, at 3:31 PM, Michael Victorov wrote:
> I  tried  to  get as much entity resolving related data from server as
> possible.   I   decided   to   keep  obj-entity  and  obj-relationship
> definitions  at  the  client  side  and  all other things are got from
> server (through bootstrap request). These "all other things" are query
> definitions...
>
>
> So I have done following modifications:
>
>  - No "db-entity" elements in *.map.xml files on client side.
>  - No "db-relationship" elements.
>  - "Obj-entitiy" has no "dbEntityName" attribute.
>  - "Obj-relationship" has no "db-relationship-path" attribute.
>  - "Obj-relationship" has attribute "toMany". Originally this
>    information was in the "db-relationship" declaration.
>  - "Obj-relationship" has attribute "reverseRelationshipName"
>    which meaning is understood from it's name.
>  - "Obj-relationship" has attribute "readOnly".
>  - No "query" elements. Query information is loaded directly from
>    server.
>
> We have no platfrom-dependend data in the SOAP interchange and also
> we have no data base info at the client side.

Great. In the future we may use DataMap.getClientDataMap(..) which  
also strips DB* part, to provide some sort of defaults to the client,  
and use the client map to override the server definitions (after  
working with JPA, I started to appreciate defaults :-)).


> I think it would be nice to have jar file with client config and
> classes available for downloading from web app.

Then why bother with an extra *.map.xml, since  
DataMap.getClientDataMap(..) can provide one.

Andrus

Re: ROPWSDL

Posted by Kevin Menard <km...@servprise.com>.
Mike Kienenberger wrote:
> For large code contributions, we must have an ICLA on file from the 
> contributor.
> I don't think using "Grant license" is sufficient in those cases,
> although it's certainly necessary.
I'll request Bruno and Michael to fill one out.  In the interim, will 
committing their contributions to the soc module be problematic?  The 
eventual goal will be to sandbox the projects and integrate what we can 
into the distribution.  Before that happens, I'll definitely make sure 
that we have what we need licensing-wise.

-- 
Kevin

Re: ROPWSDL

Posted by Mike Kienenberger <mk...@gmail.com>.
On 9/6/06, Andrus Adamchik <an...@objectstyle.org> wrote:
> I am looking at CAY-637, and I noticed that it is not a patch, but
> rather a link to an outside repository. There is a legal issue with
> such submission. We can't just take an outside code and commit it to
> Apache. We either need a Contributor License Agreement from Michael
> [1], or much better - Michael should archive the entire submission
> and attach it to CAY-637 via "Attach File" link in Jira, checking
> "Grant license to ASF.." option.

For large code contributions, we must have an ICLA on file from the contributor.
I don't think using "Grant license" is sufficient in those cases,
although it's certainly necessary.

Re: ROPWSDL

Posted by Andrus Adamchik <an...@objectstyle.org>.
Michael, Kevin -

I am looking at CAY-637, and I noticed that it is not a patch, but  
rather a link to an outside repository. There is a legal issue with  
such submission. We can't just take an outside code and commit it to  
Apache. We either need a Contributor License Agreement from Michael  
[1], or much better - Michael should archive the entire submission  
and attach it to CAY-637 via "Attach File" link in Jira, checking  
"Grant license to ASF.." option.

Andrus

[1] http://apache.org/licenses/