0



15Dec2012

Please stop using libraries and learn the tags!

In the  projects I have worked in the latest two years, a pattern emerged: developers were developing using libraries of code but  not using directly fatwire tags.  So, instead of using fatwire tags, they were calling all the time some "elements".

That is puzzling. Why they do this way? Why they use those libraries instead of just LEARNING THE CODING OF THE PRODUCT? There is no real advantage of using those libraries. A lot of code is needed to pass the parameters, other code is required to read the result, and overall it is more complex than just using the fatwire tags in the first place. What is worse, fatwire tags are documented. Those libraries are usually NOT.

I suspect this is a common pattern because implementers follow directions from someone that is providing the library. However, the library that they use is very often (I would say always) much worse than using directly the fatwire API. This is because Fatwire does not really provide features to write libraries in templates. They should code custom tags, instead. Something very rarely done.

I know that Fatwire API is somewhat confusing; for example having to extract each attribute before rendering it looks to be too much effort. But this is not an excuse for avoiding to learn it.

For example to render an attribute of an asset, an assetset:getmultiplevalues and then a ics:listget it is all that is needed to render an attribute.

 

It is shorter than calling the "getpageattributes" call I have seen too many times.

Real code I saw yesterday do:

  • collect a number of parameters
  • calling the element that extracts ALL the attributes and store in an hashmap
  • retrieve the hashmap
  • extract the values in java variables
  • sometimes bring back those variables in ics variables
  • add a lot of checks for null values

But using a library can generate be much worse results than this.

I have see in a project developers calling all the time a library that was extracting the attributes filtered by date. EVEN FOR NON DATE SENSITIVE FILTERED ATTRIBUTES.

So the coders, instead of just extracting the attributes they were needing, did some dirty trick with variables to simulate a different time range and disable the filtering when it was not needed. An extreme case of total ignorance of the enviroment they are working in. Code 10 times more complex totally unreadable and filled with hack and tricks.

So I feel to give a big warning to all the Fatwire Customers (and I know many of them  read my blog and listen to me): check that the developers knows Fatwire coding. It is not that hard. Below there is a list of questions developers will have to know the answers (without the answers... so developers that will try to be prepared for my test will have to learn).

Unfortunately many indians and chinese companies have this bad habit: since they cannot find the developers with the proper skills, they throw in the team generic java and jsp developers, and instead of providing training, they put some team leader that provides a library. Then they (regularly) lose the team leader and the developers are left hacking the library without never learning the enviroment.

Simple Test: do you know enough of fatwire for coding?

  • What is an IList?
  • How do you extract fields os an IList?
  • How do you loop an IList?
  • How do you load a basic asset?
  • How do you extract fields from a basic asset?
  • How do you load a flex asset?
  • How do you load attributes of flex assets?
  • How do you read a single value?
  • How do you read multiple values of an attribute?
  • What you get when an attribute is a blob?
  • What you get when an attribute is an asset?
  • What is the impact on the cache using a calltemplate?
  • What is the impact on the cache using searches with search state?

 

Posted by msciab
15Dec2012