Updating to 4.0

[GoogleCodeExporter]

In looking at what needs to be done to enable the toolkit for share we should 
probably look at if we want to continue to implement them as actions exposed to 
the rules engine or should we just create them as document actions?

Pros:
I believe these would be simpler to implement, using the FDK.
--Most all (or all) of the actions currently require user input to perform.
--There is no execute action at the document level, which means that we need to 
add one.
--As a rule we might need to add write YUI widgets to add them to the rules 
engine.  Most of the ones needed may already to exist in the FDK.

Cons:
No rules could be created using these actions.
--though they could be scripted.

Original issue reported on code.google.com by jottley on 4 Apr 2012 at 4:47

[GoogleCodeExporter]

I think we can do both.  I would like to refactor the actual grunt code that 
alters the PDF files out into a set of service classes.  The existing actions 
could then use those service classes.  In addition, we can expose that same 
service as a root-level object in the Javascript API, as described here:

http://wiki.alfresco.com/wiki/4.0_JavaScript_API#Adding_Custom_Script_APIs

I think this would make the toolkit available to anything that uses the 
Javascript API, including web scripts, workflows, etc.  If there was a 
root-level Javascript object defined that encapsulated the PDF toolkit service, 
could that be used by the FDK?  

By the way, I have made some progress on enabling the current rules to be used 
within Share.  I have the field labels working (hey, it's a start, right? ;-).  
Each one of the ActionExecuters has an addParameterDefinitions method that 
populates the parameter list with the parameter name, type, mandator and label. 
 Here's what one of the entries looks like in the PDFSignatureAction:

paramList.add(new ParameterDefinitionImpl(PARAM_PRIVATE_KEY,
                DataTypeDefinition.NODE_REF, false,
                getParamDisplayLabel(PARAM_PRIVATE_KEY)));

When called from Alfresco Explorer, getParamDisplayLabel returns the correct 
value.  When called from Share, it does not.  Working on a fix now, something 
that will work in both contexts.

Original comment by nmcminn on 5 Apr 2012 at 1:32

[GoogleCodeExporter]

So I've gotten the share side working� here is what I did to make it work.

I added new message strings

pdf-append.target-node.display-label=Append to
pdf-append.destination-folder.display-label=Destination
pdf-append.destination-name.display-label=Merged Name

format:
custom-key-name.<param-name>.display-label 

And then in the context.xml

You need to add a depends-on attribute to the bean

    <bean id="pdf-append"
        class="org.alfresco.extension.pdftoolkit.repo.action.executer.PDFAppendActionExecuter"
        parent="action-executer" depends-on="pdftoolkit-messages">

I've also added some more candy to the bean definition:

    <property name="applicableTypes">
            <list>
                <value>{http://www.alfresco.org/model/content/1.0}content</value>
            </list>
        </property>

Which should limit what types of nodes the action can be applied to.

Jared

Original comment by jottley on 5 Apr 2012 at 2:48

[GoogleCodeExporter]

Awesome.  I'm testing this now and will apply it to the appropriate
actions.  Thanks Jared!

Original comment by nmcminn on 5 Apr 2012 at 6:25

[GoogleCodeExporter]

Success!  That sorts out the field labels.

However, I am still not seeing the right UI widget for the parameter type.   
Specifically, everything is showing up as a text box.  I have the select lists 
working now as they did in the Explorer UI.  I started with the "visibility" 
select list in the digital signatures action.  Here's how I set it up:

1.  Created a class called VisibilityConstraint in package 
org.alfresco.extension.pdftoolkit.constraints that extends 
BaseParameterConstraint.  This class simply wraps up the HashMap that contained 
the constraints in the PDFSignatureActionHandler class.

2.  Exposed the constraint as a bean called pdfc-visibility in the module 
context file, like so:

<bean id="pdfc-visibility" 
class="org.alfresco.extension.pdftoolkit.constraints.VisibilityConstraint" 
parent="action-constraint"/> 

3.  Referenced that bean in the PDFSignatureActionExecuter when the parameter 
is added to the list, like this:

        paramList.add(new ParameterDefinitionImpl(PARAM_VISIBILITY,
                DataTypeDefinition.TEXT, false,
                getParamDisplayLabel(PARAM_VISIBILITY), false, "pdfc-visibility"));

Now, when the digital signature action is selected in Share, the visibility 
parameter is a select list instead of a text box.  Working through the rest of 
the constraints now.

The attached AMP file demonstrates the progress in the digital signature action 
in Share.  I'll commit the changes as soon as I do a little cleanup :-)

-- Nathan

Original comment by nmcminn on 5 Apr 2012 at 8:57

Attachments:

• alfresco-pdf-toolkit.amp

[GoogleCodeExporter]

Issue 14 has been merged into this issue.

Original comment by jottley on 13 Aug 2012 at 5:06

[GoogleCodeExporter]

Hi,

Is it working for Alfresco Share now. It would be nice to have options to 
split/merge pdfs under document actions.

Regards,
Hemant

Original comment by hemant1...@gmail.com on 16 Aug 2012 at 7:34

[GoogleCodeExporter]

Not yet, we are working towards this, plus other enhancements.

Original comment by jared.ot...@alfresco.com on 16 Aug 2012 at 4:18

[GoogleCodeExporter]

Initial support for 4.x and Share is out in version 0.98.28. 

Original comment by nmcminn on 18 Sep 2012 at 11:34

• Changed state: Fixed