james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <robertburrelldon...@gmail.com>
Subject Re: New Templating Module [WAS Re: New Modules]
Date Sun, 19 Apr 2009 14:04:40 GMT
On Sat, Apr 18, 2009 at 8:02 PM, Markus Wiederkehr
<markus.wiederkehr@gmail.com> wrote:
> On Thu, Apr 16, 2009 at 7:36 PM, Robert Burrell Donkin
> <robertburrelldonkin@gmail.com> wrote:
>> On Sun, Apr 12, 2009 at 12:58 PM, Markus Wiederkehr
>> <markus.wiederkehr@gmail.com> wrote:
>>> On Thu, Apr 9, 2009 at 7:26 PM, Robert Burrell Donkin
>>> <robertburrelldonkin@gmail.com> wrote:
>>>> i plan to take a look at
>>>> https://issues.apache.org/jira/browse/MIME4J-120 (adding a templating
>>>> module)
>>> Okay.. I guess if you want to e.g. create an Atom from a message you
>>> are interested in the message's header fields like subject, sender and
>>> recipient and maybe only a preview of the content, right?
>> sounds like a typical use case
>>>> i'd also like to add modules to support parsing into stores other than
>>>> file, in particular JCR and OpenJPA. the initial use case would be
>>>> upstream in server and imap but my hope is that they might develop
>>>> into standard representations.
>>> Implementing a StorageProvider that uses JPA should not be a problem.
>>> But please note that at the moment only the message's text and binary
>>> parts are written to storage. The header fields are kept in memory.
>> <snip>
>>>> i'm being intentionally vague
>>>> so that everyone has a chance to comment before i start creating JIRAs
>>>> etc.
>>> Like I said I guess you are interested in the header fields and herein
>>> lies the problem. For example in case of the subject field you are
>>> probably interested in the decoded subject and not the raw encoded
>>> words. Same for sender and recipient addresses. So it wouldn't do to
>>> fill the Velocity context with raw header fields. The header fields
>>> would already have to be understood and parsed.
>>> And do you really need a separate storage for that? Wouldn't it be
>>> sufficient to write a ContentHandler that parses the header fields and
>>> reads only a few lines of the actual content and then create a
>>> Velocity context from those parsed objects. I guess it wouldn't even
>>> be necessary to recurse into inner parts of the message.
>> apologies for the confusion - the templating module is an independent
>> idea. i'll start another thread for that.
> So a templating module could be written without modifying the existing
> code base? As a separate module or even a separate project?

it's quite possible that - as a new use case - some improvements to
the DOM may well emerge as part of the process but the templating
would just be an extension module

- robert

View raw message