Bugzilla – Full Text Bug Listing
| Summary: | Add support for date serialization | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Marcelo Paternostro <marcelo.paternostro> | ||||
| Component: | Sapphire | Assignee: | Konstantin Komissarchik <konstantin> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | konstantin | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Could you comment on the genesis of the list of default formats used in this serializer implementation? The goal with the list is to cover the most common formats and also the ones that can more precisely convey a date-time information. One can always argue in favor of a particular format and it may be the case to add it to the list. But we need to keep in mind that it will never be possible to cover every single case (hence the worry about providing the means to allow clients to display the supported format to users). As for using and exposing a list, it just allows the API to refer to the "first" format, which, in the supplied code, is the most precise and complete. Some people prefer arrays but I personally don't like the fact that they cannot be set as unmodifiable (one can always do ARRAY[0]=null even if ARRAY is a static final member). I understand that and prefer collections myself. My question is more regarding the method for putting together that list. Was it based on something? I'd say common sense and some user feedback. This list is very similar to the one currently used by the EMF to perform a compatible operation. If my memory servers me well, the suggested value set is a combination of the our initial guess for the EMF code and one or two newsgroup suggestions. Thanks for the clarification. Starting with the attached implementation suggestion, I improved it by allowing it to be parameterized with different formats without subclassing (which is still possible too). Added unit tests (TestModelingMisc0009) and content in the enhancement guide. Please verify. Nice modification: indeed a good use of the annotation's parameter list.
A minor observation is that I use the format list to generate a documentation that includes valid examples of strings that can be converted to date. With the changes, I have to invoke the init method so that formats return a non-null value:
DateSerializationService dateSerializationService =
new DateSerializationService();
dateSerializationService.init(null, null, new String[0]);
List<? extends DateFormat> formats = dateSerializationService.formats();
I don't think this is a problem but something that worth mentioning. In other words, I am fine marking this bug as verified, unless you think it would be a good idea to handle the scenario above. In this case, the formats() method could be implemented like this:
public List<? extends DateFormat> formats()
{
return formats != null ? formats : STANDARD_FORMATS;
}
> DateSerializationService dateSerializationService =
> new DateSerializationService();
> dateSerializationService.init(null, null, new String[0]);
> List<? extends DateFormat> formats = dateSerializationService.formats();
Rather than creating a new instance of the service, try accessing it like so:
DateSerializationService dateSerializationService = element.service( property, DateSerializationService.class );
List<? extends DateFormat> formats = dateSerializationService.formats();
The service is located, instantiated and initialized on first access. It then sticks around until the context is disposed. So you would be re-using the same instance of the service actually used for serialization.
Awesome. That will cause the documentation to reflect possible customizations via the annotation parameters. Yep. Closing. |
Created attachment 202094 [details] Suggestion for the implementation of a date serialization service Handling date is usually a non-trivial issue, and typically a solution never covers all usages. That said, providing a basic date serialization support in the framework helps in two ways: it may cover some cases (hopefully the majority) and it gives an example that people can use to create their own implementations. The attached class is an implementation suggestion. The idea is to rely on a fixed number of valid formats to convert a string to a java.util.Date object. The code was written to allow subclasses to provide new supported formats. The reverse operation, from date to string, uses the first supported format by default (it can also be modified on subclasses). If the suggested implementation is used, I'd recommend keeping the get*Format methods public to enable clients to write code that, for example, displays a text with example of supported date strings.