Skip navigation
All Places > Alfresco Content Services (ECM) > Blog > 2017 > February
2017

Just before Christmas we looked though the collaboration APIs for nodes, after a longer than planned hiatus the series continues with a look at some of the collaboration APIs for sites.

 

Way back in part 1 we installed 5.2.b, it's now time to re-install so that we can take a look at some of the newer APIs in this and future posts. Download and install the latest Community release (5.2.f at the time of writing) and optionally install the latest API Explorer by copying the WAR file as "api-explorer.war" to <install-home>/tomcat/webapps.

 

As has become tradition this post is accompanied by a Postman collection, click the "Run in Postman" button below to import it into your client.

 

 

One of the new APIs to have been added since 5.2.b is the create person API, let's use that to create a test user by POSTing the following body to http://localhost:8080/alfresco/api/-default-/public/alfresco/versions/1/people  (1st request in the Postman collection).

{
   "id": "test",
   "firstName": "Test",
   "lastName": "User",
   "email": "test@alfresco.com",
   "password": "test"
}

 

This will result in the response below:

{
  "entry": {
    "firstName": "Test",
    "lastName": "User",
    "emailNotificationsEnabled": true,
    "company": {},
    "id": "test",
    "enabled": true,
    "email": "test@alfresco.com"
}
}

 

As with all previous posts we'll use this user for all subsequent requests unless specified otherwise.

 

OK, let's start by using one of the new endpoints added in 5.2, arguably one of the most anticipated, the ability to create a site that can be used in Share! 

 

To create a standard site with default configuration POST the body below to http://localhost:8080/alfresco/api/-default-/public/alfresco/versions/1/sites (2nd request in the Postman collection).

{
  "id": "publicSite",
  "title": "Public Site",
  "description": "Public site created for blog post",
  "visibility": "PUBLIC"
}

 

This will result in a response similar to the one below:

{
  "entry": {
    "role": "SiteManager",
    "visibility": "PUBLIC",
    "guid": "69a5a7b1-a338-4e11-8a61-115edd1190e6",
    "description": "Public site created for blog post",
    "id": "publicSite",
    "preset": "site-dashboard",
    "title": "Public Site"
  }
}

 

Now we have created our site how do we add files to the Document Library? Each "page" in a site has a container in which it stores it's data, the Document Library is no different, we can use http://localhost:8080/alfresco/api/-default-/public/alfresco/versions/1/sites/publicSite/containers/documentLibrary  endpoint (3rd request in the Postman collection) to GET the details (see response below), the id property provides the node identifier of the documentLibrary folder that we can then use in other APIs, refer back to part 3 for details on creating new nodes.

{
  "entry": {
    "id": "171f7d8a-09b0-413b-b41a-11e524833323",
    "folderId": "documentLibrary"
  }
}

 

Another new feature for 5.2 is the ability to update a site, to change the description of the site we just created PUT the body below to http://localhost:8080/alfresco/api/-default-/public/alfresco/versions/1/sites/publicSite (4th request in the Postman collection).

{
  "description": "Public site created for blog post - part 8"
}

 

The response below shows that the site description has been updated.

{
  "entry": {
    "role": "SiteManager",
    "visibility": "PUBLIC",
    "guid": "69a5a7b1-a338-4e11-8a61-115edd1190e6",
    "description": "Public site created for blog post - part 8",
    "id": "publicSite",
    "preset": "site-dashboard",
    "title": "Public Site"
  }
}

 

Although not demonstrated above it's also possible for a site manager to update the site's title and visibility properties, for example, to make a public site private.

 

Now let's turn our attention to site membership, to prepare for that we need to create a moderated site and create a second test user.

 

We create a moderated site in the same way we created the public site earlier except we pass "MODERATED" as the value for the visibility property as shown below (5th request in the Postman collection).

{
  "id": "moderatedSite",
  "title": "Moderated Site",
  "description": "Moderated site created for blog post",
  "visibility": "MODERATED"
}

 

The visibility property is an enum, the Alfresco API Explorer can be a great help here. Use the link or navigate to the POST /sites method and scroll down to the siteBodyCreate body parameter. Click the "Model" link on the right hand side to reveal the definition, this will show the allowed values for the enum.

 

Go ahead and create a second test user by POSTing the body below to http://localhost:8080/alfresco/api/-default-/public/alfresco/versions/1/people (6th request in the Postman collection).

{
  "id": "test2",
  "firstName": "Test",
  "lastName": "User2",
  "password": "test2"
  "email": "test2@alfresco.com"
}

 

