AFAIK, OGNL does not have any support for generics, but even if it would support it, I would prefer that it wont be too smart, for example in:
<s:property value="aMap[abc].id"/> I prefer that abc be treated as an action property and call method getAbc() than coerce it to the string 'abc'. 2008/9/23 <[EMAIL PROTECTED]>: > Those are all good points, but when my collection was expressly declared to > be a Map<String, Employee> I would sort of expect the key to be a String! > When the framework "guesses" for a different type (feature?) and your > application fails; all the discussion about valid number systems is sort of > meaningless. > > Scott > > On Mon, Sep 22, 2008 at 7:53 PM, Gabriel Belingueres > <[EMAIL PROTECTED]>wrote: > >> I don't know but I hope not, since I don't want my expressions to >> reduce to different data types depending if there is a number or not >> in them! >> Even if abc would reduce to the string 'abc', the expression 0xabc >> reduce to an Integer (have tested it), since it is an hexadecimal >> number. >> >> 2008/9/22 <[EMAIL PROTECTED]>: >> > I expected the conversion facility or iterator key to be smart enough to >> > recognize my Map<String, Employee> and setup the internal key variable >> > accordingly. Do you suppose it would have worked if my Map had contained >> > 'abc':emp1, 'def':emp2, 'ghi':emp3? >> > >> > Peace, >> > Scott >> > >> > On Mon, Sep 22, 2008 at 3:47 PM, Gabriel Belingueres >> > <[EMAIL PROTECTED]>wrote: >> > >> >> Interesting. Seems it is a feature, as documented in [1]. >> >> >> >> Tested it myself: >> >> <s:property value="1234h.class.name" /> >> >> <s:property value="1234b.class.name" /> >> >> <s:property value="1234F.class.name" /> >> >> <s:property value="1234L.class.name" /> >> >> <s:property value="1234d.class.name" /> >> >> <s:property value="(1234).class.name" /> >> >> >> >> The last one (Integer) didn't work without the ( ), which I don't know >> >> if this is a necessity or a bug. >> >> What about Short and Byte data type? it doesn't say... >> >> >> >> However, I think is NOT a bug that employees[1234F].id returns >> >> nothing, since the map key is a string and you need to quote it >> >> accordingly. >> >> >> >> [1] >> >> >> http://www.ognl.org/2.6.9/Documentation/html/LanguageGuide/basicExpressions.html#constants >> >> >> >> 2008/9/22 stanlick <[EMAIL PROTECTED]>: >> >> > >> >> > I encountered a very strange situation today. I had the following in >> a >> >> web >> >> > page: >> >> > >> >> > >> >> > <s:iterator value="employees"> >> >> > <s:textfield name="employees[%{key}].id .../> >> >> > >> >> > where the get method in my action was: >> >> > >> >> > public Map<String,Employee> getEmployees() >> >> > >> >> > The employee id 7932F was being interpreted as 7932! The trailing "F" >> >> was >> >> > apparently being considered a literal for FLOAT and was being trimmed >> off >> >> > the String. >> >> > >> >> > When I wrapped the variable in quotes is worked >> >> > >> >> > <s:textfield name="employees[ '%{key' }].id .../> >> >> > >> >> > Does this appear to be a bug? >> >> > >> >> > >> >> > -- >> >> > View this message in context: >> >> >> http://www.nabble.com/Custom-tag-and-map-backed-action-tp19614086p19614086.html >> >> > Sent from the Struts - User mailing list archive at Nabble.com. >> >> > >> >> > >> >> > --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> > For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
