Some observations

[smcardle]

Hi All.

I have been doing some customisations to the Share 4.1 interface so that various pages of Share are able to be included in iframes my customers application.

1. The first thing was to hide the header and footer on every page : This went well using the module extension mechanism and as both components are global every page has the desired affect.
2. The next task was hide the title bars on the pages : This wasn't so easy as the titles region-id and source-id changes depending on what page is displayed and the scope is template.
Suggestion for improvement : Wrap the individual title bars in a global scope title component which uses the actual individual titles as sub components. This would enable the ability to turn off all title bars in a single module element at global scope. Or continue to allow hiding individual page titles if required. It's a pain to go to each page, enable surfBug to identify the id's and scope then add the individual module entries before redeploying and re-trying.
3. On the repository view I need to hide the navigation options on the left, such as the filter, tree, category and tags. The reason for this is that the 3rd party application issues a full URL for the iframe to a repository directory such as http://chma-qa115:8080/share/page/repository#filter=path|%2FClients%2F122261. The client app knows the client ID and documents for that client are stored here. Once this is shown, the user must only be allowed to navigate further down the tree but no further up the tree than this entry point, thus the left hand side options are irrelevant.
There are several problems I need to overcome here.
   a. If I hide all of the individual components on the left hand side, the tools menu no longer displays "Create Content…", "New Folder", "Upload" or "Selected Items…". However, the breadcrumbs icon and RSS feed icon are still visible.
   b. Selecting the breadcrumbs icon enables and disables the breadcrumbs bar but no breadcrumbs are shown.
It seems that hiding the "Categories" component causes this affect as if it's the only non hidden component the tools bar and breadcrumbs works - with the following exception. The breadcrumbs first element is show as "root.node".
   c. The bread crumbs are not real breadcrumbs in the same sense as "Hansel & Gretel". This should not show the path to the current item in the repository, but should rather show how I got here. As I got here directly via a URL the root node at this stage should be the current node and only navigating down the visible hierarchy should drop breadcrumbs to allow the user to navigate back. The current breadcrumbs implementation shows the whole path back to the root of the repository and allows my users to navigate out of the hierarchy they should be constrained to.

Suggested improvement : Wrap all components that are used on a left hand side navigation such as in the repository view or the my-tasks view in a navigation component that can be hidden at page scope, then wrap this in a navigation component that can be hidden at a global scope. Change the  breadcrumb implementation, or at least allow it to be easily changed to a proper breadcrumb implementation rather than just a path to the currently visible repository item.


Regards

Steve

[ddraper]

Hi Steve,

Thanks for the feedback - it's very much appreciated. It's worth bearing in mind the historical context when considering customizations… when Share was originally written it wasn't done with consideration to the customizations that are now possible through the module extension mechanism (in fact we had to retrofit this capability into Surf to make it possible). That said, your points are valid - we do need to continue to make it easier to customize Share and use-cases such as those that you've provided are very helpful to us.

We are looking at lots of ways in which we can address these sorts of issue in future releases, but its unlikely the specific changes that you're suggesting will make it into a service pack - your best bet is to raise improvement tickets in JIRA and hope they get prioritized. Hopefully some of the changes that are going into the main community source branch will begin to help make some of the customizations that you wish to make easier (by providing the ability to more easily extend the client-side JavaScript widgets and make more fine-grained changed). We'll also hopefully be making further improvements further down the line so that even this isn't a necessary step.

With regards to you concern over breadcrumbs … if they were not placed within the context of the Document List then I would probably agree with you (i.e. if they were in the title bar say)… but they are breadcrumbs in the context of the repository view that you are browsing (in fact they are more like a path location than breadcrumbs).

Regards,
Dave

[smcardle]

Thanks Dave

I completely agree that the breadcrumbs are implemented more in the context of a path to the currently displayed repository location rather than real breadcrumbs. Anyway, we intend to make some changes here to enable real breadcrumb functionality as it's pretty much a requirement in our use cases at the moment, and I'll be happy to contribute this back to the code base or as an extention module when finished.

The other issues are more in the "it's annoying" catagory and I expect we'll need to address these as well, possibly sooner than later, again to meet our user requirements. I suspect we'll gloss over these issues in the short term until they become more of a priority once the users start to complain or raise issues with the functionality.

None of this is in anyway a critisism of Share, we're big fans of Alfresco and we would like to get more involved with the future modualisation efforts going forward.

We have some BIG plans for Share customisations that we're working on and will mostly try to approach these using AOP rather than code changes if custom modules can not do the job in the short term. One such product we're working on is a Drop Box replacement called eDrive which uses the Novel iFolder clients as front ends and transforms the SOAP calls into CMIS web service calls so we can use Alfresco as the content store instead of the Novel Enterprise Servers. This will be a core touch point for our "Office Assistant" product and will provide features we are unable to realise using Drop Box or Google Drive.

What we will probably do in the future is raise JIRA tickets and provide Aspects that meet out needs, or use cases, then hopefully you guys will change the code base in future releases and we can remove our Aspects


Regards

Steve

[andy2_0]

This is very useful… thanks for contribution!