Extend OTB slingshot search Webscript Alfresco 5.0 C - csv

I want to add a csv response template to the default slingshot/search? web script which is inside in a jar (Alfresco remote api).
Already l have an ant script which build a jar inside Alfresco/tomcat/shared/lib
Inside this jar l have define an extension xml file config/alfresco/site-data/extensions/extension-modules.xml
<extension>
<modules>
<module>
<id>Custom DocumentList Widget</id>
<description>Extend Alfresco Search</description>
<customizations>
<customization>
<targetPackageRoot>org.alfresco.slingshot.search
</targetPackageRoot>
<sourcePackageRoot>webscripts.search</sourcePackageRoot>
</customization>
</customizations>
</module>
</modules>
</extension>
Also lnside config/webscripts/search l have the search.get.csv.ftl file but I never get the csv response. Is this the best way to modify/extend the default web script ?

No this isn't the best way to extend this in your case.
Normally it is, but in your case just use the default override mechanism of Alfresco.
So just place your addition in org/alfresco/slingshot/search, cause Alfresco doesn't has a csv.ftl file, so it will be available.
The extension module is uses to extend/change the default get.js & get.html.ftl file, so I'm not sure if it will accept any addition if you don't specify the one of the above files.

Related

Loading JSON files in React, without JSON extension

I'm trying to require some JSON files in my React app (based on CRA 3.01 with Typescript).
The normal const obj = require('./path/file.json') would work if my files had a .json extension - however, these files have .md for 'metadata' and a couple other extensions, and the standard require isn't working. The files are from a tool, so changing to .json isn't a practical option.
Doing some research, it seems the approach is to use the webpack json-loader module (the webpack json-loader docs says that working with different file extensions is the main reason for using the module). I found an example and am using this:
const context = require.context(
"json-loader!./metadata",
true,
/^\.\/.*\.md$/
);
const metadata = context("./foo.md");
I've got a minimum reproduction here (see App.tsx):
https://github.com/ericsolberg/testjson
It seems that this is correctly using the json-loader, and finding the file correctly. However, I'm getting a syntax error:
Error: Module build failed (from ./node_modules/json-loader/index.js):
SyntaxError: Unexpected token m in JSON at position 0
at JSON.parse (<anonymous>)
at Object.module.exports (/Users/***/projects/jsontest/node_modules/json-loader/index.js:4:49)
I did some research on this error, and believe the problem is that the file is being parsed twice - first by the loader configured by CreateCreactApp's default webpack config, then by the specified JSON loader.
I don't want to eject my CRA app to modify the webpack config, and would like to avoid a re-wire hack (and whatever other issues that introduces) ... does anyone know of a way to load JSON files in a CRA app, if these files don't have a JSON extension?
Here's the solution that ended up working for me.
I could eject my project, of course, and customize the webpack config to load JSON files with other extensions. It may be possible to make a rewire hack work as well.
But I realized that when I require a file that is not one of the extensions recognized by CRA's config, it instead copies that file into the build, and require('file.ext') returns the URL of the file. So I'm using axios to load the file. This means a trip to the server for something that could be done statically, but for where I'm taking this project that is actually OK (eventually it will load metadata from a server anyway).

Erlang: How to include libraries

I'm writing a simple Erlang program that requests an URL and parses the response as JSON.
To do that, I need to use a Library called Jiffy. I downloaded and compiled it, and now i have a .beam file along with a .app file. My question is: How do I use it? How do I include this library in my program?. I cannot understand why I can't find an answer on the web for something that must be very crucial.
Erlang has an include syntax, but receives a .hrl file.
Thanks!
You don't need to include the file in your project. In Erlang, it is at run time that the code will try to find any function. So the module you are using must be in the search path of the VM which run your code at the point you need it, that's all.
For this you can add files to your path when you start erlang: erl -pa your/path/to/beam (it exists also -pz see erlang doc)
Note that it is also possible to modify the path from the application itself using code:add_path(Dir).
You should have a look to the OTP way to build applications in erlang documentation or Learn You Some Erlang, and also look at Rebar a tool that helps you to manage erlang application (for example starting with rebar or rebar wiki)
To add to Pascal's answer, yes Erlang will search for your files at runtime and you can add extra paths as command line arguments.
However, when you build a project of a scale that you are including other libraries, you should be building an Erlang application. This normally entails using rebar.
When using rebar, your app should have a deps/ directory. To include jiffy in your project, it is easiest to simply clone the repo into deps/jiffy. That is all that needs to be done for you to do something like jiffy:decode(Data) in your project.
Additionally, you can specify additional include files in your rebar.config file by adding extra lines {erl_opts, [{i, "./Some/path/to/file"}]}.. rebar will then look for file.so using that path.

