Bug 76583 - I18N - generated List.jsp, etc from entity class does not show multibyte correctly
I18N - generated List.jsp, etc from entity class does not show multibyte corr...
Status: RESOLVED WONTFIX
Product: javaee
Classification: Unclassified
Component: Code
5.x
Sun All
: P2 (vote)
: 6.x
Assigned To: martin_adamek
issues@javaee
: I18N
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-19 01:00 UTC by Ken Frank
Modified: 2007-06-20 06:39 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
image (76.30 KB, image/gif)
2006-05-19 01:03 UTC, Ken Frank
Details
image (56.65 KB, image/gif)
2006-05-19 01:04 UTC, Ken Frank
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Frank 2006-05-19 01:00:09 UTC
running in ja locale using 55beta

create in derby a table with mbyte in column name and data

create web app, then entity class from dbase using the table created with mbyte

then create jsf from entity class and the 4 jsp files, like List.jsp are generated.

open the List.jsp and you can see the mbyte for the table or col names does not
display correctly -- see the attached gif and the red area at bottom or in
explorer for what correct mbyte looks like to compare with the ..... areas of
List.jsp

one gif is from windows, with the .... where mbyte should be, the other from
solaris, where what looks like mbyte that is shown is not correct and its all
the same 'character'



in the runtime, dbase section, the mbyte of the table and col names look
ok also.
Comment 1 Ken Frank 2006-05-19 01:02:34 UTC
the second gif on left shows the correct mbyte for the table and col names in
the db explorer.
Comment 2 Ken Frank 2006-05-19 01:03:20 UTC
Created attachment 30511 [details]
image
Comment 3 Ken Frank 2006-05-19 01:04:29 UTC
Created attachment 30512 [details]
image
Comment 4 Ken Frank 2006-05-19 17:29:23 UTC
Related to use of multibyte, assumptions are that mbyte
can be used in new j2ee persistence and other new areas for 55
such as in names of projects, names of persistence units,
names of java files and classes, etc.

can you look at
the new code and functionality to make sure its
ok and let us know if there is some restriction
based on persistence or other specs related to j2ee5 ?

ken.frank@sun.com
Comment 5 Pavel Buzek 2006-05-23 14:13:17 UTC
I guess the best solution would be to generate the jsf pages with I18N, probably
using <f:loadBundle ..> and put the messages into a bundle. I think that
generating these pages with I18N instead of inline messages would be nice. But I
am little bit hessitant if this is not more like a new feature for 5.5 then a
bugfix. The code generated by this wizard should be a simple "get me started"
code, not an attempt to solve all concievable issues of web app development.
Note that we currently do not support I18N of JSP pages. For example EL code
completion does not take <f:loadBundle> into effect.
I am not saying a strict NO, I am just raising questions. Any comments?

Also, is there any other simpler way to solve this problem (e.g. just generating
the whole pages in japanese)?

Thanks for bringing this up, Ken.
Comment 6 Ken Frank 2006-05-23 15:48:31 UTC
I don't think this issue is related to user doing i18n of their app
in context of using their own bundle files -- it would be great to do this
and there is an RFE on providing some equivalent of the i18n wizards for jsp
or other file types than java.

But this issue is not about that - its just the case where mbyte is 
used in name of some table or column, or perhaps in project name,
persistence unit name, etc -- anywhere where it might show up
in generated jsp or java files when user is doing things
with new persistence features and creating entity class,
entity class from dbase, jsf from dbase, etc.
(and thats why in description I also asked for feedback 
if any restrictions to using mbyte in project names,
persistence unit name, etc related to this new functionality --
please reply on that.

ALSO, can you elaborate more on what is meant by 
- we don't support i18n of jsp pages -- it just refers
to the code completion not happening for it, not that user
can't do it themselves like using the load bundle, and that
it would work ? If its just this, I can file RFE;
if it won't work at all, seems like a separate issue.

ken.frank@sun.com
Comment 7 Ken Frank 2006-06-14 04:55:39 UTC
This issue also means user cannot deploy/run with an entity class that
has mbyte as a column or table name (ie name of class for table or name
of variable as column -- since the jsp does not have the mbyte correctly,
it means the build or deploy will not work, since the mbyte values in the jsp
dont match those in the java file

I replaced the mbyte in jsp with the correct values as to encoding and
it worked - a table with a column with mbyte was created in dbase
(not sure if a table with mbyte table name is working)

but even for derby, if mbyte not allowed in table or col name, it is allowed
in oracle or other dbases

--> so can this be fixed soon for beta2 - this is not related to a localized
release since has nothing at all to do with localization, this is an i18n
encoding issue.

ken.frank@sun.com
Comment 8 Petr Jiricka 2006-09-18 10:20:19 UTC
Hi Ken, how important is to fix this for NetBeans 5.5? Is it a common scenario
to have multibyte table/column names in a database? Do all databases support
this, and which ones do not? How often is this used in practice? Thanks.
Comment 9 Ken Frank 2006-09-18 17:29:26 UTC
Will try to answer some of Petr's questions:

"Hi Ken, how important is to fix this for NetBeans 5.5? Is it a common scenario
to have multibyte table/column names in a database? Do all databases support
this, and which ones do not? How often is this used in practice? Thanks."


As to use of mbyte in table/column names, I think as we get a wider audience for
the fucntionality, there will be more users in other countries and thus more
that will want to use mbyte in table or column names (the topic of this bug and
other related one is column names, which I think would be more used).

That is, table and column names are often chosen to relate to the data
in them, and since we know data can and are having mbyte, and if the
dbase itself supports mbyte in table and/or column name, then nb should
also. (we see that at least oracle and javadb allow this, think that others
do but would need to look at it but that shouldn't block this issue since we
know at least these 2 db allow it and are 2 of our supt db)

Also, we didn't see problems when create entity class then adding mbyte
as variable, which will become column name in db -- so it seems that the
sort of reverese - create ent class from db (which is where problem in this
issue seen) should supprt mbyte also.

Also, for this particular issue, about the way the mbyte is shown/encoded
in List.jsp, etc - it seems that at least that part should be fixed
in any case since that is just encoding situation; and users might
separately modify the jsp files separeately to have mbyte.

ken.frank@sun.com


"
Comment 10 Petr Jiricka 2006-09-19 13:00:25 UTC
Similarly to issue 78286, since we are not aware of real world apps that use
multibyte table names today, and the fix is controversial and non-trivial, I am
requesting a waiver for this issue.
Comment 11 Petr Jiricka 2006-09-20 14:01:07 UTC
The workaround is either
- renaming database columns/tables not to use multibyte, or
- correcting the generated JSP pages

Comment 12 Petr Jiricka 2006-09-22 11:15:36 UTC
The waiver is approved.
Comment 13 martin_adamek 2007-06-20 06:39:38 UTC
Feature is dropped in 6.0


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo