UGD_Planning

Owned by Michael Vorburger
Last updated: Jul 30, 2013 by Andreas Weigel (Unlicensed)

Content

1st. call  (Mo., 3. June 2013)

Agenda:

  1. Get to know each other
  2. Discuss & understand the aim of project
  3. Create Roadmap

Summery:

In the first call we discussed the project idea in more detail.

The basic idea was enabling users to create MFI specific templates for documents they often need.

As there are more use cases for repeatedly reports like documents (e.g. SMS), we prefer to make this feature a bit more generic.

Typically u have a template (text) containing keys and u provide a map for substitution.

The idea now is to substitute the keys in the template basically depending on the keys.

Example:

U only have to provide a client to substitute the key $client.clientName with the name of the client and the key $client.repaymentSchedules with the requested list.

ToDo:

E-Mail: ask for examples of user generated documents (Michael)

look at existing report tools: http://www.eclipse.org/birt/phoenix/, http://www.pentaho.com/, http://www.crystalreports.com/ (Andreas)

look at Java Introspection API (reflection) (Andreas)

program an example for an template merging a simple placeholder (Andreas)

propose and program a REST API for templates  (Andreas)

 

Notes to myself: setup a blog

2nd. call  (Di., 12. June 2013)

Agenda:

  1. Go through code at github?
  2. Discuss questions below
  3. Plan next step 

Questions:

  1. There are no unit tests at all (?), so i had to set up the test environment. I made an extra testContext.xml 
    because jndi didnt want me to access the datasource. Is that ok? better approach?
  2. What about multitenancy? Do we have to safe the creator?
  3. May i put .metadata to .gitignore? (or why isn't it on the list)
  4. Discuss usage (workflow) of user generated templates

Summary:

After i told about my activities over the past week we tried to focus on the usage of the user generated template

functionality to get an idea, how the interface may look like. By that we figured out, that we thought of different ways

how the service should acquire required data.

My (Andreas) thoughts were to post data to the service. Michael thought of an automatic gaining data approach (e.g. from database).

Actually there are usecases for both possibilities. Thats why we implement both of them.

We decided to declaire an advanced functionality, where u can define keys yourself (requires description where the service should get the resource).

ToDo:

One more try to get realworld examples of user generated documents (Michael)

Define and implement REST interface (Andreas)

Integrationtest for usage (Andreas)

Compare template engines providing introspection-functionality (Andreas)

3rd. call  (Th., 27. June 2013)

Agenda:

  1. Discuss questions below
  2. Plan next step

Querstions:

  1. Which Tempalte Engine?

Summery:

After research and evaluation of Serverside Template Engines we decided to use mustache.java.

It is not only used by twitter and netflix it is also the reimplementation of the mature mustache template language and under active development.

It seperates logic and representation so user can concentrate on a simple syntax while creating templates for e.g. documents.

Compared to other template engines, it does not interfear in the xml/html tags, which allows us to combine a WYSIWYG-Editor for better user experience.

Last but not least it supports reflection, which is an criteria for acceptance.

ToDo:

Dive into mustache.java and start implementing templating functionality.

4th. call  (Mo., 1. July 2013)

We skiped it.

5th. call  (Th., 04. July 2013)

Agenda:

  1. Review current state
  2. Plan next step

Querstions:

  1. Does sample data match mifos?

Summery:

After i didn't get to manage my contribution to github in time, wo could not go through the code.

But we discussed in addition to the basic functionality of replacing template key words with data, 

the usage and API to request the template service.

Further we had a look on the sample data we want to use for a showcase.

ToDo:

Create a concept for usage of  the template engine.

6th. call  (Th., 11. July 2013)

Agenda:

Querstions:

  • None - just discuss status und further steps

Summery:

After Michael made some notes to my code and my proposed usage example, i made some changes and we discussed the example. I renamed 'metadata' to 'mappers' as it is more precise.

Next Michael pointed me to a mistake i made. The approach above saves a specific data, where we actually want a variable. So that we may generate a document for different instances.

More precise: insted of "metadata":{"client":"/api/v1/clients/3"} we change it to {"mappers":"/api/v1/clients/{{clentID}}"} and the user has to send the clientID

So we end up with the new approach:

POST (creates new) TEMPLATE:

curl -X POST -i -H "Accept: application/json" -H "Content-type: application/json" -k --user mifos -d '{"text":"<html><header><title>This is title</title></header><body>Hello {{client.name}}, bye {{sender}}</body></html>","name":"foo","mappers":{"client":"/api/v1/clients/{{url.clientID}}"}}' https://localhost:8443/mifosng-provider/api/v1/templates?tenantIdentifier=default

GET MERGED TEMPLATE (e.g. for template with 3313):

curl  -k --user mifos -X POST -i  -H "Accept: text/html" -H "Content-type: application/json" -d '{"sender":"me", "clientID": 736}' https://localhost:8443/mifosng-provider/api/v1/templates/3313&clientID=736?tenantIdentifier=default

 

Further thoughts (for next versions of feature):

specify in the value of the mappers not only a url, but also what it is and how to get it:

  • "mapper":{"client":"GET JSON /api/v1/clients/{{url.clientID}}"
  • "mapper":{"client" :"GET JSON /api/v1/clients/{{url.clientID}}", "now": "java: new java.util.Date()"}
  • "mapper":{"client" :"java: getClient({{url.clientID}}) }
  • "mapper": {"client":"GET JSON http://{config.crmSystemURL}/api/clients/{{request.clientID}}"}}'

ToDo:

Implement url templating (or more generic, the value of the mappers)

7th. call  (Th., 18. July 2013)

Agenda:

  1. Clarify questions
  2. Discuss further steps

Querstions:

  1. How to avoid SSL problem when getting mappers resource?

Summery:

There are a few possibilities to implement the mapping of keywords with data. For more flexibility we decided to make http request to get the data.

Even for resources from mifos. For development purpose mifos is using a selfsigned certificate, which makes it difficult to make https request from java code.

So for development we discussed ignoring self-signed certificates.  

ToDo:

Implement url templating of mappers

8th. call  (Th., 29. July 2013)

Agenda:

  1. Clarify questions
  2. Discuss futher steps

Querstions:

  1. Basic-Authentication for mapper request?
  2. Talk about tests?
  3. Milestones for second half of gsoc (frontend development)

Summery:

After a demo of the current state, which includes the basic serverside template functionality Michael and me discussed about minor improvments. 

The SSL ignore functionality for dev should be configurable and we want to give something like static methods a try. Which means u could get an 

timestamp on document generation with a tag like {{NOW}}. After that we had a long talk about the usage of the overall functionallity and the start (or entry) point.

There are two basic pages needed. Something like an administration page giving the possibilty to creat templates and perhaps an extra tab at a concrete 

entity to use it. For the second scenario we would have to assign a specific entity to the template. Giving that it would be nice to have all the fields of an entity.

Those metadata would help the administrator to create a template.

As for now there is no API describing the metadata of an entity, so we code it into the ui.

 

Note: Consider custom fields (data tables)

ToDo:

Andreas:

Prepare Demo Document

Catch mappers url and implement condition, if absolute path already exists

E-Mail to Ed regarding google hangout

Implementation of abstraction-layer for template engine to add context

Static {{NOW}} method

Ignore self-signed cert property

Michael:

E-Mail to Ed, Keith regarding information about functional requirements, usage

xth. call  (Day, xx. Month 2013)

Agenda:

Querstions:

Summery:

ToDo: