Social publishing channel publication options

[smelis]

Hi,

Past week I've had my first attempt at alfresco development. I set out to create a new social publishing channel for one of my web services.
After setting up the dev environment implementing the AbstractChannelType was pretty straighforward and it now runs beautifully.

However, I've now found the need to implement some additional features of which I'm not sure how and where to implement.
Let's say I have a DropboxChannelType and that in the social-publish dialog I want to select the folder to which the publication should be saved.

Do I extend the social-publish dialog and accompanying javascript or do I add an additional screen that pops up after the publication dialog?
And how where do I do this? Change the workflow definition for publications?

I know I can add properties to the content model for my channel type, but then any settings put in there would be for all my publications and I want to be able to select these options on a per publication basis.

Any pointers as to how and where to do this the right way would be much appreciated.

Cheers,
Stefan

[smelis]

Ok, so, here's what I've done to get this to work. It involves some abuse, so it's definitely not a final solution.

The api/publishing/queue which accepts requests for publications takes a json.
The string that's being put on the queue is built inside social-publish.js in the onPublishButtonClick event handler.
It pushes a json string to the queue called publishData, which, thankfully, may contain a comment element.

Here's where the abuse comes in. I put my options in this comment section (it doesn't appear to be used anywhere else for anything useful (as far as i can tell)) .

onPublishButtonClick: function SP_onPublishButtonClick()
      {
        this.options = {};
       this.options.someOption = true;
       this.options.anotherOption = "1,2,3";
       this.options.thirdOption = 654;
         // create the JSON object for the POST request.
         var selectedChannelId = this.widgets.selectChannelButton.get("value"),
            publishData = 
            {
               "channelId": selectedChannelId,
               "publishNodes": [this.showConfig.nodeRef],
               "statusUpdate": {},
               "comment": this.options
            },
…
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Subsequently my AbstractChannelType implementation gets a reference to the event node which contains this comment property like so:

    public void publish(NodeRef nodeToPublish, Map<QName, Serializable> properties) {
        NodeService nodeService = getNodeService();
        if (nodeService != null) {
            
            try {
                
                List<AssociationRef> lar = nodeService.getTargetAssocs(nodeToPublish, PublishingModel.ASSOC_LAST_PUBLISHING_EVENT);
                if (lar != null)
                {
                    AssociationRef lastEvent = lar.get(0);
                    if (lastEvent != null)
                    {
                        NodeRef lastEventNode = lastEvent.getTargetRef();
                        String comment = (String) nodeService.getProperty(lastEventNode, PublishingModel.PROP_PUBLISHING_EVENT_COMMENT);
                        log.info(comment);
                    }
                }
…
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I guess it would be better if I didn't have to abuse the "comment" element for this and instead the PublishingModel would provide for an "options" element or something similar.

How do I best proceed with this? Do I extend the publishing model? Put in a change request at Alfresco? Stick with the comment-element-abuse?

Thanks for any help.

Stefan

[smelis]

Alas, a bug thanks to the abuse of the comment property…

The publication history div on the document details page fails to load, because it can't parse the JSON string that's in the comment element.
I tried emptying the property from within the publish() method in the java class of my channel, which partially solves the issue.
Partially because when an exception is raised in publish() the transaction in which the property is removed is rolled back (is my best guess) and thus the comment property retains the JSON string.

A workaround for this has been to Base64 encode the property from within the javascript before I put it in the comment property.
That way the div will still load properly, albeit with a base64 string in the comment.

Would be nice if the PublishingModel would provide for an options property e.g.

public static final QName PROP_PUBLISHING_EVENT_OPTIONS = QName.createQName(NAMESPACE, "publishingEventOptions");
‍‍‍