[jstegemann]

Ok, I read your post too late. Maybe the minimal project I posted (see my last post) is usefull, too.

But here are the files you need. Both datasource, the GWT-module-description and the entry-point. I think it would be best to use the spring-hibernate-dmi sample a a base.


Your's

Jens

[jstegemann]

Just to be sure here are the two domain-classes, the html and the Spring application-context, though I do not think that you need any of these.


Your's

Jens

[michalg]

Hi,
I have got the similar problem:
http://forums.smartclient.com/showthread.php?t=14218
Still hope for a fix, but for now I have to override DSRequest and correct Date format when necessary.
Thanks,
MichalG

[PierrePlex]

I have got a very similar problem, too. Dates seem to be submitted in different formats, although they are declared exactly the same way in the datasource.
I would be very happy getting a fix for this.

Pierre

[Isomorphic]

We've made a change to resolve this issue. The fix will be present in the next nightly build (Feb 8 2011)
Please let us know if you continue to encounter the problem.

Regards
Isomorphic Software

[jstegemann]

Thank you once more for this very fast reaction.

I tested the actual nightly build and transmitting dates works now really good. Good work!

Unfortunately, when I now change the fields dateA and dateB from type "date" to "datetime" the time is not set at all on the properties on the JavaBeans.

If I choose "04/11/1978 00:30" for dateA for example the property on the bean ist set to "1978-04-10T00:00:00.000+0100"

The request from the console looks like

{
    "dataSource":"DatasourceA", 
    "operationType":"add", 
    "componentId":"isc_DynamicForm_0", 
    "data":{
        "dateA":"1978-04-10T22:30:00", 
        "elements":[
            {
                "dateB":"1978-04-11T13:16:00", 
                "name":"testB"
            }
        ], 
        "name":"testA"
    }, 
    "callback":{
        "target":[DynamicForm ID:isc_DynamicForm_0], 
        "methodName":"saveEditorReply"
    }, 
    "willHandleError":true, 
    "showPrompt":true, 
    "prompt":"Saving form...", 
    "oldValues":{
    }, 
    "clientContext":{
    }, 
    "requestId":"DatasourceA$6272"
}

I am sorry, but I am really depending heavily on this to work, that's the reason to bother you once more that soon...


Your's

Jens

[Isomorphic]

Really? That seems pretty unlikely..

1. is the field a java.sql.Date? If so, this is expected

2. what do you see in the server side console - the complete logs for the request

3. are you saying this happens for a date field on the main bean, or only in sub-beans?

4. are you saying this just changed or was previously happening for datetime fields?

[jstegemann]

I am pretty sure that it is my fault this time, but I just don't get it sorted out.

To your questions:

1. It is a java.sql.Date, you are right... I assume it should be java.sql.Timestamp?

2. What I posted is everything I get from the console - but I think it does not matter anymore having answered question one.

3. It happens for all date-fields no matter where - dito.

4. It worked before with java.sql.Date (I am pretty sure), but I think that was just because of the bug you corrected last night...

I cannot test it right now since I am already out of office, but I will do tomorrow morning.

That leaves me with the timezone problem from the beginning - getting a different time on the server than entered on the client although both are in the same timezone. Is there any documentation you can point me to? It has to work somehow I guess... Maybe it will work with java.sql.Timestamp...


Thank you again,

Jens

[Isomorphic]

OK, it's the java.sql.Date (and it can't have worked before).

java.sql.Date is explicitly a date with no time value. If you try to set a time, it remains 0.

[michalg]

Sorry to say that nightly 2011-02-08 does not solve this issue:
http://forums.smartclient.com/showthread.php?t=14218
Still ListGrid forced to create AdvancedCriteria sends date with time UTC, while FilterBuilder sends date only in request. In both cases OperatorId is GreaterThan.
MichalG

[Isomorphic]

Hi Michael - we'll take a look at that and address it in the other thread
Thanks