Wednesday, January 28, 2015

Huge datalists in Alfresco, yes you can (now)

Novem-IT, novem-it.dk presentation of enhancement to extended datalist module allowing huge datalists in excess of 100000

We do not know where the limit is .. The enhancement of the search could be a candidate for improving the search interface.

The magic is really an implementation of a count-query, that is the ability to perform an unlimited search returning no rows/results, but the number of matching nodes found (not returned nodes). Since we then know the total size of the query, the real data query need only do skip and fetch a single page (~50 nodes). SOLR4 performs super doing this, returning page results for given page in 0,4 seconds for webscript response with datalist size of 140000!


Thursday, January 22, 2015

Performance of new Aikau DocumentLibrary (5.0.c version)

The new Aikau 'framework' is very promising, I tested the new Documentlibrary, and found it to be very functional with some functions not working and with some performance problems on the client-side (approx. 2x on my machine), due to many dojo scope initializations (hitch function)





New Feautures seem to be:
- smother look and feel  and details in the presentation making it nicer to the eye
- paging is now added on top


Performance wise, here is the main cause:
.cache["dojo/_base/lang"]/</a.hitch

Calls:      3838        
Procent: 81.57%   
Time:      58090.815ms    

This is probably improved in Alfresco HEAD. A resolve could be to make bigger components / less reuse?




































Monday, January 19, 2015

contributed to extended datalists community module

as part of work for a customer we have done work on the https://github.com/deas/fme-alfresco-extdl extedned datalists module adding:
  • Paging
  • sorting across filter changes
  • fix filters not working
  • performance enhanced
Tested on Alfresco community 4.2.f

This way Novem-IT and our customer can contribute and gain from common future development on the module.

Work was done on this fork https://github.com/tass01024/fme-alfresco-extdl and awaiting a pull request to the main site.

started at Novem-IT

Thanks for a great time to Redpill-Linpro http://www.redpill-linpro.com, welcome to new experiences at Novem-IT http://www.novem-it.dk. Will continue work on Alfresco & Mule ESB, if the world does not pull me away :)

Thursday, October 30, 2014

Reindex in SOLR4 in Alfresco

In Alfresco 5.0.b har been introduced which has a different (better!) SOLR folder layout. It is slightly different, so to reindex a SOLR4 instance in Alfresco 5.0.b. You should delete or move alf_data/solr4/*. This takes care of cached content nodes, models, and index.

SOLR data/indexes
<ALF_DATA>/solr4 or normally <ALFRESCO_HOME>/alf_data/solr4


BTW SOLR4 configuration is now in alfresco root <ALFRESCO_HOME>/solr4

Wednesday, October 22, 2014

Faceted forms - form based on node state (metadata)

A nice thing about Alfresco Share is that, you get a lot of functionality for free and it is very adaptable. But often you want more client-side adaptability and the first think that comes into mind is client-side Javascript. To avoid client-side javascript customization on Share I made a special form evaluator, which gives you the power to have different forms for the same node type, depending on the state/metadata values.

Normally you define a node type form for view and edit of existing nodes:

 <config evaluator="node-type" condition="my:nodeType"> ...

This is one time solution for alle nodes of this type and lifecycle. To use a facetted approach, you could now add form configuration depending on a metadata property, like:

  <config evaluator="facet-node-type" condition="my:nodeType,my:state=open">

and another

  <config evaluator="facet-node-type" condition="my:nodeType,my:state=closed">

This means (given this facet-node-type exists and works :) you should have a resulting form configuration of the 'node-type' and one 'facet-node-type' given your node either have state 'open' or 'closed'

This evaluation is done Share-server-side, so the state (my:state) should preferable be read-only in the resulting forms.

In my example we could have a text field for an 'open' node and none for a 'closed' on.

To make this work we need to define the 'facet-node-type' in the form-config xml

<alfresco-config>
  <plug-ins>
    <evaluators>
      <evaluator id="facet-node-type" class="com.redpill-linpro.alfresco.web.config.forms.FacetNodeTypeEvaluator" />
       </evaluators>
  </plug-ins>

...

and mainly the java code Source FacetNodeTypeEvaluator.java

Finally lets show the full 'condition' definition available:

General format

condition="<node-type>,<property-evals>"

Where <node-type> is the prefix-nodetype  like in the standard node-type evaluator ...

Where <property-evals> is of the format:

 <property-eval>[,<property-eval>]*

And <property-eval> is of the format

<property-name>=<property-value>[|<property-value>]*


So I could write the following to select only 'my:node-type' nodes with 'my:state' 'open' or 'closed' and 'my:color' set to 'blue'

condition="my:nodeType,my:state=open|closed,my:color=blue"

This can be used to have a form definition where one-large common form (section) is defined and various small modifications of this is in facet-node-type sections depending on the metadata of the node.








Friday, September 19, 2014

Maven problems in 4.2.e-f and 4.20

I you need access to some java classes in a Alfresco Maven project it might give you problems with an artifact which did not get properly inserted into the maven.alfresco.com repository. The issue is also described in various issues, among others: https://issues.alfresco.com/jira/browse/MNT-10118

I solved access to alfresco-repository, alfresco-web-framework-commons, alfresco-remote-api & alfresco-web-client 

Using these dependencies in my Alfresco repo maven pom, where the parent pom used the alfresco platform.

    <dependencies>
        <dependency>
            <groupId>${alfresco.groupId}</groupId>
            <artifactId>alfresco</artifactId>
            <type>war</type>
        </dependency>
        <dependency>
            <groupId>${alfresco.groupId}</groupId>
            <artifactId>alfresco-repository</artifactId>
            <scope>provided</scope>
             <exclusions>
                <exclusion>
                    <groupId>org.alfresco</groupId>
                    <artifactId>alfresco-web-framework-commons</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
         <dependency>
            <groupId>${alfresco.groupId}</groupId>
            <artifactId>alfresco-web-framework-commons</artifactId>
            <scope>provided</scope>
            <version>${alfresco.version}</version>
        </dependency>
       
        <dependency>
            <groupId>${alfresco.groupId}</groupId>
            <artifactId>alfresco-remote-api</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>${alfresco.groupId}</groupId>
            <artifactId>alfresco-web-client</artifactId>
            <scope>provided</scope>
            <exclusions>
                <exclusion>
                    <groupId>org.alfresco</groupId>
                    <artifactId>alfresco-web-framework-commons</artifactId>
                </exclusion>
            </exclusions>
        </dependency>