We'll now use this new user to join the public site we created earlier and the moderated site we just created. The same endpoint is used to do both these actions http://localhost:8080/alfresco/api/-default-/public/alfresco/versions/1/people/test2/site-membership-requests. Join the public site by POSTing the body below (7th request in the Postman collection).

{
  "id": "publicSite"
}

 

This will return a response similar to the one shown below:

{
  "entry": {
    "createdAt": "2017-02-24T09:52:09.052+0000",
    "site": {
      "role": "SiteConsumer",
      "visibility": "PUBLIC",
      "guid": "69a5a7b1-a338-4e11-8a61-115edd1190e6",
      "description": "Public site created for blog post - part 8",
      "id": "publicSite",
      "preset": "site-dashboard",
      "title": "Public Site"
    },
    "id": "publicSite"
  }
}

 

As the site is public we are added immediately with the role of SiteConsumer, which can be seen in line 5.

 

Attempt to join the moderated site by POSTing the body below (8th request in the Postman collection).

{
  "id": "moderatedSite",
  "message": "I would like to join this site as it looks interesting"
}

 

This will return a response similar to the one below.

{
  "entry": {
    "createdAt": "2017-02-24T10:16:21.524+0000",
    "site": {
      "visibility": "MODERATED",
      "guid": "46b6504d-27e9-4137-b680-fb0be986942d",
      "description": "Moderated site created for blog post",
      "id": "moderatedSite",
      "preset": "site-dashboard",
      "title": "Moderated Site"
    },
    "id": "moderatedSite",
    "message": "I would like to join this site as it looks interesting"
  }
}

 

The response is similar to the one we got when joining the public site with one notable exception, there is no role property, this is because you haven't actually joined the site yet, your request has been sent to the site managers for approval.

 

To check your pending site membership requests you can GET http://localhost:8080/alfresco/api/-default-/public/alfresco/versions/1/people/test2/site-membership-requests (9th request in the Postman collection). You can manage your site membership requests using the /people/test2/site-membership-requests/{siteId} endpoint, refer to the API Explorer for details.

Site managers can not currently accept or reject site invitations via the /sites API, this has to be done via the workflow API, I've added a story to our backlog to add this missing functionality.

 

Now we're a member of the public site let's see who else is. If you GET http://localhost:8080/alfresco/api/-default-/public/alfresco/versions/1/sites/publicSite/members (10th request in the Postman collection) you'll get the following response.

{
  "list": {
    "pagination": {
      "count": 2,
      "hasMoreItems": false,
      "skipCount": 0,
      "maxItems": 100
    },
    "entries": [
      {
        "entry": {
          "role": "SiteManager",
          "person": {
            "firstName": "Test",
            "lastName": "User",
            "emailNotificationsEnabled": true,
            "company": {
             
            },
            "id": "test",
            "enabled": true,
            "email": "test@alfresco.com"
          },
          "id": "test"
        }
      },
      {
        "entry": {
          "role": "SiteConsumer",
          "person": {
            "firstName": "Test",
            "lastName": "User2",
            "emailNotificationsEnabled": true,
            "company": {
             
            },
            "id": "test2",
            "enabled": true,
            "email": "test2@alfresco.com"
          },
          "id": "test2"
        }
      }
    ]
  }
}

 

This shows that the "test" user is the site manager (lines 12 and 20) and the "test2" user is a site consumer (lines 29 and 37).

 

To see all the sites you are a member of the http://localhost:8080/alfresco/api/-default-/public/alfresco/versions/1/people/test2/sites endpoint can be used (11th request in the Postman collection), this will give the following response.

{
  "list": {
    "pagination": {
      "count": 1,
      "hasMoreItems": false,
      "totalItems": 1,
      "skipCount": 0,
      "maxItems": 100
    },
    "entries": [
      {
        "entry": {
          "site": {
            "role": "SiteConsumer",
            "visibility": "PUBLIC",
            "guid": "69a5a7b1-a338-4e11-8a61-115edd1190e6",
            "description": "Public site created for blog post - part 8",
            "id": "publicSite",
            "preset": "site-dashboard",
            "title": "Public Site"
          },
          "role": "SiteConsumer",
          "guid": "69a5a7b1-a338-4e11-8a61-115edd1190e6",
          "id": "publicSite"
        }
      }
    ]
  }
}

 

As our request to join the moderated site has not been approved yet we are only a member of one site, the public site we joined earlier.

 