How can I import JSON data from a REST API into BIRT?

I want to use BIRT to generate reports against data that comes from a JSON based REST API. How can I import this data?
The process for doing this is described at http://developer.actuate.com/community/forum/?app=blog&blogid=45&showentry=471, but it turns out that there are a few important steps missing. I'll fill in a few blanks here.
The original instructions describe creating a Scripted Data Source, with an "open" script that makes use of the com.actuate.json.JSONParser class. First, it is important to realise that this class is not part of BIRT, and needs to be manually added (along with any dependencies).
The download provided by the original instructions provides the com.actuate.json.JSONParser class, but leaves it up to you to source the dependencies. To make things easier I have reimplemented the JSONParser library in Maven, which will then download and package the dependencies for you. It also includes some bug fixes and enhancements like GZIP compression support. You can get the Maven project from https://github.com/mcasperson/birt-jsonparser, and to build the JSONParser library and package the dependencies, run the command
mvn clean package dependency:copy-dependencies
This will result in the birt-jsonparser-0.0.1-SNAPSHOT.jar file being created in the target directory, and all the dependencies copied into the target\dependency directory. Copy all of these JAR files into the {BIRT_INSTALL}/plugins/org.eclipse.birt.report.viewer_{BIRT_VIEWER_VERSION}/birt/scriptlib directory to allow the JSONParser class to be accessed from within your BIRT report.
If you want to debug your report, these JAR files will also have to be referenced in the Debug profile.

Configuring DisplayTag for individual pages

I have too many modules (around 90) in my project.
But I want to keep individual displaytag.properties file for each module rather than having single file for whole project.
How to achieve this.
I am using struts2
I think that you can configure each displaytag using the appropiate bundle, remember the bundle search order from S2 docs:
ActionClass.properties Interface.properties
Interface.properties (every interface and sub-interface)
BaseClass.properties (all the way to Object.properties)
ModelDriven's model (if implements ModelDriven), for the model object repeat from 1
package.properties (of the directory where class is located and every parent directory all the way to the root directory)
search up the i18n message key hierarchy itself
global resource properties
and from the docs for the DisplayTag library:
For the whole web application, create a custom properties file named "displaytag.properties" and place it in the application classpath. Displaytag will use the locale of the request object to determine the locale of the property file to use; if the key required does not exist in the specified file, the key will be loaded from a more general property file.
so i guess that the displaytag will search the config keys in the s2 available bundles.

Is there any way to add sections to .config files that will not be parsed by ConfigurationManager

I don't want to create separate configuration file for my app but store the data in the web.config.
I just want to put some XML there and manually parse it because current implementation of ConfigurationManager isn't appropriate for my case.
However, without dummy classes and properties I can't add my XML there without getting Configuration Error: Parser Error Message: Unrecognized element XXXXX. Even if I create dummy configuration classes I can't fix this error in all cases...
Is there any way to mark my XML not to be parsed so that I can use System.XML to manually get the data.
Thx.
Use System.Configuration.IgnoreSectionHandler.
Example:
<configuration>
<configSections>
<section
name="myCustomSection"
type="System.Configuration.IgnoreSectionHandler, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
allowLocation="false" />
</configSections>
...
<myCustomSection>
...
</myCustomSection>
...
</configuration>
I would suggest creating a custom figuration section if you want to store the data in your .configs
www.codeproject.com/KB/cs/CustomConfigurationSectio.aspx
I don't think you can do this - you need to conform to the XML schema for configuration files if you play around in the *.config files - and this means, you need to have your sections according to the specified schema, and if that's the case, ConfigurationManager will be able to parse them (and will do so).
If you need extra config information that doesn't conform to the standard .NET config schema, you'll have to use extra, separate config files - I don't see any other way, sorry.
Marc