Menu
▾
▴
Re: [Stripes-users] Antwort: Re: Dynamic configuration of DefaultTypeConverterFactory ?
|
From: Tim F. <tf...@tf...> - 2006-09-29 14:32:22
|
Hey Guys,
Firstly, I'm glad you got things working using the converter=3Dclass =20
stuff.
There is a reason why Stripes doesn't scan for type converters - =20
though maybe an optional scanning implementation wouldn't be so bad. =20=
The main reason is that you can have many converters in your =20
classpath for the same type, and then what should Stripes do? For =20
example, what if you don't like the Stripes type converter and =20
instead create your own (or two, or three) classes that implement =20
TypeConverter<Date>? I'm sure we could come up with a set of rules =20
governing what to use when, but it'd be pretty messy. I'm not saying =20=
it couldn't be made to work, but I worry it could cause as much =20
confusion as anything else.
-t
On Sep 29, 2006, at 10:09 AM, seb...@gf... wrote:
> Hi Ben,
>
> well you're right. The @Validation(converter=3DCLASS) annotation works
> create.
>
> I had the following class model.
>
> public class ComplexDateFormat {
> private Locale locale;
> private String pattern;
> private Timezone timezone;
> // getter&setter go here
>
> // computes the current date format in string representation =20
> using
> // the local, pattern and timezone settings
> // the implementation can handle even unset (null) values using
> internal defaults.
> public String getDateString() {
> // ....
> }
> }
>
> public class DateActionBean implements ActionBean {
> // setting application context
>
> @Validate(required=3Dtrue)
> @ValidateNestedProperties(
> {
> @Validate=20
> (field=3D"timezone",required=3Dfalse,converter=3DTimezoneTypeConverter.c=
lass
> }
> )
> private ComplexDateFormat format;
>
> public ComplexDateFormat getFormat() { return( format ); }
> public void setFormat( ComplexDateFormat cdf ) { this.format =20
> =3D cdf; }
>
> public String getDate() {
> return( this.format.getDateString() );
> }
> }
>
> Everything worked fine in that case. What i'm in doubt about is that
> complexity is really necessary ?
> Even as the ActionBean doesn't really have to know about the timezone
> property in the domain object i have
> to declare a proper TypeConverter here. Well, the solution would be =20=
> to use
> a custom TypeConverterFactory.
> That way stripes would convert the timezone property corrently on =20
> URLs like
> /Date.action?format.timezone=3DUTC
> without the @ValidateNestedProperties annotation.
>
> And here's where my suggestion comes into it. Think about the =20
> following
> situation.
>
> Team A is reponsible for developing backend stuff. So to say they =20
> developed
> the ComlexDateFormat class and provided it with a library.
> Team B is developing the actual web application using stripes =20
> framework.
> To prevent that Team B has to implement a property =20
> TypeConverterFactory for
> the used TimeZone property booth teams aggreed, that
> Team A provides all TypeConverters for custom objects which might =20
> be used
> within the application. (huuu...i know, it's really a weird and far =20=
> out
> example ;))
>
> Anyway...what Team B is at nevertheless required to do is to =20
> implementa a
> property CustomTypeConverterFactory and configure it withing the
> StripesFilter.
> Although i know that isn't really a hard thing to do, it's =20
> unncecessary in
> my point of view.
>
> I never had a closer look into stripes internal implemenation. Hey, no
> needs so far :)) But i think when the Framework is initialized also =20=
> the
> configured
> TypeConverterFactory gets initiated and initalised. Wouldn't it be =20
> nice to
> have a: well, let's say 'AutoConfTypeConverterFactory' ?
>
> This AutoConfTypeConverterFactory scans the classpath (just like =20
> stripes
> does with ActionBeans) for TypeConverter implementations and =20
> registers them
> automatically.
>
> To get back to the scenario above, that way Team B could just throw =20=
> the
> library from Team A into the classpath and the URL
> '/Date.action?format.timezone=3DEST' would
> worlk 'out-of-the-box' :)
>
> Hope things get clearer now and hey...thanks for the fast response
>
> -Sebastian
>
>
>
>
> Ben Gunter
> <bg...@cp...
> =20
> m> An
> Gesendet von: Stripes Users List
> stripes-users-bou <stripes-=20
> us...@li...urceforge.n
> nc...@li...urce et>
> =20
> forge.net Kopie
>
> T=20=
> hema
> 29.09.2006 15:27 Re: [Stripes-users] Dynamic
> configuration of
> DefaultTypeConverterFactory ?
> Bitte antworten
> an
> Stripes Users
> List
> <stripes-users@li
> sts.sourceforge.n
> et>
>
>
>
>
>
>
> I'm using type converters in one of my projects, and I've never had to
> set a parameter on the Stripes filter or implement a
> TypeConverterFactory. All I do is:
>
> public class MyActionBean extends BaseActionBean {
> @Validate(required =3D true, converter =3D MyConverter.class)
> public MyType someProperty;
> // ... more stuff ...
> }
>
> Where MyConverter implements TypeConverter<MyType>. Works like magic.
> Maybe I didn't understand what you were saying.
>
> -Ben
>
> seb...@gf... wrote:
>> Hi all,
>>
>> i would like to hear your optinions about the following idea.
>> While studying the online docs of stripes i started playing around =20=
>> with
> the
>> TypeConverter facilities. What i couldn't really understand
>> is why i had to 'reconfigure' the StripesFilter with my own
> implementation
>> of the TypeConverterFactory which just adds class-2-converter =20
>> mappings.
>>
>> So what about @Validate(class=3D"org.test.MyConverter") ? Wouldn't =20=
>> it be
>> enough to define this annotation on my ActionBeans properties ?
>> If so, are there other requirements (except the already provided =20
>> default
>> convertes like DateTypeConverter or EmailTypeConverter) for the =20
>> converter
>> mappings factory ?
>>
>> Well nevertheless, a simple solution getting rid of the extra
>> implementation of the TypeConverterFactory and the additional
> configuration
>> step on StripesFilter
>> would be maybe the following:
>>
>> As each TypeConverter implementes the same interface wouldn't it be
>> possible to automatically configure the stripes framework with all
>> TypeConverters found in the classpath following the same mechanism =20=
>> as the
>> NameBasedActionResolver does with ActionBean implementations ?
>>
>> As i'm not really fimilar with the internal java 5
> introspection/reflection
>> capabilities i'm not sure if it would be easily possibly to =20
>> autmatically
>> detect the
>> target type for the convert using the GenericDeclaration. If this =20
>> is not
>> possible, how about to create a new class-level annotation like
>> @TypeConverter(targetClass) ?
>>
>>
>> Hope my english's not too bad, and you understand what i was =20
>> trying to
> say
>> :)
>> So hopefully i will get some suggestions
>>
>> bye
>> Sebastian
>>
>> _________________________
>>
>> Diese E-Mail (ggf. nebst Anhang) enth=E4lt vertrauliche und/oder =20
>> rechtlich
>> gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat =20
>> sind, oder
>> diese E-Mail irrt=FCmlich erhalten haben, informieren Sie bitte =20
>> sofort den
>> Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren =20
>> sowie die
>> unbefugte Weitergabe dieser Mail ist nicht gestattet.
>>
>> This e-mail (and any attachment/s) contains confidential and/or
> privileged
>> information. If you are not the intended recipient (or have =20
>> received this
>> e-mail in error) please notify the sender immediately and destroy =20
>> this
>> e-mail. Any unauthorised copying, disclosure or distribution of the
>> material in this e-mail is strictly forbidden.
>> _________________________
>>
>>
>> ---------------------------------------------------------------------=20=
>> ----
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to =20
>> share
> your
>> opinions on IT & business topics through brief surveys -- and earn =20=
>> cash
>> http://www.techsay.com/default.php?=20
>> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
>> _______________________________________________
>> Stripes-users mailing list
>> Str...@li...
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>
> ----------------------------------------------------------------------=20=
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =20
> share
> your
> opinions on IT & business topics through brief surveys -- and earn =20
> cash
> http://www.techsay.com/default.php?=20
> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
> _______________________________________________
> Stripes-users mailing list
> Str...@li...
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
>
> ----------------------------------------------------------------------=20=
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =20
> share your
> opinions on IT & business topics through brief surveys -- and earn =20
> cash
> http://www.techsay.com/default.php?=20
> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
> _______________________________________________
> Stripes-users mailing list
> Str...@li...
> https://lists.sourceforge.net/lists/listinfo/stripes-users
|