Fórum

Alloy UI aui:input checkbox problem

Ian Gratton, modificado 13 Anos atrás.

Alloy UI aui:input checkbox problem

New Member Postagens: 17 Data de Entrada: 10/02/10 Postagens Recentes
Hi Folks,

its been a while but I'm not back on a Liferay project working with 6.0.5 and I have to implement some Portlets. I'm working against the com.liferay.util.bridges.mvc.MVCPortlet interface and I have my Portlet configured to support view, edit and help contexts. This aspect of the Portlet is fine.

When I'm in the edit context I'm obviously manipulating my Portlet's preferences using non-AJAX based Alloy UI forms.

I have a bit of a problem with the Alloy UI taglib - specifically when you use <aui:input type="checkbox"...... /> constructs

Now as I'm sure we are all aware in regular HTML forms you can associate a group of <input type="checkbox name="foo"...../> elements. For example:

<form method="get" action="test.html">
    <input type="checkbox" name="colour" value="red">Red
    <input type="checkbox" name="colour" value="green" checked>Green
    <input type="checkbox" name="colour" value="blue">Blue
    <input type="submit" value="Submit">
</form>


So - when the above form is submitted and I've checked the Green and Red checkboxes the HTTP request contains

colour=green&amp;colour=red


based upon the above values on the form.

Now what I'm trying to do is build the same functionality using the Alloy UI taglib and the <aui:input> tag....

The logic for bulding my list of checkable colours is as follows.

1. I have a simple Java enum that allows me to represent colours (maybe colours are a bad choice for this exmaple - who knows?) - This keeps the example simple (I think).

public enum ColourEnum
{
    Red,
    Green,
    Blue	
}


2. In my .jsp page I have the following

&lt;%
	for(ColourEnum c : ColourEnum.values())
	{
		System.out.println(c.toString());
		%&gt;
			<aui:input type="checkbox" name="colour" value="<%= c.ordinal() %>" label="<%= c.toString() %>" />
		&lt;%
	}
%&gt;


what actually comes out in the Portlet's UI is a list of checkboxes as you would expect, however, The Green checkbox is checked right from the start even though I've not said it should be. The value attribute of <aui:input> seems to be representing the CHECKED part of a HTML <input> tag e.g.

<input type="checkbox" name="colour" value="Blue" checked>


and NOT the value attribute.

This seems to have been reported in a few places on the Liferay forums (some as far back as 2009) - but there is no workaround/solution to the problem.

What I need to be able to do is:

int[] selectedColours = ParamUtil.getIntegerValues("colour");


based upon each of the checkboxes value attributes being based upon a colours ordinal position in the Enum I should get back a list of the value attributes associated with the checked checkboxes.

If I was working with regular HTML <input type="checkbox" /> tags this would be the case. If I'd checked Red and Blue I'd end up with:

selectedColours[] = {0, 2)


as the <aui:input> tag is mapping its value attribute back onto the <input> tags checked attribute there appears to be no way of associating a value with a checkbox.

Does anyone know if there is a fix to the alloy taglib that makes checkbox form inputs built from <aui:input> tags work correctly ? i.e.

The value attribute maps to the value attribute of the <input> tag and..
The checked attribute of the tag maps to the checked attribute of the <input> tag


Regards

Ian.
Ian Gratton, modificado 13 Anos atrás.

RE: Alloy UI aui:input checkbox problem

New Member Postagens: 17 Data de Entrada: 10/02/10 Postagens Recentes
OK,

I'm working around this issue now - its manageable by code - but - because of the nature of how the checkbox implementation of aui:input works means that you end up with a much bigger HTTP request from the browser emoticon.

I dont like spitting more data over the network than I absolutely need to and the size of the http request made bigger by the fact we are running within a portlet engine. All request parameters end up prefixed with the portlets identifier (not an issue really) etc.

So,

Imagine our enum again...

public enum ColourEnum
{
    Red,
    Green,
    Blue   
}


