MVEL has a pluggable type-conversion API, just like OGNL. Since it's
source-from-many in it's design, you can easily design converters that
perform as much introspection as necessary to determine formatting, etc.
Brian Pontarelli wrote:
>
> Yeah. That's good. The last thing I would toss in as criteria is a
> good type conversion interface. In JCatapult, I actually took things a
> step further. I found that complex types usually needed more
> information than just the data to perform the type conversion. For
> example, conversion of dates generally requires the date format.
> Likewise, conversion to money generally requires the currency code. In
> many MVCs this information is statically configured for the entire
> application, configured per action in XML or properties files or fixed
> and not configurable at all.
>
> For maximum flexibility, I built a system where tags could provide
> this additional data via extra attributes (it can also be configured
> application wide as well). My tags look like this:
>
> [EMAIL PROTECTED] name="user.lifeSavings" currencyCode="USD"/]
> [EMAIL PROTECTED] name="user.birthDay" dateTimeFormat="MM/dd/yyyy"/]
>
> This information then gets passed to the type converters as part of
> the API.
>
> This then reveals another shortcoming of OGNL and the wrapper in
> Struts, what if a required attribute is missing? This is a different
> case then if the type conversion fails. So, I created two distinct
> checked exceptions to handle these two cases. This makes the type
> conversion system more powerful and easy to interact with. Plus, it
> reveals good exceptions for coding problems.
>
> -bp
>
> On Oct 10, 2008, at 3:00 AM, Chris Brock wrote:
>
>>
>> MVEL will handle type coercion for method parameters, properties,
>> and even on
>> egress of those values if the generic type information can be
>> deduced on
>> ingress. In situtations where the generic type is dependent on the
>> root of
>> the object graph though, MVEL cannot infer generic type data (ie. a
>> bound
>> variable, that's say a Map) because of erasure. There is no generic
>> type
>> information held on a per-instance basis.
>>
>> However, if the parameterized type is a class member say:
>>
>> class Foo {
>> public Map<String, Integer> map;
>> }
>>
>> And you use an instance of Foo as a context or as a bound variable,
>> MVEL's
>> compiler can certainly extract the generic type information, and
>> provide
>> automatic coercion and verification accordingly. MVEL's type
>> verifier will
>> always extrapolate whatever type data is available.
>>
>>
>>
>> Brian Pontarelli wrote:
>>>
>>> This is not quite the same unless it can detect generics while
>>> setting
>>> values and creating values. An example might be values from a form
>>> going into something like:
>>>
>>> List<String>
>>>
>>> or
>>>
>>> Map<String, List<Integer>>
>>>
>>> or the always fun
>>>
>>> List<List<Integer>>
>>>
>>> that sorta thing. I know that OGNL had (might not any longer) many
>>> issues with generics in this respect. I think OGNL also got mad when
>>> it encountered something simple like:
>>>
>>> int[]
>>>
>>> or
>>>
>>> String[]
>>>
>>> coming from checkbox lists and multiple selects. I believe that it
>>> would stuff the values into the String[] like this:
>>>
>>> {"value1,value2,value3"}
>>>
>>> rather than
>>>
>>> {"value1", "value2", "value3"}
>>>
>>> This was a while ago, so all of this might be fixed.
>>>
>>> -bp
>>>
>>>
>>> On Oct 9, 2008, at 7:32 PM, Chris Brock wrote:
>>>
>>>>
>>>> MVEL 2.0 has full support for generics (and static typing):
>>>> http://mvel.codehaus.org/Strong+Typing+Mode
>>>>
>>>>
>>>> Brian Pontarelli wrote:
>>>>>
>>>>>
>>>>> On Oct 7, 2008, at 3:08 PM, Dave Newton wrote:
>>>>>
>>>>>> Just to muddy the EL/templating waters:
>>>>>>
>>>>>> http://mvel.codehaus.org/Performance+of+MVEL
>>>>>>
>>>>>> (v. OGNL)
>>>>>
>>>>> Not sure about MVEL or OGNL at this point, but everything was
>>>>> lacking
>>>>> in support for generics, collections and arrays. I wrote my own for
>>>>> the JCatapult MVC and it was really not all that hard. It only
>>>>> handles
>>>>> getting and setting, but I figure that's all that should be allowed
>>>>> at
>>>>> that point anyways.
>>>>>
>>>>> -bp
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>
>>>>>
>>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/MVEL--tp19867360p19910418.html
>>>> Sent from the Struts - Dev 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]
>>>
>>>
>>>
>> --
>> View this message in context:
>> http://www.nabble.com/MVEL--tp19867360p19914597.html
>> Sent from the Struts - Dev 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]
>
>
>
--
View this message in context:
http://www.nabble.com/MVEL--tp19867360p19935345.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
