Subscription Functionality for dLCMS Content Elements

[Flynt]

This is not a bug but a new feature.

Is it possible to use the Silva Subscription mechanism for changes of contents also for dLCMS Content Elements?

The "Mobility Matters" people want to have that.

[Flynt (flyntle)]

Probably this issue involves also Yves Serrano pretty much, and Benno Luthiger.

[Andy Altepeter (aaltepet)]

Subscriptions appear to be working "out of the box". Just enable the service, enable subscriptions through /edit/tab_subscriptions, and then visit the public view of an object and append "/public/subscriptor".

There are some issues with this:
1) The subscription template doesn't use SilvaLayout, so regardless of the layout specified in the properties (e.g. dlcms plain layout), it uses the stock Silva layout.
2) dLCMS VersionedContent objects, like "Content Element", can't access "/public/subscriptor" because no view is registered on the content object, just the content version. I've adjusted the SilvaDLCMS install script so public views are also registered for the three VersionedContent types, "Content Element", "Questionairre", and "Slide". This makes the public view accessible, so the subscription will actually work.

I don't currently have a working smtp-relay, so I can't test the full process at this time.

What's now needed:

1) convert the subscription template to use SilvaLayout
2) Fully test subscriptions

[Kit Blake (kitblake)]

Note that the current subscription template assumes it's in a ZODB-based layout and fills a slot in layout_macro.html. This makes the subscription forms act like content, because it fills 'main', and it shows up in whatever layout is used, e.g.:
http://infrae.com/service/public/subscriptor
Also, users can always customize the subscription template by pointing it to a new template they create.

We must find a way to override only when SilvaLayout is installed. What about defining some (Five) view that's not in './public'? Such as:
http://infrae.com/object/subscriptor

[Andy Altepeter (aaltepet)]

I actually emailed thisfred about this last night...I suppose I should've included it in this issue. Here's what I said...basically what I don't know is how to get the Zope3 view to use SilvaLayout templates...

I'm thinking a Zope 3 view could be created on ISilvaObject which basically
replaces "subscriptor". Well, both could exist, as some Silva sites may not
be using SilvaLayout yet (we don't). If you're using SilvaLayout, you link
to the public subscriptor by adding '@@subscriptor' to the url, otherwise you
link to 'public/subscriptor'. These links have to be manually added by those
sites implementing the subscriptions service anyways, so this shouldn't be a
problem.

The only problem I can't overcome yet, is how to define a new view in a Layout
that uses the layout. I don't know how to describe this, so let me try and
explain further:

This code for this new subscriptor view (I'm thinking the page template here)
should only be the stuff within the "content" section of the layout template.
In layout_macro terms, it should fill the "main" slot. I don't know if it is
possible to fill the "main" slot of a SilvaLayout template from an additional
view? If you could help by explaining a bit how this works, or by pointing
to an example, I'd really appreciate it.

[Andy Altepeter (aaltepet)]

OK, for the life of me, I don't know how to get the view to be wrapped inside a skin. I have the view registered, and it's accessible by appending '/subscriptor' to an item (make sure you have subscriptions enabled!).

What I'm thinking now is to:
1) Have a new acquisition-friendly class, that basically knows how to render
   the subscriptor page using the standard silva api (ummm, self.render()?)
2) In the subscriptor view, create a new instance of this class, and do instance = instance.__of__(self.context)
3) Somehow get the publisher to re-run with the new context (create a sub-request?).

In the subrequest, the rendering process should put the subscriptor within the skin, and hopefully keep the navigation and such within the context of the Silva object.

At this point, I have no idea how to do this. I feel like I'm thinking too hard. Do you have any thoughts, or know who might?

[Eric Casteleijn (thisfred)]

I have this working, I moved the SilvaLayout based subscription views into SilvaLayout, and the DLCMS overrides for that into SilvaDLCMSLayout. What still needs to happen is the actual styling to make things look nice with the dlcms views (adding classes to css I think) and adding a subscription link top the public view templates.

[Samuel Schluep (schluep)]

I did not manage to get this working with my setup (heads of Silva 1.6 branch, SilvaLayout 1.6 branch, SilvaDLCMS trunk, SilvaDLCMSLayout trunk, Zope 2.8.5, Python 2.3.5, Windows XP). Silva and SIlvaDLCMS have been refreshed after updating, MaildropHost is not installed. I enabled "subscriptions" in service_subscriptions in the ZMI and set "subscribable" in the SMI properties/subscriptions tab of the Silva root to "Yes". When I add "/public/subscriptor" to the URL of the Silva root public view I get the following error: KeyError, 'view_method' (see traceback in the attachment).

Is my installation correct?

[Eric Casteleijn (thisfred)]

I think I found something that might cause this. Can you update your SilvaDLCMS trunk, and see if it works then? The view should now show, but of course subscribing and unsubscribing won't work without a maildrophost.

[Samuel Schluep (schluep)]

I found the reason for the KeyError, ''view_method': the layout_macro.html of the SilvaDLCMS default layout and the SilvaDLCMSLayout product contain a tal definition that set the variable view_method to options/view_method. The subscriptor does not supply the view_method in the request, therefore a KeyError is thrown. In the standard Silva layout the options/view_method is also called, but only in the main slot of the macro. The dLCMS layouts use view_method also at other places. This KeyError can be solved with the following tal definition: tal:define="global view_method options/view_method | nothing". I'll correct this for both, the dLCMS default layout and SilvaDLCMSLayout.

[Samuel Schluep (schluep)]

Oh, using the subscription view with SilvaDLCMSLayout uses the basic ZMI based layout_html and not the the SilvaDLCMSLayout. I thought that SilvaDLCMSLayout (trunk revision 26527) has been modified for the use with the subscription feature?

[Eric Casteleijn (thisfred)]

This is really strange. I get the subcription view rendered in the dlcmslayout, every time. The steps i take to get there:

1. ZMI: make a new silva root
2. ZMI: in service_extensions install all products
3. ZMI: in service_subscriptions enable subscriptions
4. SMI: in the properties/subscriptions screen of the root, set subscribable to Yes
5. SMI: in properties/settings of the root, set skin to DLCMSNavigation
6. Public site: Go to the url of the silva root + /subscriptor

I can subscribe there, and I see the subscription form in the dlcms layout

[Samuel Schluep (schluep)]

OK, I used <silva root> + 'public/subscriptor' to access the subscription form. I this case the ZMI based layout templates is used. With <silva root> + '/subscriptor' the SilvaLayout based layout is used. Thus, this problem is solved.

I suggest that the documentation on http://www.infrae.com/products/silva/silva_docs_1_6/manager/subscription_config should tell users to use <silva root> + '/subscriptor' if SilvaLayout based layouts are used.

Apropos documentation, it would also be helpful if the Silva documentation would contain a note that service_subscriptions_mailhost needs to be configured to setup the subscription feature.

[Samuel Schluep (schluep)]

Tested, this works like a charm. Removing tag test-required.

[Samuel Schluep (schluep)]

Fix released Silva dLCMS 1.6.1 and Silva dLCMS Layout 1.6.1