When I build up my set of checkboxes I now do the following:

for(ColourEnum c : ColourEnum.values())
{
    %&gt;
        <aui:input type="checkbox" name="<%= c.toString() %>" label="<%= c.toString() %>" />
    &lt;%
}


When this form gets posted back to the server the HTTP request includes the following style parameters. If I check the Red and Blue check boxes I end up with:

_myportletname_WAR_myportletname_INSTANCE_aVF5_Red=true
_myportletname_WAR_myportletname_INSTANCE_aVF5_Green=false
_myportletname_WAR_myportletname_INSTANCE_aVF5_Blue=true

So - when an aui:input derived check box is not checked its still posted back to the server with a value of false. With a regular HTML form the unchecked items would *not* be included in the HTTP request resulting in less data being spat at the network by the browser. I know this is a trivial amount of additional data - but take into account my list of checkboxes is about 50 items (its allowing you to select which fields you want visible in another part of the portlets view UI) and the additional size of the HTTP request is significant. I think I'm just old - I like efficiency.

So - now I know this happens to build up a list of checked items I do:

ArrayList<string> selectedColours = new ArrayList<string>();

for(ColourEnum c : ColourEnum .values())
{
    if(ParamUtil.getBoolean(request, c.toString()))
    {
        selectedColours.add(c.ordinal());
    }
}

Integer cols[] = selectedColours.toArray(new Integer[selectedColours.size()]);	
</string></string>


Which gives me the very short list of numerical identifiers which I'll store as a portlet proference.

If the aui:input worked properly I'd just have to do:

int[] selectedColours = ParamUtil.getIntegerValues(request, "colours");


So I can do what I need to - its just a bit more effort than it should be.

Anyone else found a better solution to this problem ? I guess the Alloy UI JSP taglib is unlikely to be fixed because so many bits of functionality in liferay are likely to now depend upon it working the way it currently does.
Leonardo Guilherme de Freitas, modificado 12 Anos atrás.

RE: Alloy UI aui:input checkbox problem

New Member Postagens: 2 Data de Entrada: 26/01/12 Postagens Recentes
Hello Ian. There's more than a year you've asked this and now I've stumbled in the same problem. Unfortunately I cannot do as you, iterating over all possible values, because I have an unpredictable amount of values and there might be too many of them to iterate.

Have you come to any other possible solution? If not, I'll stick to standard html input tag.

Thanks

Leonardo.
thumbnail
Suresh Yadagiri, modificado 7 Anos atrás.

RE: Alloy UI aui:input checkbox problem

Junior Member Postagens: 29 Data de Entrada: 24/03/14 Postagens Recentes
In JSP:
<aui:field-wrapper name="coverages">
<aui:input inlineLabel="right" name="coverage" type="checkbox" value="1" label="Men" />
<aui:input inlineLabel="right" name="coverage" type="checkbox" value="2" label="Women" />
<aui:input inlineLabel="right" name="coverage" type="checkbox" value="3" label="Kids" />
</aui:field-wrapper>


In Portlet;
long[] coverages = ParamUtil.getLongValues(actionRequest, "coverageCheckbox");
_log.info("coverages Selected are " +Arrays.toString(coverages));


If we notice , the check box name in jsp is "coverage" and in Portlet class , the name is "coverageCheckbox"
thumbnail
Claudio Carlenzoli, modificado 6 Anos atrás.

RE: Alloy UI aui:input checkbox problem

New Member Postagens: 12 Data de Entrada: 31/12/14 Postagens Recentes
I knew that Alloy Checkbox behaves as you explained but I had an issue reported in thread

https://web.liferay.com/community/forums/-/message_boards/message/44804126

As far I know right now Alloy Checkbox doesn't provide a way to set the value in the hidden field only when checked
You should read the property with "Checkbox" as suffix...but when used in specific cases as in the reported thread it gives trouble.

Am I missing something?

Sincerely

Claudio