1. #1
    Sencha Premium Member
    Join Date
    Dec 2011
    Posts
    34
    Answers
    1
    Vote Rating
    0
    MarcT is on a distinguished road

      0  

    Default Unanswered: Problem with ValueProvider<T, Date>

    Unanswered: Problem with ValueProvider<T, Date>


    I have a ValueProvider<LogEntry, Date> props.timestamp() for LogEntry, which is an autobean loaded from JSON data.

    I use that value provider in the following grid code:

    Code:
            ColumnConfig<LogEntry, Date> timeCol = new ColumnConfig<LogEntry, Date>(props.timestamp(), 40, "Time");
            timeCol.setCell( new DateCell( DateTimeFormat.getFormat("HH:mm:ss.SSS") ) );
    This works fine in production mode, but I get an empty cell in dev mode, and if I try to call props.timestamp() myself in dev mode, the Date object it returns is null. The date in JSON is an ISO_8601 format string.

    This all works great in production, but I need dev mode too. Does anyone have an idea what's going wrong or how I can debug this?

  2. #2
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,640
    Answers
    107
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    All the generated ValueProvider is doing is calling the Date getTimestamp() method on your bean - if that returns null, then this too much return null. If you can confirm that the models do not return null when their getter is called, but that the generated ValueProvider does return null anyway, more code will help us to discover why this is happening.

    If that autobean property is null in dev mode, but not in prod mode, that suggests a bug in how your json is being turned into an AutoBean. That work is done in the GWT class com.google.web.bindery.autobean.shared.impl.StringQuoter.tryParseDate. This should be called the first time that each property is read, to see what the String value is, and translate it to a Date.

    If you can provide a testcase, with a JSON string and the autobean, autobeanfactory that can read it, this will help us to see if it is a formatting issue, GWT AutoBean issue, or GXT PropertyAccess issue.

  3. #3
    Sencha Premium Member
    Join Date
    Dec 2011
    Posts
    34
    Answers
    1
    Vote Rating
    0
    MarcT is on a distinguished road

      0  

    Default


    Thanks for pointing me at the StringQuoter.tryParseDate function. Breaking in that I found that our ISO-8601 date string did not have a trailing "Z" on the end. Leaving off the Z is legal, if not recommended because it's ambiguous. Like I said, it works fine in production mode, but dev mode was silently returning null. So it looks like an inconsistency in GWT's date parsing.

    I had our server guy add a 'Z' to the string and now it's working fine.

  4. #4
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,640
    Answers
    107
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    It could be worth taking this up with the GWT team by filing an issue at http://code.google.com/p/google-web-toolkit/issues/, or looking into making and submitting a patch to them for future versions of GWT.

    Glad you got this worked out.

  5. #5
    Sencha Premium Member
    Join Date
    Jun 2010
    Posts
    35
    Vote Rating
    0
    eguardiola is on a distinguished road

      0  

    Default


    Hi Marc,

    In development mode the date is parsed using this code from com.google.web.bindery.autobean.shared.impl.StringQuoter.class:

    Code:
      public static Date tryParseDate(String date) {
        try {
          return new Date(Long.parseLong(date));
        } catch (NumberFormatException ignored) {
        }
        if (date.endsWith("Z")) {
          date = date.substring(0, date.length() - 1) + "+0000";
        }
        try {
          return ISO8601.parse(date);
        } catch (ParseException ignored) {
        }
        try {
          return RFC2822.parse(date);
        } catch (ParseException ignored) {
        }
        return null;
      }
    being the ISO8601 pattern used

    Code:
      private static final String ISO8601_PATTERN = "yyyy-MM-dd'T'HH:mm:ss.SSSz";
      private static final DateFormat ISO8601 = new SimpleDateFormat(ISO8601_PATTERN, Locale
          .getDefault());

    But in the production mode a super source version is used that is a implementation that work only on javascript (client code). This implentation is on GWT /user/super/com/google/web/bindery/autobean/super/com/google/web/bindery/autobean/shared/impl/StringQuoter.java

    Code:
      public static Date tryParseDate(String date) {
        try {
          return new Date(Long.parseLong(date));
        } catch (NumberFormatException ignored) {
        }
        try {
          JsDate js = JsDate.create(date);
          return new Date((long) js.getTime());
        } catch (JavaScriptException ignored) {
        }
        return null;
      }
    So in client code you can see it is using the constructor of the javscript Date object. This constructor can deal with many ISO8601 formats allowing you to work with TimeZone info or not. For that reason your code works on production.

    Be aware that when you put timezone data, the parser may be adjusting time and dates values from UTC to local ones. It depends of the implemetation and configuration of the iso parser.

    Hope it helps.

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar