Custom fields and an XML alter hook

This one has been on my mind; here's the model I've come up with.

Each view can have multiple displays (when editing a view with the Views UI, they appear as tabs on the left side). Some displays include one or more fields. We can take advantage of this in two steps.

1. SunMailer can select a certain display for a view (right now it just takes the default display).
2. Any fields made available by that display will be exposed in the XML.

After this is done, the person using the module will have to modify the XSL files to consume the new data exposed in the XML file (there is documentation for that if you install Advanced help).

Oh, this is what I was thinking of adding for SunMailer 1.2, not what it currently supports.

Since SunMailer uses views, you should be able to sort (and maybe group) content by modifying the view. For example, The Cornell Daily Sun assigns weights to individual stories. The view for each section (news, sports, etc...) then sorts by this weight. This controls the order of content in SunMailer, as well as the front page, section pages, and anything else which leverages this view.

I am also having the exact same requirement - of needing to add custom fields in my newsletter.

I have created a view which shows exactly the content that I would like to get mailed out in a newsletter using the SunMailer. But what the SunMailer mails out is somewhat different.

In my view I have the 'node' title with link and two other custom fields. But in the newsletter what is shown is the node title along with the teaser. I don't want the teaser to be mailed out. Also, I would like to custom fields to be part of the newsletter.

Is there a way that I can edit the xml or xsl files to make this work? I know the token names of the custom fields that I would like to include in the newsletter.

Would appreciate any help!

Not in version 1.1. I've been looking at the Views documentation today to get a sense of how to do this in the next release. I'll try to knock out a lot of the problems sets for my classes tomorrow so I can plow full speed ahead on this issue.

As I'm envisioning it right now for 1.2, the XML will contain the rendered values for all the fields the view contains (and the tags will likely be the token names); you will not need to do any work to make this happen. What you will need to do, however, is create a new XSL file to leverage the new XML tags. This can already be done in version 1.1, and there's documentation for it if you install the Advanced help module.

Thanks for your prompt reply! If I understand correctly, what you written here is that using custom fields can be done in ver 1.1 by creating a new XSL file and the documentation for this is in the Advanced Help, Is that correct?

I have installed Advanced Help and went through the SunMailer documentation- but couldn't find any info on how to create a new XSL file to leverage the new XML tags. If there is a way to do this in version 1.1 I would love to try it out.

Custom fields can't be done in version 1.1. Just a custom XSL file. You can customize the display, but you're still limited in what data can be displayed in the first place. Which is what I'm looking to fix in the next release.

Thanks for the clarifications! I just read your other post where you said the next release might be code complete this weekend.

I'd be happy to be one of the first few users to test the new release for you. If you can let me know on email when its out - my email address is rsutaria@gmail.com.

Btw, the view that I'm trying to use with the SunMailer can be seen here:
http://karmayog.in/events/mail-list-view

The newsletter content that I get is very different. In case you send me your email address- I can fwd the SunMailer Newsletter that I is getting generated and mailed out by the module. That might help explain the specific issue that I'm facing.

Looking forward to the release!

I think I'm going to push things back a bit so I can also put in some sort of alter hook for the XML. Custom fields is a big plus, and no-one should have to implement a hook to use those in SunMailer.

That being said, there are other potential customizations one may wish to make for the XML. And unlike the fields provided by views, which are broadly usable, some of these customizations may be built specifically for the organization, and obviously wouldn't go into the public release of SunMailer. Thus, an alter hook for the XML would be the best solution here.

(This should make the module sufficiently powerful for any use case. After all, XML and XSLT are Turing-complete.)

Code has been added to the dev branch.