Bug 95738 - I18N - unable to enter JA data in IEP editor
I18N - unable to enter JA data in IEP editor
Status: RESOLVED FIXED
Product: soa
Classification: Unclassified
Component: IEP editor
6.x
PC Windows XP
: P2 (vote)
: 6.x
Assigned To: Ritesh Adval
issues@soa
: I18N
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-15 20:16 UTC by gmurr
Modified: 2008-10-07 01:35 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description gmurr 2007-02-15 20:16:35 UTC
In an IEP project,
drag stream Input into the palette window.
double click on the  stream Input icon.
You can not input any JA data into any of the text fields.
my OS is windows xp running in JA locale
Comment 1 Ken Frank 2007-02-15 20:25:34 UTC
George,

does this happen when using im tools for entering mbyte or with copy/paste also ?

could you attach gif of the window if convenient ?


ken.frank@sun.com
Comment 2 gmurr 2007-02-15 20:34:03 UTC
It happens for both input and copy/paste.
Attaching a gif does not help because when I do the input, nothing shows up in
the text field.
Comment 3 Ken Frank 2007-02-15 21:38:31 UTC
true for any iep component properties editor - can't input multibyte at all.

ken.frank@sun.com
Comment 4 Ken Frank 2007-02-15 21:45:36 UTC
was able to input mbyte into the comment section of relationship aggregator,
but not the attribute name or some other parts.

actually there are various prop editors of iep components
where even ascii cannot be input or focused to add input

ken.frank@sun.com
Comment 5 Yanbing Lu 2007-02-16 18:24:48 UTC
Operator names in IEP are like method names in Java, and 
attribute names in IEP are like variable names in Java. 
It has to start with any thing in the set {_, a through z, A through Z},
and followed by any thing in the set {_, a through z, A through Z, 0 through 9}
The editor only considers these as valid inputs.

We may change this in the future by extending the IEP language.
Comment 6 Ken Frank 2007-02-16 18:32:28 UTC
method and variable names in java can have multibyte, 
thus I don't think this is a valid restriction if indeed what is legal
in java is what is legal in iep editor.

but if it needs to be restricted, can there be some clue or error
msg - since in this case, the user is doing the usual way of typing
multibyte but sees nothing happening and that is confusing.

ken.frank@sun.com
Comment 7 gmurr 2007-02-16 22:16:31 UTC
In the stream Input editor you should be able to enter multibyte for database
column names. The database does allow multibyte data for column names.
Comment 8 Alexei Mokeev 2007-02-19 07:10:57 UTC
There was an objection from Ken. Waiting for resolution.
Comment 9 Alexei Mokeev 2007-02-20 07:35:09 UTC
Not a stopper accoriding to Ken. However migh be visible for users:
"I was just clarifying that some i18n things, like these bugs, would be visible
to users of the en beta, who run in other locales"
  
Comment 10 Alexei Mokeev 2007-03-05 17:23:55 UTC
Removed Beta EP551_WAIVER_APPROVED keyword - we are going forward to FCS.
Comment 11 Ken Frank 2007-03-28 15:44:09 UTC
To dev team - can you confirm that this will be fixed in hula ?
Its not related to translations at all, since can impact any user who runs in
other locale and who might use characters of that locale, and use of such
characters is legal in java.

ken.frank@sun.com
Comment 12 Yanbing Lu 2007-07-03 00:45:59 UTC
It was a bad analogy to method names and variable names in Java.
The operator names and attribute names are used to generate 
event processors in CQL language. The CQL engine can only
process operator names and attribute names that are composed
of _, letters, and digits. We will enhance the engine to 
allow more characters in the future.
Comment 13 Ken Frank 2007-07-03 02:16:29 UTC
Thanks for clarifying about the QL - 

as per previous comments, I do think a warning or other information
should be provided to the user about this - if they use their normal
ways of input of extended ascii, multibyte or other non ascii chars,
and it just does not work, it will be confusing to them

since this is an editor, it seems it can be a bit more challenging
as to where to place the warning and how, vs for a single dialog, wizard or property.

Also, please add to even beta1 release notes, since this is not related to
translations at all.

But on the topic of translations - will translated messages/labels in this editor
be able to be shown ?

ken.frank@sun.com
Comment 14 Yanbing Lu 2007-07-03 17:49:18 UTC
Translated messages/labels in this editor will
be able to show.
Comment 15 Ken Frank 2007-07-04 02:42:10 UTC
Blu,

IMO this is not an enhancement; its an issue that needs to be fixed via giving a warning or some
other way vs user seeing that the usual way they input non ascii appears to be broken.

that is, the way multibyte (and other non ascii) is entered is a standard way, and doing it that
way in iep props editor it does not work and will be confusing to them; since the props editor
looks like any other props editor in ide. 

Thus I understand that the fix should not be to allow such input, but to warn the user
they can't do it;  and hopefully block such input rather than allowing it since when
its allowed, it looks partially broken, for example for ja on solaris, I see the candidate characters
but they are not shown.


Also, are there any props of iep pallette items where non ascii is allowed as values ?

Am changing back to defect.

kenf.frank@sun.com
Comment 16 Ken Frank 2008-01-15 20:55:15 UTC
seems like iep project is back in nb6.1/sierra
and thus if editor is also, this needs to be fixed
for nb6.1


can dev team comment about it ?

also, can other i18n things about iep project, file types,
editors, etc be done if not already - if you file separate
issues or tasks can you add kfrank and kaa to interest list ?

ken.frank@sun.com
Comment 17 Sergey Lunegov 2008-01-18 10:57:38 UTC
IEP will not be part of NB 6.1 FCS I believe.
Comment 18 Ken Frank 2008-01-18 16:34:24 UTC
Sergey,

just to reconfirm, the iep project, file type, editor, etc that is seen now in
nb6.1 builds, which I am assuming now has all sierra functionality that was
in separate builds - all this functionality will noto be in 6.1 fcs ?

if so, could it be removed soon ?
(let me know if 6.1 trunk builds are not the place where sierra functionality is)

ken.frank@sun.com
Comment 19 Sergey Lunegov 2008-01-21 10:09:54 UTC
Ken, I confirm that IEP will not be in 6.1 fcs. Ritesh, would you please work with NB Release Engineering to exclude IEP
modules from NB 6.1 build.
Comment 20 Ritesh Adval 2008-10-06 23:17:46 UTC
started
Comment 21 Ritesh Adval 2008-10-07 01:35:08 UTC
Fixed, Two changes are done:

(1) Now whenever an invalid name is entered, user is shown a popup tooltip like message about
invalid character.

(2) Added a system property iep.editor.validateNamesInTextField (by default the value is true), this can be set for 
example in netbeans.conf
ex: -J-Diep.editor.validateNamesInTextField=false

if this property is set to false as shown above then we by pass the name validation and allow user to enter
whatever name they want. This could fail in runtime if user enters invalid names which make some iep database
sql invalid, but at least we have a way to allow user to enter what they want and they should make sure
names are valid so that sql is valid.


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