Bug 124393

I will move this bug to Woodstock after the break.

Created attachment 54522 [details]
the 6.0 result

Created attachment 54523 [details]
in 5.5.1 the world ist allright

The Web developer can use 6.0 first when this bug is fixed otherwise the great IDE is useless for us. We must have
control over the size of the components and not the IDE. Please fix this annoying bug. In 5.5.1 it works fine and 6.0
should be a progress.  When I connect a component to the styclass in the properties 6.0 hangs up. I have attached two
screenshots which shows the problem very clear. When I drag a table in 6.0 to a jsp page I don’t get the choice to
select an available sessionbean. 6.0 always creates a new sessionbean. When this bugs are fixed 6.0 is really top and
the best IDE in the world. 

Here you can test an application for retailers build within 5 months with about 90 dialogs and 230 sessionbeans and 90
tables. I have to convert to 6.0 because 5.5.1 is now very very very slow when I develop new dialogs but 6.0 is much
faster even with our big application. 

http://osretail.for-better.biz
  

Issue filed in the Woodstock Issue tracker

https://woodstock.dev.java.net/issues/show_bug.cgi?id=979

This change was introduced as part of the next gen architecture to Ajax enable woodstock components. All components are
rendered with a span around the particular element, so setting width no longer has any impact.  I'll let woodstock team
evaluate possible work arounds.

From Rick Ratta in Woodstock issue #982 (https://woodstock.dev.java.net/issues/show_bug.cgi?id=982):

The listbox and dropdown components need a "columns" property
similar to textfield and textarea to control dimensions of the listbox and dropdown.

Workaround

The workaround is to "select" the listbox and dropdown "select" elements
using redefined CSS selectors, and set the CSS width and height properties
in the selector definition. This will work for all listboxes and dropdown
widgets in the page or for specific listboxes and dropdowns.

If you look at the rendered HTML (actually the generated HTML) you will
see that the value of a listbox's select element's "class" attribute is "Lst"
or "LstMno" or "LstDis" if disabled,
and for a dropdown's select element, "MnuJmp" (jumpmenu) or "MnuStd" or
"MnuStdDis" if the listbox is disabled. There is no "MnuJmpDis".

The idea is too redefine these selectors in the JSP pages that have listboxes or
jump menus or dropdown menus. For example if you have a listbox with 
height 120px and width 50px you would define the selector in the body
of the "<webuijsf:body..>" tag as

<style type="text/css">
.Lst {
    width:50px;
    height: 120px;
}
.LstDis {
    width:50px;
    height: 120px;
}
</style>

And similarly for dropdowns redefining the dropdown and jump dropdown selectors.

If you need specific instances of a listbox or dropdown that need independent
dimensions within the same page, then you need to uniquely identify the 
instance. You can do this by specifying a value for the "className" attribute
of the component. For example, in the IDE (or in the JSP page) define the
"className" attribute for a "<webuijsf:listbox...>" say "ListBoxOne", so you
would have '<webuijsf:listbox className="ListBoxOne"...>' or in the IDE just
set the value of the "className" property to "ListBoxOne" (or any name you
prefer).

Then create the selectors in the JSP page as follows

<style type="text/css">
.ListBoxOne Lst {
    width:50px;
    height: 120px;
}
.ListBoxOne LstDis {
    width:50px;
    height: 120px;
}
</style>

The "ListBoxOne" symbol will be set on the containing span of the select
element which will have the class attribute value of "Lst" or "LstDis". 
This descendant selector will match the select element and define the
dimensions. Similarly this can be used for dropdown components as well.

These selectors can also be defined by customizing the theme at the
application level (See the latest theme documentation on how to do this).
Cutomizing the theme at this level will allow you to include application
defined CSS stylesheets (as well as any theme property) on every page,
that could contain the custom
selector definitions and these new selectors can be made to replace the
default selector names when the widgets are rendered in the page.
However for specific instances you will need to still specify
a value for the className property of the component.

Some history of this issue (Just substitute "listbox" or "dropdown" where
ever "textarea" or "textfield" is mentioned.)

A TextArea component like many if not all Woodstock components are not rendered
as a single HTML element. In this case there is an enclosing span that 
contains the "textArea" HTML element. It is this span that "represents" the
TextArea component. I won't go into the reasons here but this is the case
for many Woodstock components. It is the style attribute of the 
"span" HTML element
that is assigned the value of style property.

The "style" attibute and value that you see in the JSP page is the 
style attribute that is set in the IDE via positioning or resiziing on the
design surface. There is a simple rule that says this style attribute is
always placed on the top level HTML element of the component, for all
components.