So how do you find sites to join? 

 

To list all public and moderated sites in the system the http://localhost:8080/alfresco/api/-default-/public/alfresco/versions/1/sites endpoint can be used (12th request in the Postman collection), this will return the following response.

{
  "list": {
    "pagination": {
      "count": 3,
      "hasMoreItems": false,
      "totalItems": 3,
      "skipCount": 0,
      "maxItems": 100
    },
    "entries": [
      {
        "entry": {
          "visibility": "MODERATED",
          "guid": "46b6504d-27e9-4137-b680-fb0be986942d",
          "description": "Moderated site created for blog post",
          "id": "moderatedSite",
          "preset": "site-dashboard",
          "title": "Moderated Site"
        }
      },
      {
        "entry": {
          "role": "SiteConsumer",
          "visibility": "PUBLIC",
          "guid": "69a5a7b1-a338-4e11-8a61-115edd1190e6",
          "description": "Public site created for blog post - part 8",
          "id": "publicSite",
          "preset": "site-dashboard",
          "title": "Public Site"
        }
      },
      {
        "entry": {
          "visibility": "PUBLIC",
          "guid": "b4cff62a-664d-4d45-9302-98723eac1319",
          "description": "This is a Sample Alfresco Team site.",
          "id": "swsdp",
          "preset": "site-dashboard",
          "title": "Sample: Web Site Design Project"
        }
      }
    ]
  }
}

 

If you are a member of any of the sites your role in that site is indicated (line 23). The other way to find sites is to search for them and there are a couple of ways to do that. You could use the new Search API which I'll be covering in the next post or you can use the Queries API. We'll also be covering the new Queries API in a future post so I'll just briefly mention it now.

 

The /queries/sites endpoint is "pre-canned" query for sites, you pass a single term as a query parameter. For example, calling http://localhost:8080/alfresco/api/-default-/public/alfresco/versions/1/queries/sites?term=public will return a response similar to the one below (13th request in the Postman collection).

{
  "list": {
    "pagination": {
      "count": 1,
      "hasMoreItems": false,
      "totalItems": 1,
      "skipCount": 0,
      "maxItems": 100
    },
    "entries": [
      {
        "entry": {
          "role": "SiteConsumer",
          "visibility": "PUBLIC",
          "guid": "69a5a7b1-a338-4e11-8a61-115edd1190e6",
          "description": "Public site created for blog post - part 8",
          "id": "publicSite",
          "preset": "site-dashboard",
          "title": "Public Site"
        }
      }
    ]
  }
}

 

The last thing to cover in this section is how to leave a site you've previously joined. As you might expect a DELETE endpoint is used to do this. To leave the "publicSite" we joined earlier use http://localhost:8080/alfresco/api/-default-/public/alfresco/versions/1/people/test2/sites/publicSite (14th request in the Postman collection). A 204 response is returned if you successfully left the site.

 

For the last section of this post we're going to take a look at some of the other endpoints available to the site manager. 

 

A manager of a site is able to add members with a specific role. To add "test2" as a member of the "publicSite" created earlier with the "SiteContributor" role we can POST the following body to http://localhost:8080/alfresco/api/-default-/public/alfresco/versions/1/sites/publicSite/members. Remember to switch your credentials back to the "test" user or use the 15th request in the Postman collection.

{
  "id": "test2",
  "role": "SiteContributor"
}

Allowable values for the role property are SiteManager, SiteCollaborator, SiteContributor or SiteConsumer

 

Now we've added test2 to the site let's say we want to change their role to be a site manager, this can be accomplished by PUTing the following body to http://localhost:8080/alfresco/api/-default-/public/alfresco/versions/1/sites/publicSite/members/test2 (16th request in the Postman collection).

{
  "role": "SiteManager"
}

 

Finally, to remove the "publicSite" site use a DELETE request against http://localhost:8080/alfresco/api/-default-/public/alfresco/versions/1/sites/publicSite (last request in the Postman collection), you should receive a 204 status code. 

 

We've covered a majority of the Sites API in this post but there is more so I'd encourage you to examine the API Explorer and experiment.

 

In the next instalment of the series we're going to take a look at the new queries and search APIs.

User Assistance at Alfresco

Posted by ahealey Feb 9, 2017

If you’re reading this blog then chances are you know about docs.alfresco.com, where the official Alfresco help and documentation is available. Everything you read (or watch) there is created by Alfresco’s User Assistance (UA) Team, who are based out of the Engineering headquarters in the UK.

 

