Re: Intake, ValueParser and Localization

[Scott Eade <se...@backstagetech.com.au>]

Hello Thomas!

I'm afraid I am still head down at work and have not had time to respond 
to this.  It has also been a while since I wrote it so mi head is not 
quite in this space.

Thomas Vandahl wrote:
> Hi Scott,
>
> Scott Eade wrote:
>   
>> I am looking at how intake's DateStringField might be enhanced to
>> support localization and was looking at the work that was recently done
>> the numeric fields for clues as to how to proceed.
>>     
> Right you are. But you're opening a big box, ya know...
>   
Hello Pandora!
>   
>> Currently:
>>
>>    * Field grabs the LocalizationService and uses this to determine the
>>      locale based on the request, falling back to the default if the
>>      Field being initialized is not from a HTTP request.
>>          o For my use case this is not so good because there is no way
>>            to override the locale setting from the browser
>>          o This adds a coupling between the Intake and Localization
>>            services that we may not want in the longer term
>>     
> This was the problem I found with the Fulcrum components, too.
>
>   
>>    * DateString fields can be configured with multiple formats in
>>      intake.xml, but these need to be repeated for each DateString
>>      field and it does not cater for localization.
>>     
> I have configured four different patterns for my date fields and I know
> what you're talking about...
>
>   
>>    * ValueParser provides a getDate(name, DateFormat) variation that
>>      could potentially be used but is not.
>>     
> Actually the normal getDate() method would suffice in most cases if the
> ValueParser was locale-aware.
>
>   
>>    * It seems that ValueParser ought also to be localized and that it
>>      would be better of intake made use of this rather than
>>      implementing its own strategy
>>     
> +1
>
>   
>> Potential changes:
>>
>>    * Push the localization down into ValueParser
>>          o Provide a way of specifying the locale to be used for
>>            extracting numbers and dates from a particular parser
>>            instance.  Default locale could easily be pulled from the
>>            Request for ParameterParser and use the default otherwise,
>>            but provide for specifying an overriding locale.
>>          o Provide a means of specifying the date and time patterns to
>>            use when parsing dates and times.  There will be a
>>            dependency on the Localization service anyway, so we could
>>            pull these in from there (advantage being that they need
>>            only be specified once).
>>     
> I'm afraid I don't quite get what you mean. How would you specify a date
> or time pattern to the LocalizationService if not in the ResourceBundle?
> Do you suggest to introduce reserved keys?
>   
Yes - we could always add a level of indirection to pull the keys from 
the application configuration, but one way or another there are going to 
be some fixed keys somewhere.
>>    * Intake to make use of ValueParser for localizing numbers and dates
>>     
> Intake does not get converted numbers and dates from the ValueParser.
> That's the whole point of input validation: You would only get values
> from the parser if they were at least syntactically valid. Currently,
> Intake does not have the parser available at validation time. Do you
> suggest to change that? It would couple things even more.
>   
Would an optional callback deal with this, as per the optional use of 
LocalizationService you mention below?
>>    * We still have a bit of a mess of dependencies that have to be
>>      sorted out, particularly with the Fulcrum implementations.  Could
>>      we handle these by implementing basic behaviour in a service and
>>      then provide an extended implementation that adds the facilities
>>      that require the dependencies?  For example,
>>      ValueParser/ParameterParser could be altered to require manual
>>      specification of a Locale (falling back to the JDK for the
>>      default) and date formats, and we could provide an extended
>>      implementation adds the dependency on the Localization service to
>>      cater for the additional requirements (pulling the Locale out of
>>      the Request, as a source of the date formats).
>>     
> If we can live with a compile-time dependency, I'd suggest to ask the
> service manager if the LocalizationService exists and use it if it does.
> I did the same thing in the parser with the UploadService.
>   
Sounds like the right thing to do.
>> These are just some initial thoughts so there are bound to be plenty of
>> holes, but I am interested to hear what others think.
>>     
> My biggest concern is that certain things need to be done in a certain
> order while the request is processed. So we first need to detect which
> Locale to use before parameter parsing takes place. Only after this
> Intake can get control. Turbine 2.3 has no means for specifying when
> which part of request processing should happen and little possibilities
> to interfere at a certain point of that processing.
>   
I would need to go an have a closer look to see what might be possible 
for 2.3.  Perhaps we look at it a little more pragmatically to determine 
what we can achieve for 2.3 and push the rest over to 2.4 where the 
pipeline should help deal with such issues.
> One more thing: There is RunData.getLocale() and I could not find a case
> when this is set to a useful value nor used anywhere. Could that be a
> starting point?
>   
This could indeed be useful as it provides a place to override the 
retrieval of the locale.

We should probably resurect a Wiki page to discuss what else there is to 
do for 2.3.3 (Torque 3.3, Yaafi 1.0.5 (should release some of the other 
fulcrum components for this update), Quartz doco, deprecate Scheduler 
Service, what else?) and to initiate plans for 2.4 (as little as 
possible to get a working release out) - this could be the one to use: 
http://wiki.apache.org/turbine/Turbine2/Development/DevelopmentRoadMap

Oh for some more time to spend on this.

Scott


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org