Extend Share Document Library Browse Folder Template

[davidbalt]

I've tried posting this question posed a different way, and got no response.  I'll try to reframe the question to see if Jeff Potts or somebody else can point me in the right direction.

I've extended the folder model with custom metadata - specifically, "wiki content" as a custom model called custom:wikifolder.  I've already figured out how to get the new metadata field to show up on the folder details page, and I've even gotten it to show a wysiwyg editor to add rich content into the metadata field, again on the folder details page.  However, what I really want to do is show the metadata in the document library while browsing for files; if a folder has wiki content metadata, that content will be shown above the file list in the browse view.

I have figured out a partial solution using a third party extension, but I don't think it's working well enough as I'm having some other problems with it, and I'd rather use vanilla Alfresco without having to resort to an extension.

If I want to add this metadata to the Document Library while browsing, I think it needs to go into the "toolbar" @region of the documentlibrary template.  So I think if I create a "component", I should be able to register it to place it's content into the "toolbar" region.  Probably this component will have to have ajax files with it to render the region after each browse event, but I'm not sure what is needed and how it needs to be structured.  Or is there another way?  I would like to keep the solution purely to xml and FTL/HTML/Javascript, no Java if possible.

I want to show the metadata in the documentlibrary (#1) ONLY when the folder is of type custom:wikifolder, (#2) with inline editing capabilities , (#3) using the same/largely the same javascript files that the Wiki module uses.  I might be able to work out #3 on my own as that is more my expertise than all of these XML configuration files per se.

I'm hoping somebody can tell me the right way to do this.  I've gotten tantalizingly close, got the data structured right I think, but working with the template system / regions / etc is proving extremely difficult.

[ddraper]

Have you seen this blog post? http://blogs.alfresco.com/wp/developer/2011/09/02/auto-readme-extension-example/

Although the example is looking for a specific file in the currently rendered DocLib folder, I think it is essentially doing something similar to what you want (i.e. to show some additional information in certain circumstances - in your case it would be if the folder is of your new custom type). You should be able to re-use some of the existing Alfresco wiki based JavaScript resources for editing.

[davidbalt]

I had not seen that before, but unfortunately there are a few things about that linked post that seem problematic.  First, that approach uses the .head.ftl method of templating, which I think is deprecated now.  I've had issues getting some of the FTL macros to work in my experiments, I believe those macros are supposed to make .head.ftl obsolete.

The other issue is that there is no source code for that example, apparently having been lost between versions of the developer blog site.  The critical piece is to understand how the template region is modified IFF the content type matches; or in the case of the example, IFF there is a file called Readme.txt in the same directory.

Nevertheless, the link has been helpful in laying out the right approach, so thank you!

[ddraper]

No problem, you're right - I'd forgotten about the source being lost - apologies. You're also right about the .head.ftl being deprecated, however the principles are the same except they dependencies are just moved into the .html.ftl file. I was trying to show how you can inject a new Component fairly easily into an existing page so that you can work with a new WebScript at which point you're free to do pretty much whatever you'd like. Here are a couple of other posts that may be useful for adding and customizing content:

http://blogs.alfresco.com/wp/developer/2011/07/22/how-to-add-content-to-an-alfresco-share-page/
http://blogs.alfresco.com/wp/developer/2012/05/22/customizing-share-javascript-widget-instantiation-... (first in a series of 4)

[davidbalt]

Thank you for your help so far, Dave.  I will read your blog entries carefully.  I think I am quite close to eliminating the need for the third party extension, and getting the content to show up.  Do you have any thoughts on the best way (once I get the content showing up correctly) to bring in the Share Wiki component's WYSIWYG edit/save functionality to my customization?  I'd like to reuse as much as possible, but I'm just storing one field of string metadata, so I don't need versions, or author information, or any of that.  Just a nice WYSIWYG (with the Link to Document and Insert Image functions that are Alfresco Specific) and the ability to edit/save.  How much reinvention of the wheel might I have to do? Or can you think of a better approach? And thanks again for your help and attention.

[davidbalt]

Dave,

It seems like most implementations of share customizations that load content into a region of the template do so using a webscript and arguments coming from the Browser to request a particular file or node; for example I don't have your ReadMe.txt javascript to reference, but I imagine you implemented that using a onFilterChanged event listener and a webscript backend to check for the existence of a readme.txt file in a given path, where the path was provided as an argument to the webscript.  Is this the only/preferred design pattern for this sort of thing?  It seems circuitous; is there a way to determine the current path/nodeRef within the template as it's loaded into a given region of the documentLibrary?

Is there any kind of server-side state (in the session or something?) that would point to the current path or node?

[ddraper]

Share is stateless by design (the only state that is maintained is the session token used for authentication on REST calls back to the Alfresco repository). Some of the widgets on the Document Library page (e.g. the Alfresco.DocumentList) do store the root node information when the page is loaded, but as you change the filters you are requesting different content via an XHR request so any node state on the server would be changing anyway. On other pages where the display is more "static" (e.g. the document-details page) the nodeRef is passed as a request parameter and passed to the Share-tier WebScript but a REST call is still made to the Repository-tier to retrieve the actual node metadata.

…so I guess the short answer is, no - there's nothing in the session detailing the current node.

[zoe]

Hi David,

I want to do something very similar to what you were trying for.  I also took a look at the auto-readme example and was really hopeful that it would help explain what needs to be done, but given how out of date it was I cannot get it to work.  Did you ever get something like this implemented?  Would it be at all possible for you to post or send your source code so I could see how you did it?

Thanks for any help!

[davidbalt]

Yes, as a matter of fact, I did end up developing something.  It's imperfect, I'm hoping to do another version in the next couple of months (client-willing).  Hope your project went well.

[davidbalt]

I've begun redesigning / refactoring this project.  Curious if you got anywhere with it?