I'm using Alfresco 5. I have create a custom type (parent type is cm:folder) and
added an entry for this type in the Document Library "Create" menu.
I would like to override the default folder create function so that I can do
some custom processing.
I would like to create some content within the new folder each time.
You can use alfresco behaviour/policies for your requirement.
For creating policy you need to create below things.
1.Spring Bean in context file
2.One class which implements onCreateNode from org.alfresco.repo.node.NodeServicePolicies
For more information regarding policies read below blog written by Jeff Potts
http://ecmarchitect.com/alfresco-developer-series-tutorials/behaviors/tutorial/tutorial.html
Apart from behaviour/policies easier option would be using rule and script.
You can create a rule which will be executed on creation of new
folder.
Create alfresco java script which will do processing you required on creation of
new folder.
Hook up script with rule.
Related
Is there a way to programmatically create folders? There was a way to do it in lotus script - that method also was not documented in designer help. I want to get a document collection and then put the whole collection into a folder. I can see in the documentation that this will create the folder - I want to add columns to the folder. I suppose at worst I can open the folder after it has been created from the "put" command.
You can use ViewEntryCollection.PutAllInFolder method https://www.ibm.com/support/knowledgecenter/en/SSVRGU_9.0.1/basic/H_PUTALLINFOLDER_METHOD_VEC_JAVA.html
The folder will be created from the view/folder flagged as "Default for new views/folders" property. To change its design, you can use createColumn method https://www.ibm.com/support/knowledgecenter/SSVRGU_9.0.0/com.ibm.designer.domino.main.doc/H_CREATECOLUMN_METHOD_VIEW_JAVA.html
If you want to modify the design by adding columns, it will need to run with a ID that has at least Designer access to the database. ODA has a design API that can be used to create design elements via DXL. I've used it to create views, but folders should work the same.
If you don't need to modify the design, you can create a Shared Private on First Use folder by running as the user and calling getView(). I don't think that needs designer access, but it's worth double-checking.
Note: the ODA methods haven't been tested from SSJS. If it works, you're lucky, but the focus is Java.
How to create my own custom version of Jaxb2RootElementHttpMessageConverter; so I can give it my own defined JAXB2 Marshaller via the application context xml configuration file?
Thanks,
Tonté
Just create a sub-class of the Jaxb2RootElementHttpMessageConverter.java and then override the necessary methods. Or you can complete create your own class by copying and pasting the source code of the Jaxb2RootElementHttpMessageConverter.java and then update class as necessary.
I have followed this tutorial to create a send email custom action using Java backed Webscript:
http://ecmstuff.blogspot.com/2012/04/adding-document-library-actions-in.html?showComment=1403279845779#c303784066266925848
As has been mentioned above, there is an AbstractWebScript class defined just to execute the action without using a freemaker template, but I get this error:
Cannot locate template processor for template sendDocInEmail.get.html
I guess, there is a problem with the -context.xml file
My files are placed in the following folders:
1. the java .class files are in \tomcat\webapps\alfresco\WEB-INF\classes (placed with the package structure)
2. sendDocInEmail.get.desc in \tomcat\shared\classes\alfresco\extension\templates\webscripts folder (with the package structure)
3. services-context.xml file in the folder \tomcat\webapps\alfresco\WEB-INF\classes\alfresco\module (again with the package structure)
Please help!
Thanks in advance.
You most likely derived your class from DeclarativeWebScript which extends AbstractWebScript and adds the template processing. Make sure to derive your class from the latter.
I want to audit-trail all changes made to dataobjects. Say I have Event dataobject and I want to know who changed it, when changed, what is changed etc. (Similar to Pages).
Silverstripe site recommends the use of Verioned but I can't find any examples of implementation. It says the best example is Pages which is is already comes with Versioned implemented. The basic rule is to define an augmentDatabase() method on your decorator.
So, I want to use DataExtention for dataobject (extension) and then use the extended one for my Event dataobject. But is there any simple example?
Assuming you want to manage and monitor multiple versions of the event DataObject, you simply need to declare that you want to use the versioned extension for thatDataObject
Class Event extends DataObject{
static $extensions = array(
"Versioned('Stage', 'Live')"
);
...
}
Then run a dev/build
You should now have a Event, Event_Live, and Event_versions tables.
You can then have a look at the methods available in Versioned.php, and use them with Event, ie publish(). This should get you started.
"Versioning in SilverStripe is handled through the Versioned class. It's a DataExtension, which allow it to be applied to any DataObject subclass."
"Similarly, any subclass you create on top of a versioned base will trigger the creation of additional tables, which are automatically joined as required."
Here is link to read further with examples
Versioning of Database Content
It seems that toolset.xml goes only half way. Ideally it should be able to do away with the ToolInit call in initialize() in __init__.py. But I could not get the tool icon to show in the ZMI without the ToolInit call.
The ToolInit call in the initialize function registers the tool class as something that can be added to OFS based folders in the database - primarily it register a factory for creating instances of the class. This is basically the same that ContentInit does for normal content classes.
Once the class is registered and its meta_type is known, instances of the class can be added to OFS based Folders. GenericSetup steps are responsible for managing persistent content and can be used to add tool instances to the database.
If we wanted to avoid the code in the initialize function, we would need to create some custom ZCML directives instead and use these in a configure.zcml to register the type and its factory. Dexterity has gone this route, but its not available for Archetypes based content types or general classes like tools.
The goal of toolset.xml is to instantiate tools into the database. It can also be used to remove tools; this is very useful in upgrade steps for example.
Example toolset.xml:
<?xml version="1.0"?>
<tool-setup>
<required tool_id="portal_foo" class="dotted.path.to.FooTool" />
<forbidden tool_id="portal_spam" />
</tool-setup>
This example toolset.xml would instantiate the FooTool class as portal_foo in it's context, and remove any object with id portal_spam if present.
Note that you can use a toolset.xml in any GenericSetup profile, not just in the package that defines the tool in the first place, for example, in general policy packages for a site you develop.