Do I keep reading? Is this going to be interesting?

You'd better believe it!
We’ve got news of career opportunities at Alfresco, plus details of how we’re looking for more community involvement.

 

What is UA at Alfresco?

The UA team are the conduit between an engineer’s brain, and the people who use Alfresco software. We take something complicated, and explain it in terms that can be easily understood.

 

We work on everything that Alfresco produces, with every single user type in mind. Whether you’re an end-user of Alfresco Mobile looking for help on the go, or a seasoned Alfresco developer using Aikau and looking for the latest Share extensions, the UA team are here to help.

 

Things we do

 

Who we are

The Alfresco UA Team is managed by Helen Mullally, who with 8 years under her belt is an Alfresco old-hand. Whilst we aim to be as T-shaped and cross-skilled as possible, naturally we each have our own strengths. So one person will lead or specialise on videos, another on API docs. It’s not exclusive though, I might work on videos one day and API docs the next.

 

How we work

Each product development team at Alfresco has a member of the UA team embedded into it. (Each team is made up of engineering and QA, a product manager (PM), a scrum master (SM), a member of the UX team, and us). The UA representative attends team standups, sprint reviews and retros. This means that we’re able to write in parallel with development and release documentation in parallel with products.

 

With UX and the PMs we define both the UI copy and any in-product help that’s required. This way of working means that not only is the writing in Alfresco products clear and consistent, but also that we can take advantage of findings from user research to address actual user scenarios in the online help.  

We do use Alfresco ourselves, to store, manage, and publish all of our content, with a publishing tool built on top of Alfresco called Componize.

 

Do you interact with the Alfresco community?

The honest answer is probably not as much as we should. Last year we took part in a Tech Talk Live with Richard Esplin, and have spoken in the past at Alfresco Summit. This year we intend to become more active within the community, and will be attending Beecon in April.

 

We do regularly check and occasionally contribute to the Alfresco forums, and we receive regular feedback from the feedback form in the online help, some of it good, some of it brutally honest. All feedback is great and helps us to improve.

 

Can the community contribute to the docs?

We haven’t opened up the documents for comments as this can be a nightmare to sort the good from the bad from the spam. It’s something we’re always considering though, so maybe in future. For now, you can use the feedback form mentioned above to suggest improvements to the documentation. We read every single piece of feedback and have had some good exchanges with people who’ve contacted us this way. You can also raise an ALF Jira ticket using the "Documentation" component.

 

Andddd… (drumroll)… coming soon we’re going to be running a program for user-created videos.

 

We’ll be inviting you to create your own Alfresco help videos using our templates – the best of these we’ll make available on docs.alfresco.com and our YouTube channel. Watch out for the announcement here and on Twitter later this year.

 

We’re hiring!

The team is currently growing to keep up with the expanding product development teams. If you’re technically-minded, want to help out other Alfresco users, and can put your ideas into words then get in touch. You don’t need to have a tech writing or user assistance background. We’re also looking for super-technical Alfresco developers who have a flair for writing. Maybe you have a background in social media, content marketing or article writing.

 

Take a look the two job descriptions, and if you think you're a match then get in touch.

Technical Writer

Technical Writer (API/Developer Documentation)

 

These roles will be mainly based out of our Maidenhead headquarters and you’ll need to be authorized to work in the UK.

 

 

If you want to find out more then you can contact the UA Team at docs@alfresco.com.

Introduction

I've recently been writing some custom clients in order to test out the V1 REST APIs that are available in the 5.2 Alfresco releases in order to provide feedback to the team on areas that can be improved. I've been experimenting with various different UI libraries and frameworks including Vue.js, Aurelia and Angular and have most recently been working with React. When developing anything I always try to follow good coding practices and as such have tried to make the various components that I've built as reusable as possible and have stumbled upon an interesting approach (described in this post) to application composition.

 

Pre-Requisites

The project is ECM only at the moment so you just need a 5.2 Alfresco Repository (there is no need for enabling CORS, you just need to have the repository started and running locally on port 8080). You'll also need to have Node.js (at least version 6) and NPM (at least version 3) installed. You need to use Chrome (it's only a proof-of-concept so I've not yet included some polyfills that are required for other browsers).

 

Setup

Getting everything up and running should only take a couple of minutes. You just need to follow these simple steps:

  1. Download or clone the GitHub repository
  2. Open a terminal in the project directory
  3. Run "npm install"
  4. Run "npm start"
  5. A new browser tab or window should open at http://localhost:3000 showing the following login page.

