On Sat, Jan 10, 2009 at 10:14 AM, Markus Wiederkehr
<markus.wiederk...@gmail.com> wrote:
> I suggest we add a high-level factory for header fields. I would like
> to simply call it Fields. Here is an outline that illustrates the
> design for the Date field:
>
> public class Fields {
>
> public static DateTimeField date(String fieldValue) {
> return date("Date", fieldValue);
> }
>
> public static DateTimeField date(String fieldName, String fieldValue) {
> return (DateTimeField) Field.parse(fieldName + ": " + fieldValue);
> }
>
> public static DateTimeField date(String fieldName, Date date,
> TimeZone zone) {
> DateFormat df = RFC822_DATE_FORMAT.get();
> if (zone != null) {
> df.setTimeZone(zone);
> }
> return date(fieldName, df.format(date));
> }
> ....
> }
>
> Obviously that class would need to have a lot of methods for the
> various header fields.
+1
may be worthwhile considering whether a stateless POJO would be better
in this case. class methods tend to be more difficult to use with
reflection but their public API is more obvious and concise. (i lean
towards using static methods in this case as proposed.)
> It should also be possible to automatically use encoded words when
> creating a Subject field, for example. This could help with MIME4J-69.
+1
> In Message I would also like to add convenience methods that use the
> Fields factory. Again an outline for the Date field:
>
> public class Message extends Entity implements Body {
> ...
> public Date getDate() {
> Header header = getHeader();
> if (header == null)
> return null;
>
> DateTimeField dateField = (DateTimeField) header.getField("Date");
> if (dateField == null)
> return null;
>
> return dateField.getDate();
> }
>
> public void setDate(Date date) {
> setDate(date, null);
> }
>
> public void setDate(Date date, TimeZone zone) {
> Header header = getOrCreateHeader();
>
> if (date == null) {
> header.removeFields("Date");
> } else {
> header.setField(Fields.date("Date", date, zone));
> }
> }
> ....
> }
+1
> Any objections?
not from me :-)
i'm not a big fan of Date (i much prefer JODA) but i think this use is
reasonable and leads to a more obvious and compact API.
i find for protocol work, using a specialist framework is necessary to
prevent errors creeping in for some locales. i also find that the
java.util.Date parsing stuff often tends to be slow. so, i think we
should consider avoiding the use of java.util.Date but i think this
issue would best be left till a later release. i'll raise a JIRA.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
