[KULRICE-4810] edoclite should give message to user when buttons are pressed Created: 04/Nov/10  Updated: 16/Jan/15

Status: Open
Project: Kuali Rice Development
Component/s: Development
Affects Version/s: 1.0.2.1
Fix Version/s: Backlog

Type: Improvement Priority: Major
Reporter: Chris Hyzer (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: Old
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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


Generated at Fri Jul 10 02:25:30 CDT 2020 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.