http://www.google.com/gwt/n?eosr=on&q=Reflection+generics+Java+&source=m&hl=en&ei=ZWfZSODxI5nYqAKR1t53&sa=X&oi=blended&ct=res&cd=4&rd=1&u=http%3A%2F%2Ftutorials.jenkov.com%2Fjava-reflection%2Fgenerics.html
On 9/23/08, Laurie Harper <[EMAIL PROTECTED]> wrote: > Sounds reasonable until you remember two words: type erasure. There is > no way to 'glean the generic type' of a collection at runtime. > > L. > > Gabriel Belingueres wrote: >> I agree too. >> >> 2008/9/23 stanlick <[EMAIL PROTECTED]>: >>> I agree totally! If the TypeDeterminer had called getEmployees() <which >>> it >>> clearly did for iterator> *and* had bothered to glean the generic type of >>> the key, it would have recognized the action expected the key to of type >>> String. If the data type is specifically spelled out and the framework >>> decides a type diametrically opposed, this is a problem.:teeth: >>> >>> >>> >>> Gabriel Belingueres-2 wrote: >>>> 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] >>>> >>>> >>>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Custom-tag-and-map-backed-action-tp19614086p19629362.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]