A screenshot showing the login page

 

The Client

You should be able to gain access to the application by entering valid user credentials for the Alfresco Repository. I'm constantly adding new pages to test out as many of the REST APIs as possible but at the time of writing you should find pages (or "screens" - it is a single page application) for:

 

  • node browsing (table view with drag-and-drop upload)
  • node browsing (film strip view)
  • node details page (accessed by double-clicking on a file name in the table view of nodes)
  • user browsing
  • site browsing
  • tag browsing

 

A screenshot showing the node browser with table view

 

I've intentionally not spent time polishing the design of the client. It is using Material Design Lite to give some basic styling but for the most part I've not done much to any additional styling (for example the upload dialog just shows an overall percentage as a number rather than showing the progress of each individual upload as a progress bar). 

 

The Code

Import the project into your IDE of choice (my preference is Sublime Text 3) and if possible try to ensure that it has appropriate syntax highlighting for JSX (I've used the Babel Sublime plugin for example).

 

The entry point to the client is src/index.js. This file defines the "routes" for the client:

render((
   <Router history={browserHistory}>
      <Route path="login" component={Login} />
      <Route path="/" component={MainLayout} onEnter={requireAuth}>
         <IndexRoute component={Nodes} onEnter={requireAuth} />
         <Route path="nodes" component={Nodes} onEnter={requireAuth} />
         <Route path="users" component={Users} onEnter={requireAuth} />
         <Route path="filmstrip" component={FilmStrip} onEnter={requireAuth} />
         <Route path="sites" component={Sites} onEnter={requireAuth} />
         <Route path="tags" component={Tags} onEnter={requireAuth} />
         <Route path="node/:id" component={NodeDetails} onEnter={requireAuth} />
      </Route>
   </Router>
), document.getElementById('root'))

 

If you wish to add your own route into the client then this is where you should do it. Each route is a React component and you can find the existing route components in the src/routes folder. Create a new file (i.e. "MyRoute.js") for your own route in this folder and then import it in the index.js file:

import MyRoute from "./routes/MyRoute";

...you can then add it as a new client route by inserting it as a new child of the MainLayout route

<Route path="myroute" component={MyRoute} onEnter={requireAuth} />

(note the use of requireAuth to ensure that only logged in users can access the route).

 

Finally you'll want to add a link to your new page into the navigation drawer. This can be done by editing the src/routes/MainLayout.js file that contains the component that defines the layout for the application:

<Drawer title="Links">
   <a className="mdl-navigation__link" href="/nodes">Nodes</a>
   <a className="mdl-navigation__link" href="/users">Users</a>
   <a className="mdl-navigation__link" href="/filmstrip">Filmstrip</a>
   <a className="mdl-navigation__link" href="/sites">Sites</a>
   <a className="mdl-navigation__link" href="/tags">Tags</a>
   <a className="mdl-navigation__link" href="/myroute">My route</a>
</Drawer>

Now add the source code into MyRoute.js to define the component for your new route:

import React from "react";
import Content from "../components/layouts/Content";

const MyRoute = React.createClass({
   render() {
      return (
         <Content>Hello World</Content>
      );
   }
})

export default MyRoute;

Each time you save a file the application should hot-reload so you should see the new link in the drawer:

Screenshot showing the new link in the drawer

...and when you click the link it will take you to the new route..

Screenshot showing the new route

 

Composing Your Route

The render function in the MyRoute component is one of the React Component lifecycle functions and returns JSX. The great thing about this is that it is possible to mix-and-max JavaScript, HTML and other React Components. This allows you to compose the content of your route in much the same way as you'd write a standard HTML page. 

 

The components that are currently available in the repository have been written to be as re-usable and as flexible as possible. The components can be divided into container and presentation components where the container components are responsible for retrieving and setting data on the Alfresco Repository (via the V1 REST APIs) and setting state that is pushed down through the nested presentation components. 

 

Whilst state is pushed down to presentation components I've taken the approach to use custom native DOM events to bubble actions back up from those presentation components to the container components. This is a slightly different approach than the suggested approach of passing callbacks as properties but does avoid the problem of "drilling holes" to reach deeply nested components.

 

In practice this means that a presentation component can always communicate with its containing component no matter how deeply it is nested. It also means that the components in between the container and the deeply nested presentation component do not need to be involved or have any awareness of that communication.

 

The Collection Component

The starting point of many a client is in showing a collection of something... nodes, users, sites, search results, etc. The great thing about the new REST APIs is that they provide a completely consistent way of requesting and receiving data. This means that the same collection component (components/containers/Collection) can be used for any GET REST API that returns a list of items. It also means that you can use the same pagination controls component (components/controls/Pagination) to control the page size and what page of available data is displayed. Common events are defined and exported from the components/containers/Collection.js file that can be emitted by any component nested within a collection to handle:

 

  • new item creation
  • existing item updates
  • reordering of data (field and/or direction)
  • filtering
  • navigation and relative path setting
  • updating page size
  • changing the displayed page

 

So whether you want to show nodes, users, tags, favourites, sites, whatever you can use the same component.

 

Single Responsibility Principle

The collection component follows the single responsibility principle in that it is only responsible for retrieving data and it does not deal with how that data is displayed. Instead it handles off that responsibility to other components that can be nested anywhere inside it. This means that the view of the data is completely customizable.

 

At the time of writing I've provided 3 different data views:

 

  • A table view (components/views/TableView) that relies on nested components to define the structure of that table
  • A table view of user data (components/views/UserTableView) that is a component composed of a mixture of HTML and other components
  • A carousel view (components/views/Carousel) that relies on nested components to define how each item in the carousel is displayed.

 

...and you can of course both provide entirely new views or nest existing or custom components within those view components to construct any view that you want with complete freedom.  For example compare this example in the sites route:

<Collection url="/api/-default-/public/alfresco/versions/1/sites" relations="containers,members">
   <TableView>

      <TableViewHead>
         <TableHeading label="ID" />
         <TableHeading label="Name" />
         <TableHeading label="Actions" />
      </TableViewHead>

      <TableViewBody>
         <TableCell property="id"/>
         <TableCell property="title"/>
         <TableCell>
            <Delete url="/api/-default-/public/alfresco/versions/1/sites"></Delete>
         </TableCell>

      </TableViewBody>
     
      <TableViewFoot>
         <TableCell colspan="3" >
            <Pagination />
         </TableCell>
      </TableViewFoot>

   </TableView>
</Collection>

 

...with this on in the filmstrip route:

<Collection url="/api/-default-/public/alfresco/versions/1/nodes/-root-/children" 
            orderBy="name"
            include="properties">

     
   <BreadcrumbTrail/>

   <Carousel frameHeight="300px">
      <Property property="name" navigation={true}></Property>
      <Thumbnail renditionId="imgpreview"></Thumbnail>
   </Carousel>
  
</Collection>

 

Note how the same collection component is used (configured with different URLs to access different data) but completely different components are used to compose how the data is displayed.

 

Custom Rendering and Extension

It's also worth noting in the sites example how a TableCell can easily be used to either render a property of an item or it can simply nest another component like the Delete component to render something completely different (in this case a delete action that prompts for confirmation). It's also worth noting that the exact same Delete component can be used for deleting any item from any collection because of the consistent way in which the REST APIs now handle DELETE operations.

 

In the Carousel example you'll see that the name of the node is displayed using the Property component. This component could just as easily have been nested inside a TableCell and in fact both components extend the abstract Render component. This is just one example of how it is possible to reuse existing capabilities by extending an existing component. The means that when it is not possible to render data as you'd prefer you can simply create your own component (and optionally choose to extend Renderer if appropriate) and then nest it anywhere within your view.

 

Hierarchical Freedom

The components are written in such a way that you are completely free to compose them as you wish. For example in the routes/Nodes component you'll see that the TableView is nested within an UploadTarget component. The UploadTarget component provides a target area for dragging-and-dropping files from the operating system to upload into the Alfresco Repository. The key thing here is that it does not need to be nested within a Collection and the Collection does not need to nest it.

 

You could just add an UploadTarget anywhere on the page so that files dragged-and-dropped onto any of the nested components will be uploaded to the configured location in the Alfresco Repository (you should note that for convenience the url property will be inherited from a parent unless specifically provided). 

 

This freedom also means that it's possible to include BreadcrumbTrail components and Toolbar components into the Collection without any problems - but the benefit is that they can influence the Collection (for example to change the relative path or refresh the list when a new folder is created) by simply emitting on of the registered custom events.

 

Documentation

I've made an attempt to provide documentation for some of the components using JSDoc. You can build this documentation locally by running:

npm run generate-docs

...and you can then browse the documentation by opening the docs/index.html file in a browser. 

Filter Blog

By date: By tag: