HTML Widget Model, the work flow

1) HTML Widget flow

a) jsp parser encounter a custom tag in a jsp page, i.e. <>

b) trace back based on the tld <>, found the definition in

"/WEB-INF/view/module/htmlwidgets/resources/htmlwidgets.tld"

c) the tag class in the tld file will lead to

org.openmrs.module.htmlwidgets.web.taglib.WidgetTag

c1) WidgetTag class has properties named : name, object, property

this will populated by the attributes of the same name based on demonstration.jsp:

the known attributes are:

id="defaultField${p.key}" // represents the id of the input field

name="${p.key}" // represents the name of the input field

object="${demo}" // represents the object whose property are editing

property="${p.key}" // represents the name of the property/field to edit

// on the object

d) in WidgetTag, the actual widget type will be figured out by reflection, then associate the tag with a Taghandle class.

g) TagHandle itself is a abstract class,openmrs has a ulti method to match a subclass according to the actual type of the tag.

This method works like this:

it will call openmrs api to return a list of loaded spring beans.

if a bean has a annotation and matches the type. it should be returned

f) why handler classes are treated as beans?

In ApplicationContext-Service. we see a line

< package="org.openmrs"> < type="annotation" expression="org.openmrs.annotation.Handler">

... < /context:include-filter>

This line will let spring to include any class which has a @handler annotation and load them as beans into spring Context(finally figure it out, phew~~) when refreshing the context.