RSF Discussions Forum

Hi,

I want to use IKAT to render a String to be sent by email. This is within an RSF webapp, but would have to work independently of all the request handling.

The 'Disintegrations' page on the wiki indicates that this should be possible, so where do I start?

Rob

Hi there - I have been meaning to "work this up" into something more formal, but it will be difficult until we rationalise our handling of Spring contexts as part of the 0.8 work. In particular since the current idiom of RSF is to take over the entire Spring application context, it is hard to "make space" for alternative bean configurations.

An example of doing exactly what you are describing can be found in the now somewhat "cast off" FlowTalk project (which was however responsible for the development of RSF in the first place). The code is in

https://saffron.caret.cam.ac.uk/svn/projects/FlowTalkServlet/trunk/src/java/uk/ac/cam/caret/flowtalk/rsf/mail/DefaultOutgoingMailRenderer.java

and in particular the manual steps in the "renderTextBody" of setting up the bean environment for ViewRender will be what you need. All this would be better expressed in Spring of course, but would require the use of some autonomous "mini-context". You can consult your taste

As a general caveat, this particular code has not been maintained in about 10 months, so there may well be some drift in the expectations of modern "ViewRender" that are not reflected here - but the core steps here should be enough to get you going, as well as the useful utility of the "XMLFlattener". Do post back sooner rather than later if you run into some oddity or missing dependency - cheers.

Thanks for this - very helpful.

At the moment my code is trying to use a layout template, which I don't want it to.

I expect this has something to do with setting templateResolver to viewTemplateResolver. Should I construct a separate TemplateResolver instance instead?

Rob

Ok yes, inappropriate layout templates was something we hit in the AJAX context, and this was resolved by using a ViewGroup.

This is the standard definition from RSF

Code:

   <bean id="layoutProducerParent" class="uk.org.ponder.rsf.view.LayoutProducerHolder" 
      abstract="true">
      <property name="viewGroupName" value="HTMLViewGroup" />
   </bean>

if you adjust the viewGroupName to your own group, and set it to a predicate to exclude the email view name, you should be laughing.

At least, chuckling moderately, the test cases for the ViewGroup code will be forthcoming in this new release

Sobbing quietly to myself...

It seems I'm fighting my own TemplateResolverStrategy from http://ponder.org.uk/rsf/posts/list/210.page

The 'consumertype' it's picking up is probably determined by RSF for the request, not my invocation of TemplateResolver.locateTemplate.

Is there a quick-ish way of wiring up a separate TemplateResolver, or is it just too tightly meshed with the request decoding?

Hmm... well that's odd. I guess I'm not quite sure what you put into your TRS, since on the face of it I can't quite see how it might be interfering with the LayoutProducerHolder/LayoutCollector relationship. The idea would be that you would define the ViewGroup based on view id, and not on content type, and I'm not quite sure how the consumer type comes into this

I guess you'll have to paste your TR to see what you did.

A TRS is fairly easy to knock up as you saw, but replacing the entire TR would be much more daunting. I refactored it recently for some 0.7.3 work but it is still pretty meaty and something I would balk at implementing another one of

It's part of a scheme to achieve separate layout producers and outer templates per ViewGroup. The TRS selects the appropriate layout template based on consumerInfo (as I understood your suggestion) - which is overridden to set consumertype to a value inferred from viewParameters and viewGroupResolver.

Time is a bit short, so I'll find another way to format emails for now.

Thanks for your help though.

Rob

OK.... it sounds like this might have been resolvable by just assigning your email template view to its own ViewGroup, but indeed there are other ways of rewriting emails

Cheers,
A.

I just ran into a use case where this was very helpful... so thanks for this info....

We had a fun use case where we had to create PDFs from scratch. So instead of using iText, I took advantage of PD4ML which takes rendered HTML and translates it (with CSS) into a nice PDF. This was much quicker for me to put together since I am comfortable with HTML so well.

Anyway, I needed a way to get rendered HTML without spawning a bunch of different request cycles (I wanted to do it in the same request for efficiency reasons).... so I used the above example of the rendered email to return the HTML as a string, then fed that straight into PD4ML....

There's probably 10 reasons why this was the worst idea ever, but it was quick and worked very well! ;-)