In earlier versions of VWP and the Woodstock components, the previously
mentioned containing span was rendered conditionally. For a few reasons, the
standard use case in VWP was such that the enclosing span was never rendered.

This conditional rendering of the span was not supportable since the component
id would sometimes be rendered to the containing span and sometimes to the
"input" element or "select" element in the listbox/dropdown case. The component
id had to be rendered to the same HTML element every time. This is what led
to the removal of the resize handles. (In addition to the fact that pixel
resizing for text based elements was not reliable either, given that any
browser could use a different size font than was used when the page was
designed.)

For text fields and text area component the rows and rows and columns
properties must be used to size the rendered HTML elements.

These values should be in terms of "em" and not "px" to resize appropriately
when the font size changes.

After talking with Dongmei, this issue can continue as https://woodstock.dev.java.net/issues/show_bug.cgi?id=982.
Therefore, I'm closing this as won't fix.

Reopen the issue per Jayashri.

This bug is remaining open only as a placeholder. The real bug and its solution is being worked is at 
https://woodstock.dev.java.net/issues/show_bug.cgi?id=982.

Downgrading bug to P2 since there is a workaround.
Gowri, please mark the issue as fixed once a fix for this bug has been integrated into Woodstock.

in my web app there are mor than 200 drop down lists so your workaround is theory. Now I have to stop my development
because a 5.5.1 can't manage such a big application. 5.5.1 is extrem extrem slow 

have a look at my application and  you can see my drop downs. Its in German but click around and you will understand my need

http://osretail.for-better.biz

Is there a chance that you can try the workaround on one or two of your pages?  The sooner we can get you on NetBeans 6.x the better. We have been 
working on a number of performance improvements to VisualWeb that will soon appear in the first NB 6.1 milestone build targeted for this week. The 
difference can be dramatic - up to 50% faster for opening a page on Windows for example. Certain enhancements, such as on-demanding binding, could be 
especially helpful for large applications such as yours since it can reduce the overall size of the generated Java code. For details, see: 
http://wiki.netbeans.org/wiki/view/VW_Performance

Gowri,
  Issue 979 is still open, so hopefully that will be updated once the fix is integrated. So lets leave this open.

This bug has been fixed in Woodstock repository and the changes are brought over with build 3 integration.
Please verify the fix.

Hi i just tested the fix wit the last trunk-nightly. When I enter the width of a drop down list in the properties for a
drop down lists in new project it works fine. But when I enter the width to a drop down list from my migrated project
5.5.1 i get this messages when i want to run the application : org.apache.jasper.JasperException:  PWC6131: Attribute
width invalid for tag dropDown according to TLD 

6.1 Beta  uses the version jsp:root version="2.1"  5.5.1 uses the version  <jsp:root version="1.2"  to change 1.2 to 2.1
doesnt work. I there any workaround. Its really urgent for your application 

Peter

I have to make a comletion. the resizing in a new project works only in the design when you run the application its like
before . No improvment.  The longest expression defines the width of the drop down . 

Here are the comments from the component owner. Please update it with your comments.

------- Additional comments from rratta Mon Mar 10 15:33:11 +0000 2008 -------

> Hi i just tested the fix wit the last trunk-nightly. When I enter the width of
> a drop down list in the properties for a
> drop down lists in new project it works fine. But when I enter the width to a
>  drop down list from my migrated project
> 5.5.1 i get this messages when i want to run the application : 
> org.apache.jasper.JasperException:  PWC6131: Attribute
> width invalid for tag dropDown according to TLD 

That's correct. The TLD in any version of the components other than the
latest version does not define that attribute. I'm not sure how you got 
into this situation. If you see the property in the designer then you should 
have the correct jars and hence the TLD.

If you get the error at runtime but the width property appears in the designer
then the jars in the runtime war file have not been updated to the latest
woodstock jars.

If that is the case I have no idea of what you have to do to make sure that
your runtime has the latest jars.

Please confirm that this is the issue vs. the width property not working
in a new project.

This bug has been fixed in the Woodstock repository. But changes are yet to brought over to the NB code base. I will
mark it as fixed when the changes are brought over.

Here are the comments from the component owner.

------- Additional comments from rratta Mon Mar 10 20:30:37 +0000 2008 -------

oops.

Looks like I clobbered my own changes when I putback the large set of
"selectBase" changes.

I putback the fix for this issue 979 before the large set of changes
to selectBase. It looks like I clobbered the support for "width" in 
selectBase with those changes.

------- Additional comments from rratta Mon Mar 10 21:37:26 +0000 2008 -------

Restored the clobbered changes, that supported the widget width property.

Fix will be available into NetBeans once the next woodstock milestone is integrated which should be on Mar 27th.