wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Grigorov <mgrigo...@apache.org>
Subject Re: Using Wicket to generate E-Mails.
Date Tue, 12 Mar 2019 14:18:17 GMT
Hi,

There is an example how to do this in wicket-examples:
- http://examples8x.wicket.apache.org/mailtemplate/
-
https://github.com/apache/wicket/tree/master/wicket-examples/src/main/java/org/apache/wicket/examples/asemail

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

> 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.Schoening@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message