I'd welcome some kind of current context similar to
ActionBeanContext in TypeConverters. At this point I have one
converter that needs an access to session and/or request stuff. Its
not really important yet, but is possible "requirement" in the
future. We had an idea of ThreadLocal as well, but decided clunky
solution wasn't worth the effort.
Sincerely,
Daniil
On 3/21/2011 10:08 AM, VANKEISBELCK Remi wrote:
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
|
<<attachment: daniil.vcf>>
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users