Announcement Announcement Module
Collapse
No announcement yet.
Questions about Spring faces, JSF and date field Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Questions about Spring faces, JSF and date field

    Code:
     <div class="input">
                                <sf:clientDateValidator required="true" >
                                    <h:inputText id="data_prestito" value="#{booking.data_prestito}" required="true">
                                        <f:convertDateTime pattern="yyyy-MM-dd" timeZone="EST"/>
                                    </h:inputText>
                                </sf:clientDateValidator>
                            </div>
    1) How can obtain the date in the format:
    dd/MM/yyyy
    Now i obtain the format:
    MM/dd/yyyy
    2) How change the language of that date validator?
    I would like obtain the name of the month in my language.
    3) How i can customize the color of that date validator?
    4) Where is the link with information about the api of spring faces?

    Thanks.

  • #2
    Someone can help me?

    Comment


    • #3
      just a guess

      <f:convertDateTime pattern="dd/MM/yyyy"/>

      Comment


      • #4
        Still does not work.

        Now i has tried to use calendar from richfaces because that problem hasn't resolved.

        Comment


        • #5
          Can we get some tips on clientDateValidator usage from anyone (SWF developers?) please?

          Looking for:
          How to set the date pattern
          How to restrict date entries with upper or lower bounds

          Any way to do this with the tag, or will I need to to do this manually on the back end?

          *EDIT*

          Okay, I'm able to use Trinidad's validateDateTimeRange, but with a name like "clientDateValidator", one would think it would have the ability to validate date ranges or bounds.

          Also, I'm getting some kind of javascript error when I do a browser refresh, which is interfering with my ability to use some navigation links. I don't have access to the tools (Firefox, Firebug) to examine this further. Can anyone reproduce this?
          Last edited by InverseFalcon; Feb 12th, 2009, 10:44 PM.

          Comment


          • #6
            Hmm... So I'm not the only one.

            I've got the same problem, but really feel I must be missing something...

            Code:
            <sf:clientDateValidator>
            	<h:inputText id="Inp107"  value="#{form.date}" >
            		<f:convertDateTime pattern="#{form.datePattern}"/>
            	</h:inputText>
            </sf:clientDateValidator>
            The date pattern is contructed from a locale, and is used elsewhere to format the output of a list of dates on the same page, also using f:convertDateTime (so I know that's working OK).

            However, when the pattern is set to a NZ format ("d/MM/yyyy") and my browser and regional settings are also set to the same locale, sf:clientDateValidator displays the date selected via the widget in "mm/dd/yyyy" format.

            However, if I remove sf:clientDateValidator from the page, the date input reverts to "dd/mm/yyyy" format - but then I've lost the widget and it's nice validation error handling.

            It really looks like sf:clientDateValidator is either picking up it's date pattern from somewhere else, or is getting confused by the server locale.

            Help!

            Comment


            • #7
              I've been able to get more control over this widget by creating it manually through Spring JS instead of using the tag. Since it's using Facelets, you can make it into a custom tag so the markup becomes similar. You'll get more control over widget attributes, but you'll need to supply the ID of the decorated element, as it doesn't currently have the ability to look it up itself (I'm rather weak in this area, so any improvements and suggestions are welcome).

              Code:
              <ui:composition xmlns="http://www.w3.org/1999/xhtml"
                    xmlns:ui="http://java.sun.com/jsf/facelets"
                    xmlns:c="http://java.sun.com/jstl/core">
              
                <!-- Replaces the ClientDateValidator from Spring Faces.  This version adds the
                    Dojo decorations faster, preventing styling "spasms" as the widget decorates itself.
                    Also added the ability to change the display formatting on the date and to set
                    min and max constraints.
                    
                    Does not actually do anything with the decorated element.  This is still
                    encouraged in order to group the generated javascript with the element it's
                    decorating, which ensures that the Javascript will always refresh with the
                    element.
                -->
                    
                <!-- Accepts the following attributes:
                      decoratedElementId
                      displayDatePattern    (defaults to yyyy-MM-dd)
                      required              (defaults to false)
                      promptMessage
                      invalidMessage
                      rangeMessage
                      minDate               (inclusive, not required, in format yyyy-MM-dd)
                      maxDate               (inclusive, not required, in format yyyy-MM-dd)
                -->
                    
                <!-- Does not handle the following sf:clientDateValidator attributes:
                      lowercase
                      propercase
                      regExp
                      uppercase
                -->
              
                <c:if test="#{empty displayDatePattern}">
                  <c:set var="displayDatePattern" value="yyyy-MM-dd"/>
                </c:if>  
                
                <c:if test="#{empty required}">
                  <c:set var="required" value="false"/>
                </c:if> 
              
                <ui:insert/>
              
                <script type="text/javascript">
                  /* <![CDATA[ */      
                  dojo.require("dijit.form.DateTextBox");
              
                  var decoratedElement = dojo.byId('#{decoratedElementId}');
                  var minDate = '#{minDate}';
                  var maxDate = '#{maxDate}';
                  
                  if (decoratedElement != null) {
                  
                    var widgetConstraints = {
                      datePattern:'#{displayDatePattern}'
                    }
                    
                    if (minDate != '') {
                      widgetConstraints['min'] = minDate;
                    }
                    
                    if (maxDate != '') {
                      widgetConstraints['max'] = maxDate;
                    }
                    
                    var widgetAttributes = { 
                        datePattern : 'yyyy-MM-dd',
                        promptMessage : '#{promptMessage}', 
                        invalidMessage : '#{invalidMessage}', 
                        rangeMessage: '#{rangeMessage}',
                        constraints: widgetConstraints,
                        required: #{required}};
                  
                    Spring.addDecoration(new Spring.ElementDecoration({    
                        elementId : decoratedElement,    
                        widgetType : 'dijit.form.DateTextBox',    
                        widgetAttrs : widgetAttributes}));
                  }
              
                  /* ]]> */
                </script>
              </ui:composition>

              Comment


              • #8
                Based on that, and the other posts in this thread, it really looks like sf:clientDateValidator doesn't support date pattern localisation.

                Seems to me like a very major shortfall in a date widget.


                I've just looked to see if this has ever been raised as a Jira - but, surprisingly, I can't find one. But I guess there's no chance of getting this fixed in Webflow 2 - it looks like all the development effort is now going into Webflow 3.

                Comment


                • #9
                  You may want to see if this is really a shortfall in the sf:clientDateValidator, or in the DOJO widget used under the hood.

                  Comment


                  • #10
                    Originally posted by InverseFalcon View Post
                    You may want to see if this is really a shortfall in the sf:clientDateValidator, or in the DOJO widget used under the hood.
                    Hmm... Maybe...

                    Then again, if I bought a car and the engine was faulty, I wouldn't expect to have to contact the mechanic who built the engine in the first place.

                    I still find it hard to beleive that sf:clientDateValidator doesn't support localisation - whatever the underlying cause is for that.


                    It's not an easy sell, is it? I'm trying to think of a suitable marketing slogan:

                    Spring Webflow 2: JSF tags bringing the local back to localisation. We're pretending other countries don't exist

                    Comment


                    • #11
                      Originally posted by DentA View Post
                      Hmm... Maybe...

                      Then again, if I bought a car and the engine was faulty, I wouldn't expect to have to contact the mechanic who built the engine in the first place.

                      I still find it hard to beleive that sf:clientDateValidator doesn't support localisation - whatever the underlying cause is for that.


                      It's not an easy sell, is it? I'm trying to think of a suitable marketing slogan:

                      Spring Webflow 2: JSF tags bringing the local back to localisation. We're pretending other countries don't exist
                      Car analogies only go so far, I think, especially when we're talking about software. Keep in mind that Spring JS and Spring Faces only wrap and decorate with existing DOJO elements, they aren't rewriting the entire library.

                      In any case, it's best to pinpoint the source of the flaw. If it's in Spring Faces or Spring JS, because of some inability to specify or interpret locale, then the SWF team should have full responsibility and a JIRA should be opened.

                      If it's a flaw in the dropdown date widget in DOJO, then it's the DOJO team that needs to offer the fix. The SWF team might be helpful in contacting DOJO informing them of the flaw, but users can do the same.

                      Comment


                      • #12
                        I like the car analogy. Is it more difficult for a consumer to figure out whether the problem is in the engine or elsewhere in the car than the car maker experts? I think we should go ahead to create a JIRA.

                        Comment

                        Working...
                        X