[LWUIT-497] Form title not tickering Created: 20/Dec/11  Updated: 20/Dec/11

Status: Open
Project: lwuit
Component/s: None
Affects Version/s: not determined
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: dreamscape Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: form, ticker, title

 Description   

In the latest version grabbed from the svn, the title of the Form component is not tickering even though the title text is larger than the available space.

I did some debugging:

In the constructor of Form, when the width and height values are set, the width and height of titleArea (Container) and the title (Label) remains unchanged (both are zero). Therefore title.shouldTickerStart() always returns false.






[LWUIT-429] Listen to soft keys on dialog/form Created: 13/Apr/11  Updated: 27/Apr/11  Resolved: 17/Apr/11

Status: Resolved
Project: lwuit
Component/s: None
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: tempusername Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: Form, LWUIT, keys, soft

 Description   

Hi,

it is impossible to use the addKeyListener to detect soft key presses on dialogs/forms
since the keyReleased method in form calls the menubar if they detect soft key codes and does a return (even if there are no commands on the menubar.
In general i think the keyPressed/KeyReleased etc methods should return a boolean to know if the event was consumed or not thus allowing to continue propagate or not onwards.
We have our own UI lib that we build and we also did at first the mistake of not using a boolean on the return value, however this change might be too big atm for lwuit so perhaps the call the keylisteners at the start of the function or perhaps not doing a return.
i would also like to explain the underline cause to which we want to listen to soft keys.
we use dialogs to show the user ok/cancel questions etc and when the ok/cancel are used as soft keys they look a bit ugly and not connected to the actual dialog itself and its also not so friendly to touch devices. we saw there is a theme constant that allow the commands to be shown as buttons on the dialog but they dont respond to their relative soft keys to allow for both touch and non-touch devices to use it in intuitive manner so we tried adding our own buttons and using the keylistener to connect the soft keys to the buttons.

(sorry for the looooooooooooooong explanation)



 Comments   
Comment by vprise [ 17/Apr/11 ]

I'm marking this as fixed since I changed the behavior of commandsAsButtons to check the softbuttons internally and perform the command when a physical softbutton is pressed.

We have event.consume() the approach of returning false from a method is only practical for simpler API's that don't rely on the observer pattern. Even in this case its a problem since people need to be familiar with the call chain of event dispatch.

We don't expose softbuttons since we don't want people to "hack" them, they are a problematic none-portable concept. If you really want to get access to them you should replace the menu bar (which we now allow).

Comment by tempusername [ 27/Apr/11 ]

Hi,

Was this change committed? i updated my src two days ago and i dont think its working.

Comment by vprise [ 27/Apr/11 ]

Yes: Dialog.java lines 919-935





[LWUIT-428] screen size change listener Created: 13/Apr/11  Updated: 27/Apr/11  Resolved: 16/Apr/11

Status: Resolved
Project: lwuit
Component/s: None
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: tempusername Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: Form, LWUIT, display, size

 Description   

Hi,

we have some forms that we place component center of the screen (by setting the margin of the container to be X percent from the screen width or height, as the margin values are absolute and not relative when the screen size gets change (like screen rotate) the values we used to do an absolute center (both vertical and horizontal) are no longer correct (and also other stuff like size of fonts maybe and size of components) but we dont know when the size changed as there is option in lwuit for us to listen to that event.
i think a size changed listener should be added and it should be called before the form sizeChangedInternal is called to allow us to do some re-calculations.



 Comments   
Comment by vprise [ 16/Apr/11 ]

The main problem is that size change is "flaky" at best, we handle it properly internally and allow a callback in Form for those who really know what they are doing. But it breaks often, mostly because of the very delicate order of reflows (adding more layout reflows will slow the UI and cause problems with things like growing text areas).
We need to allow margins/paddings in different units (its in my extensive TODO list).
However, for your particular use case you can use border layout and activate the absolute center flag to get that same effect.

Comment by tempusername [ 27/Apr/11 ]

i still think that notifying size has changed via a listener should be done because often you preload resources based on the screen resolution (fonts/icons etc) and in handsets like N95 which can switch from 240x320 to 320x240 you might want to switch full screen images from one to another (sure you can use lwuit resize image option but it would look as good as pre-loading a "good" image)

Comment by vprise [ 27/Apr/11 ]

We don't think that this use case is a good idea and don't want to encourage it. You can always derive Form and override the size changed callback, so this use case is supported just discouraged. If you are doing things like that manually, subclassing the Form is probably something you should do anyway.





[JERSEY-733] Encoded annotation is not working for form parameter. Created: 16/Jun/11  Updated: 29/Nov/13  Resolved: 29/Nov/13

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.6, 1.7
Fix Version/s: 2.5

Type: Bug Priority: Major
Reporter: paulnibin Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour
Original Estimate: 30 minutes
Environment:

I am testing using Jersey 1.6 in tomcat web container.


Attachments: File RestTest.war    
Tags: encoding, form

 Description   

According to the JAX-RS specification, Encoded annotation disables automatic URI decoding for Path, Query, Form and Matrix parameters.

But when I tested it, I found that the encoded annotation has no effect if it is used with Form Parameter.

I have attached a war file for testing. Deploy it in the tomcat.

The client for testing the service.

----------------------------------------------------------------------------------------------------------------------------------------------

import java.net.URI;

import javax.ws.rs.core.UriBuilder;

import com.sun.jersey.api.client.Client;
import com.sun.jersey.api.client.ClientResponse;
import com.sun.jersey.api.client.WebResource;
import com.sun.jersey.api.client.config.ClientConfig;
import com.sun.jersey.api.client.config.DefaultClientConfig;
import com.sun.jersey.api.representation.Form;

public class TestEncoded
{
    public static void main( String [] args )
    {
        ClientConfig config = new DefaultClientConfig();
        Client client = Client.create( config );
        WebResource service = client.resource( getBaseURI() );

        // Verifying path param
        ClientResponse clientResponse = service.path( "encoded" ).path( "testPath" ).path( "Test Value" )
                .get( ClientResponse.class );
        System.out.println( clientResponse.getEntity( String.class ) );

        // Verifying query param
        clientResponse = service.path( "encoded" ).path( "testQuery" ).queryParam( "param", "Test Value" )
                .get( ClientResponse.class );
        System.out.println( clientResponse.getEntity( String.class ) );

        // Verifying form param
        Form form = new Form();
        form.add( "param", "Test Value" );
        clientResponse = service.path( "encoded" ).path( "testForm" ).post( ClientResponse.class, form );
        System.out.println( clientResponse.getEntity( String.class ) );

        // Verifying matrix param
        service = client.resource( UriBuilder.fromUri(
                "http://localhost:8080/RestTest/rest/encodedTest/encoded/testMatrix;param=Test%20Value" ).build() );
        clientResponse = service.get( ClientResponse.class );
        System.out.println( clientResponse.getEntity( String.class ) );

        /*
         * The rest of the test cases invoke params that does not specify
         * encoded attribute.
         */

        service = client.resource( getBaseURI() );
        // Verifying path param
        clientResponse = service.path( "testPath" ).path( "Test Value" ).get( ClientResponse.class );
        System.out.println( clientResponse.getEntity( String.class ) );

        // Verifying query param
        clientResponse = service.path( "testQuery" ).queryParam( "param", "Test Value" ).get( ClientResponse.class );
        System.out.println( clientResponse.getEntity( String.class ) );

        // Verifying form param
        form = new Form();
        form.add( "param", "Test Value" );
        clientResponse = service.path( "testForm" ).post( ClientResponse.class, form );
        System.out.println( clientResponse.getEntity( String.class ) );

        // Verifying matrix param
        service = client.resource( UriBuilder.fromUri(
                "http://localhost:8080/RestTest/rest/encodedTest/testMatrix;param=Test%20Value" ).build() );
        clientResponse = service.get( ClientResponse.class );
        System.out.println( clientResponse.getEntity( String.class ) );

    }

    private static URI getBaseURI()
    {
        return UriBuilder.fromUri( "http://localhost:8080/RestTest/rest/encodedTest/" ).build();
    }
}

----------------------------------------------------------------------------------------------------------------------------------------------

You can see that for the form parameter the arguments are not encoded.



 Comments   
Comment by paulnibin [ 16/Jun/11 ]

Sorry. The test case is not formatted.

What should I do to show the test case in good format?

Comment by Marek Potociar [ 02/Sep/13 ]

Need to verify if the problem persists in Jersey 2. If yes, we need to fix it, if it's only Jersey 1.x issue, close it as won't fix/fixed in Jersey 2.

Comment by Michal Gajdos [ 29/Nov/13 ]

This behaviour is not required by JAX-RS 2.0 but you can use @Encoded with @FormParam in Jersey 2.





[JAVASERVERFACES-3075] HTML input elements without type attribute should be recognized as text inputs Created: 31/Oct/13  Updated: 08/Jan/14  Resolved: 31/Oct/13

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.4
Fix Version/s: 2.2.5

Type: Bug Priority: Minor
Reporter: kithouna Assignee: Manfred Riem
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish 4.0


Tags: attribute, form, html, input, type

 Description   

Consider the following form:

<form jsf:id="form">
  <label jsf:for="input">Foo</label>
  <input type="text" jsf:value="#{testBean.foo}" jsf:id="input"/>
  <h:message for="input"/>
  <input type="submit" jsf:action="#{testBean.save()}" value="Save"/>
</form>

When the type attribute is removed from the input element, the input element is not recognized anymore. The foo property of testBean is not set and the log shows 2 warnings because the label and h:message do not find the component with the ID "input".

I'm not sure if this requires a JSF spec change. IIRC the JSF spec says input elements with any type value (other than those with other meanings like button, submit etc.) should be rendered like h:inputText. One could argue the type attribute does not have any value when it's not specified, but the HTML 4.01 specification clearly states The default value for this attribute is "text" and it's very common in HTML to omit this attribute.



 Comments   
Comment by Manfred Riem [ 31/Oct/13 ]

You are indeed pointing out something that would nice to have unfortunately we have to implement what is specified at http://docs.oracle.com/javaee/7/api/javax/faces/view/facelets/TagDecorator.html

Please feel free to file this as a spec issue at the spec issue tracker at https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC

Thanks!

Comment by kithouna [ 31/Oct/13 ]

Spec issue: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1234





[JAVASERVERFACES-2403] Character encoding corrupt for UTF-8 on form submit Created: 01/May/12  Updated: 01/May/12  Resolved: 01/May/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.7
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: susnet Assignee: rogerk
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JBoss 7.1.1, Java EE 6


Tags: character, encoding, form

 Description   

I have a XHTML page with encoding UTF-8 like this: <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
If I submit a form the input parameters get corrupted if they contain national characters, for example Swedish characters; ÅÄÖ.
Although if there is a validation error and therefore the page reloads and then I submit the form again, then it works correctly.

If I change the charset to ISO-8859-1 it works correctly.

Maybe this has something to do with: JAVASERVERFACES-2217



 Comments   
Comment by rogerk [ 01/May/12 ]

Appears to be dup of http://java.net/jira/browse/JAVASERVERFACES-2217





[JAVASERVERFACES-2187] f:ajax processes enclosing form only Created: 11/Sep/11  Updated: 24/Feb/12  Resolved: 24/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: ajax
Affects Version/s: 2.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: cernicb Assignee: rogerk
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, Java 1.6.0_27, Glassfish 3.1.1 build 12, Jsf mojarra 2.1.3


Attachments: Zip Archive TestJSF.zip    
Tags: ajax, form, jsf, process

 Description   

When there is more than one form on the page, f:ajax execute attribute deals with enclosing form components only. Here's an example that doesn't work:

<h:form id="f1">
<h:commandButton id="prev" action="#

{test.prev}" value="Previous">
<f:ajax execute=":f2:test" render=":f2:test" />
</h:commandButton>
</h:form>
<h:form id="f2">
<h:inputText id="test" value="#{test.currPage}" />
</h:form>

And this one works:

<h:form id="fok">
<h:commandButton id="prevok" action="#{test.prev}

" value="Previous">
<f:ajax execute="testok" render="testok" />
</h:commandButton>
<h:inputText id="testok" value="#

{test.currPage}

" />
</h:form>

Managed bean "test" is request scoped. In mojarra 1.2 apps this has easily been achieved with help of richfaces 3.x a4j:support tag. This issue is related to JAVASERVERFACES-1719 (f:ajax execute=@all does the same as execute=@form ). There are common situations when there's one main form, and other one handling dialogs or modal panels. Communication between these two forms is highly needed.



 Comments   
Comment by rogerk [ 24/Feb/12 ]

Duplicate of http://java.net/jira/browse/JAVASERVERFACES-2172.





[GLASSFISH-18453] multipart/form-data problem with myfaces extension filter Created: 06/Mar/12  Updated: 29/May/13  Resolved: 29/May/13

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.2_b23
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: dani_drio Assignee: Ed Burns
Resolution: Works as designed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 3.1.2 build 23, jre 7, ubuntu linux


Attachments: Zip Archive TestCharset.zip    
Status Whiteboard:

myfaces ExtensionsFilter doesn't work with glassfish 3.1.2. A h:form with multipart/form-data with page encoding utf-8 sets h:inputText with wrong charset. As a result the database is corrupted with unreadable chars and the page is reloaded with strange characters. Also no file is upload by the managed bean. Maybe related with issue GLASSFISH-16740?

The same application works with glassfish 3.1, 3.0.1

Tags: encoding, form, jsf, multipart

 Description   

myfaces ExtensionsFilter doesn't work with glassfish 3.1.2. A h:form with multipart/form-data with page encoding utf-8 sets h:inputText with wrong charset. As a result the database is corrupted with unreadable chars and the page is reloaded with strange characters. Also no file is upload by the managed bean. Maybe related with issue GLASSFISH-16740?

The same application works with glassfish 3.1, 3.0.1



 Comments   
Comment by kchung [ 10/Mar/12 ]

Are you doing the file upload with servlet 3.0 Request.getPart() or on your own. If it is the latter, you may want to see if the patch in http://java.net/jira/browse/GLASSFISH-18444 fixes your problem.

Otherwise, you'll need to come up with a simple test case for me to work on.

Comment by dani_drio [ 10/Mar/12 ]

Related to the charset problem I attach a simple NetBeans project (TestCharset.zip) with a web app. Only one jsp exists with a simple form. To test:

  • Run the project
  • In the jsp form input type 'ó' and click the 'Send' button.
  • The input now shows 'ó' instead of 'ó'

Now, remove the enctype="multipart/form-data" and the forms works ok.

I tested the patch web-core.jar you suggested but not solve the problem.

Thanks in advance.

Comment by kchung [ 12/Mar/12 ]

The problem has nothing to do with multipart processing in the container. In fact, the following JSP page show the same symptom.

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<html>
<body>

<form method="post" action="form.jsp">
<input type="text" name="name" value="$

{param.name}

" size="12"/>
<input type="submit"/>
</form>

</body>
</html>

The problem is with the character encoding of the POST data. Depending on the browser, the request encoding may not be specified correctly.

If I add the following line after the page directive, it works as expected.

<% request.setCharacterEncoding("UTF8"); %>

Comment by dani_drio [ 13/Mar/12 ]

In my opinion the problem is with the web engine (or something related to JSF). The browser should receive the same headers related to encoding in both cases. If you try this JSF it will not work:

<%@page contentType="text/html" pageEncoding="UTF-8"%>

<%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
<%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>

<% request.setCharacterEncoding("UTF-8"); %>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

<f:view>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
</head>
<body>
<h:form id="mainForm" enctype="multipart/form-data">
<div>
<h:inputText size="12"/>
</div>
<h:commandButton value="Send"/>
</h:form>
</body>
</html>
<h:messages/>
</f:view>

This JSF has the request.setCharacterEncoding("UTF-8") as you suggested and works properly with older glassfish versions (with o without multipart) and in glassfish 3.1.2 when the multipart is not present. So, has no sense to get different behavior. It makes impossible to work our CMS with multi-language web applications.

Thanks.

Comment by kchung [ 13/Mar/12 ]

In your JSF test, what is the easiest way to display the text from h:inputText. Sorry I don't know JSF too much.

The addition of enctype="multipart/form-data" to h:form seems to do something strange. If I add an action to H:commandButton, it wouldn't even go there!

Comment by dani_drio [ 14/Mar/12 ]

Only needs to press the "Send" button. Because no binding to a managed bean exists JSF will restore the value automatically in the input.

I check the "action" for commandButton and works fine. So, in principle I discard a problem here.

I check the HTTP headers the browser receives with firebug and in both cases, with and without "multipart/form-data", seems to be ok.

It appears the problem is in the process of extracting the parameter values from the multi-part response the server receives. I think the server is assuming incorrectly the response is ISO-8859-1.

Comment by kchung [ 14/Mar/12 ]

Hmm.. I only got a blank in the input after hitting "Send" button. Running glassfish trunk with Internet Explorer 8.

If the problem is just using the wrong char encoding when extracting the request parameters, then inserting a java scriptlet to set the request char encoding should work. The thing that I am not sure of is when the code is executed. With JSF, there may be some timing issue.

It'd be great if you can come up with a test without JSF.

Comment by dani_drio [ 15/Mar/12 ]

I see some light ... I made a test without JSF and works as you says in previous message: it's needed the "request.setCharacterEncoding("UTF-8");" to work in both cases with and without multipart. That is not a surprise, and in the past (when no JSF exists) we forced this in a web filter.

When JSF is used I think mojarra do some "magic" process to set the properly enconding based in the last request or something similar. Googling I see this value is saved in the session attribute "javax.faces.request.charset". If you print the session attributes in the jsp:

<%
for (Enumeration e = request.getSession().getAttributeNames(); e.hasMoreElements(); )

{ String att = (String)e.nextElement(); out.println(att + ": " + request.getAttribute(att) + "<br/>"); }

%>

You will see this.

So, mojarra seems to works different that in previous versions, and the worse is the behavior is different with or wihout multipart.

Please, can you change the state of this bug to open?

Tanhks in advance.

Comment by kchung [ 15/Mar/12 ]

reopen and assign to Ed Burns to look into this further.

Comment by kchung [ 27/Mar/12 ]

I've fixed a related issue, http://java.net/jira/browse/GLASSFISH-18453. Can you verify if that also fixes this issue?

Comment by kchung [ 27/Mar/12 ]

Oops. I meant http://java.net/jira/browse/GLASSFISH-18516

Comment by dani_drio [ 27/Mar/12 ]

No, I try the last 4.0 (build 27) and has the same problem.

Comment by kchung [ 29/Mar/12 ]

Build 27 does not include the fix. Try b30.

Comment by dani_drio [ 31/Mar/12 ]

No, b30 does not solve the problem.

Comment by dani_drio [ 10/Sep/12 ]

Causally I found a solution. The problem seems to appear when this combination occurs:

  • the form is multipart
  • the page has a page directive declaring the encoding: <%@page pageEncoding="UTF-8"%>

The solution is:

  • declare in descriptor glassfish-web.xml the param: <parameter-encoding default-charset="UTF-8"/>
  • remove the page directive in all the jsf pages.

This solution also removes from the log the typical warning:

"Unable to set request character encoding to UTF-8 from context xxxx, because request parameters have already been read, or ServletRequest.getReader() has already been called"

regards.





Generated at Fri Mar 06 20:02:06 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.