Hi folks,
I'd even go further : make EVERYTHING request-scoped. Not only
TypeConverters, but also ActionBean resolution and Validation.
If you look at the current ActionBeanResolver, it's all "static". One should
be able to write dynamic resolvers if he wants to. The whole path thing in
ActionResolver makes it very clumsy at the moment. Same goes for
ValidationMetadataProvider.
After all, everything that occurs in Stripes should occur when serving a
request, therefore the request (or action bean conctext) should be available
everywhere.
Cheers
Remi - ThreadLocal-based RequestInterceptor is what I'm doing for now, but
clearly, it sucks.
2011/3/20 Will Hartung <redro...@sbcglobal.net>
> TimeZones!
>
> TimeZones suck!
>
> Working on a project that's deployed on GAE.
>
> GAE only works on UTC. That's the default TimeZone, and everything done
> within the running image is done at UTC.
>
> Specifically, Date parsing and display default to UTC.
>
> This is not so good when you're doing a local app, in my case PST/PDT.
>
> I chatted with the gang on IRC about ways around this and how to work with
> it. Through various attempts I settled on using a custom TypeConverter and
> Formatter for dates hard code to my time zone. (I'll pause while Ben mops up
> whatever beverage he has just spewed over his expensive computer equipment
> and his antique mahogany desk overlooking the tranquil rustic harbor from
> his hillside, panoramic window).
>
> The change was simple, but it brought up other issues.
>
> Basically, this technique works great, if you're limited to a single time
> zone. But not so much if you want a flexible time zone (like say a user
> setting).
>
> The problem centers around the fact that the TypeConverters and Formatters
> have no context whatsoever. They have no access to the StripesContext or the
> Session or anything else.
>
> The <s:text > tag also has no way to specify a time zone, and the
> Formatters have no way to have a TZ passed to them even if we added a
> parameter to s:text. Also, the TZ on s:text would only affect rendering, not
> parsing, so it's inelegant at best anyway.
>
> So, simply, I'd like to suggest in Stripes 2.0 that the formatters and type
> converters be given some kind of access to the current request. Then they
> can leverage the Session or some other piece of information tied to the
> request itself.
>
> We can hack around this currently with something like a ThreadLocal, but
> that's something I think is kind of distasteful.
>
> I suggest it for S2.0 simply because I don't think it could be done without
> breaking all of the current TCs and Formatters, and that shouldn't be done
> in a 1.x release. A touch rude.
>
> We could maintain the "old" TCs and Formatters and create an "extended" TC
> and Formatter and dispatch internally, but that's kind of nasty in a "these
> have been deprecated forever why are they still here" kind of way. But
> that's a different discussion.
>
> I guess we could instead add a "WantsContext" interface and if we see that,
> then call a setContext method on the TC/Formatter. That way new TCs can
> broadcast that they want it, and old TCs work just peachy. Perhaps that's
> not so nasty bad that we could do that right now (I haven't looked at how
> much of the StripesContext is available at this phase of the processing, I'm
> just blindly assuming it's handy).
>
> Anyway, fuel for the fire.
>
> Share and Enjoy!
>
> Regards,
>
> Will Hartung
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
