Sorry but I can't find documentation about this...
If I want to use more than one workspace in Alfresco, how can I specify the workspace to use?
For example, to access a node, I use an url like this:
workspace://SpacesStore/32da316f-9d2a-4e57-a28b-89d86bff6584
If I have various workspaces (A and B)... How can I difference one from another with this url?
And on the code side... when I use Alfresco API Java operations, I authenticate with user and password (with getAuthenticationService().authenticate method). And do something like, for example, a query to search a node (TYPE:"{mymodel}exp" AND PATH:"/app:company_home/app:user_homes/cm:mydir").
My question is the same... How can I specify one or other workspace to search in A or B? Has a different spacestore?
Related
Our Share users currently have a static large list of parameters that they need to manually re-input everytime documents needs to be searched.
Is there any way of saving search/queries in Alfresco share?
This function was available in the g'old explorer UI, but unfortunately never got into Alfrescp Share or into Alfresco Digital Workspace. As a work around you may take a look into the Saved Search dashlet ?
There is a dashlet called Saved Search available.You can use that or you can create similar dashlet with your customization.
I can use the powershell command: New-AzureRmResourceGroupDeployment, with a relevant template file to create an instance of all the items within the template. In fact, this is how I initially created some of the components in the current resource group I am working on. Since creating my Azure components I have tweaked things quite a lot, and I would like to create a template based on the setup in my resource group as it stands now, this would allow me to run the above command and to recreate the components if I ever need to.
Can anyone tell me if there is a way to create a template based on an existing resource group?
Looks like there are some MS docs detailing the process here:
https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-export-template
I have recently started developing with aikau in alfresco share.
I want to achieve a functionality wherein I can export search results to a CSV file.
For that, I can change the back-end repository web script to return csv data.
Now, At alfresco share end - I was successfully able to show the export link by adding a new widget to FCTSRCH_TOP_MENU_BAR. I used alfresco/renderers/PropertyLink to display this link. Now, the missing part for me is - how can I invoke the search web script passing additional param format=csv and alongwith that pass all the query parameters used to retrieve the results.
I am stuck with that. If I use the publishTopic as ALF_CRUD_GET_ALL and provide the URL there then it invokes the sample web script (I created to return sample csv response) and returns the response. However, the csv doesn't come as downloadable response. I am stuck here in order to how to achieve export csv functionality for search results.
It would be great if any of you can help me here and provide your guidance/suggestions.
This blog post provides an example on how you can custom the search page in Share. Although it specifically addresses changing the search queries the basic extension approach is more or less that same in that you will want to change the data that is used to send an XHR request. I think that the major difference here is that you may need to do more in-depth updates to the service - in particular with regards to the switch statement that is used to build the advanced search query object.
If you have extended or replaced the default search REST API then I would expect that you will need to call the same URL, but if you have provided an entirely new REST API to return the CSV data then you'll also need to change the URL that is used by the service.
In terms of providing a link for downloading the content we have previously implemented something in the DragAndDropModelCreationService (see the generateDownload function) but this only works with Chrome due to security limitations and the generation of files to download.
Your best bet may be temporarily store the CSV content on the repository in a hidden location and then use the standard download links to allow it to be downloaded - this would be more complex but would provide better cross browser support. Something similar is done for the "Download as ZIP" action.
OK, with the extra information provided I would do the following...
The information on the process of adding widgets to the search page are quite well detailed here (although you're not adding a view, you can follow the approach to add a new PropertyLink after the widget with the id "FCTSRCH_RESULTS_COUNT_LABEL").
The approach I would take would be to include an additional custom service on the page that subscribes to the "ALF_RETRIEVE_DOCUMENTS_REQUEST_SUCCESS" topic (which is published on a completed search). It should save the the search response in a variable in preparation for users clicking on the PropertyLink.
This custom service should also subscribe to a topic that is published by the PropertyLink (called say "DOWNLOAD_CSV"). This custom service could then generate a file download using the approach described in my previous answer using the CSV data that will have been provided in the payload. As I said though, this may only work with some browsers due to security reasons.
If your custom search WebScript were able to store the CSV data as a node on the Repository then you could just provide a the NodeRef of the CSV data in the search response and the PropertyLink could just publish the "ALF_DOWNLOAD" topic for the DocumentService to handle the download.
Trying to generate a file to download on the client side is going to be an issue for most browsers I think.
Currently i have not a code-problem, but i dont know which way would be better for me.
For our project, we have two kind of data which would be translatet for the view.
The part, which be coded in the source code like system messages (e.g. You are logged in, log out, etc.)
The second part is the database content like services, there can be added or deleted rows. And not for every entity would be a translation available.
Now i need to know, if i should save and get the translation from a translation table or is it better to transfer (via script) the translation into a services.xliff file
I would suggest to use XLIFF or GetText for the application (source: php, js).
Especially http://jmsyst.com/bundles/JMSTranslationBundle might be helpful.
The storage mechanism is less important, because of caching. So feel free to use either a DB or files as backend.
User created content is often managed via database. So you might use a common DoctrineExtension, like translateable. http://symfony.com/doc/current/cookbook/doctrine/common_extensions.html
https://github.com/stof/StofDoctrineExtensionsBundle/blob/master/Resources/doc/index.rst
I am designing a system that uses asp.net webapi to serve data that is used by a number of jquery grid controls. The grids call back for the data after the page has loaded. I have a User table and a Project table. In between these is a Membership table that stores the many to many relationships.
User
userID
Username
Email
Project
projectID
name
code
Membership
membershipID
projectID
userID
My question is what is best way to describe this data and relationships as a webapi?
I have the following routes
GET: user // gets all users
GET: user/{id} // gets a single user
GET: project
GET: project/{id}
I think one way to do it would be to have:
GET: user/{id}/projects // gets all the projects for a given user
GET: project/{id}/users // gets all the users for a given project
I'm not sure what the configuration of the routes and the controllers should look like for this, or even if this is the correct way to do it.
Modern standard for that is a very simple approach called REST Just read carefully and implement it.
Like Ph0en1x said, REST is the new trend for web services. It looks like you're on the right track already with some of your proposed routes. I've been doing some REST design at my job and here are some things to think about:
Be consistent with your routes. You're already doing that, but watch out for when/if another developer starts writing routes. A user wants consistent routes for using your API.
Keep it simple. A major goal should be discoverability. What I mean is that if I'm a regular user of your system, and I know there are users and projects and maybe another entity called "goal" ... I want to guess at /goal and get a list of goals. That makes a user very happy. The less they have to reference the documentation, the better.
Avoid appending a ton of junk to the query string. We suffer from this currently at my job. Once the API gets some traction, users might want more fine grained control. Be careful not to turn the URL into something messy. Something like /user?sort=asc&limit=5&filter=...&projectid=...
Keep the URL nice and simple. Again I love this in a well design API. I can easily remember something like http://api.twitter.com. Something like http://www.mylongdomainnamethatishardtospell.com/api/v1/api/user_entity/user ... is much harder to remember and is frustrating.
Just because a REST API is on the web doesn't mean it's all that different than a normal method in client side only code. I've read arguments that any method should have no more than 3 parameters. This idea is similar to (3). If you find yourself wanting to expand, consider adding more methods/routes, not more parameters.
I know what I want in a REST API these days and that is intuition, discoverability, simplicity and to avoid having to constantly dig through complex documentation.