Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-4810

edoclite should give message to user when buttons are pressed

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0.2.1
    • Fix Version/s: Backlog
    • Component/s: Development
    • Labels:
    • Similar issues:
      KULRICE-3543Edoclite applications throw an Exception when user double clicks an Action button.
      KULRICE-4809should be able to customize button text in edoclite
      KULRICE-8396Pressing Enter with cursor in search field gives inappropriate messages on Several KRMS Rules Search Interfaces
      KULRICE-3544When the validateAttributeDefinition method is called for an Edoclite Role, and the parm does not validate successfully, an Exception is throw.
      KULRICE-1744Implement proper Super User support in EDocLite
      KULRICE-1412Answering Question Prompt gives the user an HTTP Status 500
      KULRICE-4282Bootstrap Filter and EDocLite
      KULRICE-8781Radio button values are not reset when clear button is pressed
      KULRICE-822Backdoor message missing on EDocLite screens
      KULRICE-5341UserSession gets bound to a thread, and eDocLite documents are not establishing user session properly
    • Rice Module:
      KEW
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      Two requests:

      1. By default, when a "route" or "approve" or any button is pressed, the edoclite displays again in readonly form with no message to the user that it was submitted. This confuses users. By default The edoclite should be able to display "The form was submitted" or something at the top in a div that can be styled.

      2. Rice should have a variable which should be able to be queried from xsl that indicated that the page is being displayed due to a user action being submitted. Then the edoclite is more flexible in how this is handled.

      Here is the current workaround and comments from Eric:

      Chris, I think this is a good enhancement request and would welcome you submitting a jira for this. The post method sounds like a good workaround, though it would cause problems if it were the way this was implemented in the general case (i.e. for those who might be using dropdown-refresh behavior which does a post, or for those who are using multi-page forms). Would it be sufficient for edoclite to expose the last "action" that was taken, or at least information that an action was taken? Seems you could key off of individual actions (such as submit and approve) or just the fact that a document action was taken in order to display a reasonable message to the user. And EDL should probably display something reasonable by default anyway.

      Thanks,
      Eric

      On Nov 4, 2010, at 2:24 AM, Chris Hyzer wrote:

      I guess I still don't understand how this would work...

      <xsl:if test="$docStatus = 'ENROUTE' and $isUserInitiator and $globalReadOnly">

      I think doc status is ENROUTE when people approve, right? I would like the message to appear for the initiator or any approvers after clicking a button
      Same comment on isUserInitiator
      For globalReadOnly, same comment, are there cases where globalReadOnly is true that aren't after someone clicks a button? i.e. when viewing a document? Or when approving?

      Does anyone else want this? Should I open a Jira so there is a built in way?

      This is how I handled it, it seems to work (let me know if there is a gap). Im sure there is a better way, but thought I would share, just detect if http method is post...

      1. Make a filter to hold the request in a threadlocal (does this exist already)?

      /**

      • @author mchyzer
      • $Id$
        */
        package test;

      import java.io.IOException;

      import javax.servlet.Filter;
      import javax.servlet.FilterChain;
      import javax.servlet.FilterConfig;
      import javax.servlet.ServletException;
      import javax.servlet.ServletRequest;
      import javax.servlet.ServletResponse;
      import javax.servlet.http.HttpServletRequest;

      /**
      *
      */
      public class HttpRequestThreadLocalFilter implements Filter {

      /** keep the request here */
      private static ThreadLocal<HttpServletRequest> threadLocalHttpServletRequest = new ThreadLocal<HttpServletRequest>();

      /**

      • @see javax.servlet.Filter#destroy()
        */
        public void destroy() {
        }

      /**

      • @see javax.servlet.Filter#doFilter(javax.servlet.ServletRequest, javax.servlet.ServletResponse, javax.servlet.FilterChain)
        */
        public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain)
        throws IOException, ServletException {

      HttpServletRequest httpServletRequest = (HttpServletRequest)servletRequest;
      threadLocalHttpServletRequest.set(httpServletRequest);
      try

      { filterChain.doFilter(httpServletRequest, servletResponse); }

      finally

      { threadLocalHttpServletRequest.remove(); }

      }

      /**
      *

      • @return the request
        */
        public static HttpServletRequest httpServletRequest() { return threadLocalHttpServletRequest.get(); }

      /**

      • see if this is a post
      • @return if this is a post
        */
        public static boolean isPost() {
        HttpServletRequest httpServletRequest = threadLocalHttpServletRequest.get();
        if (httpServletRequest != null)
        Unknown macro: { if (httpServletRequest.getMethod() == "POST") { return true; } }

        return false;
        }

      /**

      • @see javax.servlet.Filter#init(javax.servlet.FilterConfig)
        */
        public void init(FilterConfig arg0) throws ServletException {
        }

      }

      2. Put this in the web.xml

      <filter>
      <filter-name>HttpRequestThreadLocalFilter</filter-name>
      <filter-class>test.HttpRequestThreadLocalFilter</filter-class>
      </filter>
      ...

      <filter-mapping>
      <filter-name>HttpRequestThreadLocalFilter</filter-name>
      <url-pattern>/*</url-pattern>
      </filter-mapping>

      3. Put something in a common text file:
      <xsl:template name="submittedMessage">
      <div class="submittedMessage">The form was submitted</div>
      </xsl:template>

      4. Add something to the CSS:

      div.submittedMessage

      { padding:5px; border-color:#7794C9; border-width:3px; border-style:dashed; margin-top: 20px; margin-bottom: 10px; font-weight: bold; }

      5. Add to edoclite or widgets:

      <xsl:variable name="isPost" select="java:test.HttpRequestThreadLocalFilter.isPost()" />
      ...

      <xsl:choose>
      <xsl:when test="($isPost)">
      <xsl:call-template name="submittedMessage" />
      </xsl:when>
      </xsl:choose>

      From: Westfall, Eric Curtis ewestfal@indiana.edu
      Sent: Wednesday, November 03, 2010 11:18 PM
      To: Chris Hyzer
      Cc: Carroll, Timothy Dale; rice.collab@kuali.org
      Subject: Re: [kuali] confirmation of submitted edoclite

      We have a couple of enhancements we need to contribute back from IU, one is the ability to define <param name="..."> style configuration in your edl definition and then utilize that from the stylesheets. As part of that, we implemented a feature that allows you to turn off the "disabled" html input tags and replace them with text output which is the way that most applications work when displaying read only data. This is particularly important for textareas when the content is outside of the visible area.

      Additionally, there is some state you can read from the edl xml to determine if the user just submitted/approved the document. We do it for some of our docs here, here is the specific condition we use:

      ...
      <xsl:variable name="docHeaderId" select="/documentContent/documentState/docId" />
      <xsl:variable name="docStatus" select="//documentState/workflowDocumentState/status" />
      <xsl:variable name="isUserInitiator" select="my-class:isUserInitiator($docHeaderId)" />
      ...
      <xsl:if test="$docStatus = 'ENROUTE' and $isUserInitiator and $globalReadOnly">
      ...
      </xsl:if>

      Hope that's useful.

      Thanks,,
      Eric

      On Nov 3, 2010, at 9:31 PM, Chris Hyzer wrote:

      Thanks, do you mind sharing that?

      Chris

      ----Original Message----
      From: Carroll, Timothy Dale tcarroll@illinois.edu
      Sent: Wednesday, November 03, 2010 1:17 PM
      To: Chris Hyzer
      Cc: rice.collab@kuali.org
      Subject: Re: [kuali] confirmation of submitted edoclite

      I'm sure you could modify the widgets.xml to check for this condition before displaying the read-only form. In fact, what we have done is to reformat the document when it is in a read-only state to address accessibility and usability problems. For example, put text in <span> and <div> tags, so text that is in <textarea> and <input> fields are not locked from scrolling etc. People generally prefer to read the text as a document rather than a form. This reformatting has also made it more printer friendly as well.

      tc

      On Nov 3, 2010, at 12:42 PM, Chris Hyzer wrote:

      We might have discussed this before, but we are getting complaints from confused users so I will ask again...

      When an edoclite is submitted (routed, accepted, etc), the screen turns readonly, and the upper right says ENROUTE.

      Is it possible to put text on that screen that says "Your form was submitted" or something so the user knows that the button did something?

      Or... can I detect something when the screen is displaying so I know it is in the READONLY clicked state, so I can do something in javascript or something to put that message in a DIV or javascript alert or something?

      Thanks!
      Chris

        Activity

        No work has yet been logged on this issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            Chris Hyzer (Inactive)
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Structure Helper Panel