There is an example how to do this in wicket-examples:
- http://examples8x.wicket.apache.org/mailtemplate/

On Tue, Mar 12, 2019 at 4:05 PM Thorsten Schöning <tschoen...@am-soft.de>

> Hi all,
> I'm using Wicket for some frontend of some web app and pretty much
> like it because it allows me to clearly separate skins, language
> files, templates and to not mix too much view and business logic. My
> current requirements are to send mails in some web service backend and
> I want to use some template engine to generate those, because I need
> to support multiple languages, might need to create somewhat complex
> content like tables, headlines and stuff. Not only using HTML, but
> using plain text as well.
> I've already searched around that topic focussing on Wicket and found
> some explanations that this in fact is doable, but those references
> are pretty old already. The following are some examples:
> http://wicket-praxis.de/blog/2009/12/01/sending-html-email-from-wicket-app/
> https://cwiki.apache.org/confluence/display/WICKET/Use+wicket+as+template+engine
> Are there any newer docs available covering that topic I have missed?
> What I'm especially interested in is how to avoid the HTTP-stuff, what
> the entry points are if I want to render to some string only and what
> the best approach is to provide necessary data like different language
> settings, as the corresponding HTTP-headers are missing.
> Another focus is on generating plain text. I know Wicket is based on
> HTML/XML-templates, but components can be rendered "body only" already
> as well. I had something in mind like reusing the templates for
> HTML-mails by not rendering them entirely including nodes, but only
> node content itself specially.
> Something like "<h1>...</h1>" would simply be rendered as some line of
> text with an empty line afterwards. Same for e.g. "p", while "pre"
> might simply be indented, "cite" might get a leadin ">" per line etc.
> So in the best case, I would maintain one set of templates mostly and
> two different rendering approaches to switch between.
> Any hints on how I need to implement those different rendering
> approaches for the same components? So that I don't need to deal with
> that for each and every component, but some visitor-rendering-pattern
> or such.
> Does anyone already have experience with such an approach and
> additonal advises? Is it a totally bad idea for some reason?
> Thanks for your input!
> Mit freundlichen Grüßen,
> Thorsten Schöning
> --
> Thorsten Schöning       E-Mail: thorsten.schoen...@am-soft.de
> AM-SoFT IT-Systeme      http://www.AM-SoFT.de/
> Telefon...........05151-  9468- 55
> Fax...............05151-  9468- 88
> Mobil..............0178-8 9468- 04
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to