Wednesday, March 31, 2010
Spring MVC(2) Property Editor
From http://www.shaunabram.com/data-binding-in-spring-mvc/
Spring MVC allows the use of command objects (aka form backing objects, model attributes, domain model objects – basically the objects used to transport data between your view and your controller) using just about any type. However, the Servlet API deals with form parameters as Strings. Spring uses a technique called data binding to covert between the String representation and the real underlying type. This enables user input to be bound to the objects you use to process user input. In other words, the values entered by a user in a form can be used to set the property values on a chosen object.
Spring MVC allows the use of command objects (aka form backing objects, model attributes, domain model objects – basically the objects used to transport data between your view and your controller) using just about any type. However, the Servlet API deals with form parameters as Strings. Spring uses a technique called data binding to covert between the String representation and the real underlying type. This enables user input to be bound to the objects you use to process user input. In other words, the values entered by a user in a form can be used to set the property values on a chosen object.
Spring MVC(1) basic controller work flow
1)DispatcherServlet: the main servlet
org.openmrs.web
2)Controllers
SimpleFormController
Workflow from: http://static.springsource.org/spring/docs/2.0.x/api/org/springframework/web/portlet/mvc/AbstractFormController.html#workflow
1)The controller receives a request for a new form (typically a Render Request only). The render phase will proceed to display the form as follows.
2)Call to formBackingObject() which by default, returns an instance of the commandClass that has been configured (see the properties the superclass exposes), but can also be overridden to e.g. retrieve an object from the database (that needs to be modified using the form).
3) Call to initBinder() which allows you to register custom editors for certain fields (often properties of non- primitive or non-String types) of the command class. This will render appropriate Strings for those property values, e.g. locale-specific date strings.
4)The PortletRequestDataBinder gets applied to populate the new form object with initial request parameters and the onBindOnNewForm(RenderRequest, Object, BindException) callback method is invoked. (only if bindOnNewForm is set to true) Make sure that the initial parameters do not include the parameter that indicates a form submission has occurred.
5)Call to showForm to return a View that should be rendered (typically the view that renders the form). This method has to be implemented in subclasses.
6)The showForm() implementation will call referenceData, which you can implement to provide any relevant reference data you might need when editing a form (e.g. a List of Locale objects you're going to let the user select one from).
7)Model gets exposed and view gets rendered, to let the user fill in the form.
8)The controller receives a form submission (typically an Action Request). To use a different way of detecting a form submission, override the isFormSubmission method. The action phase will proceed to process the form submission as follows.
9)If sessionForm is not set, formBackingObject is called to retrieve a form object. Otherwise, the controller tries to find the command object which is already bound in the session. If it cannot find the object, the action phase does a call to handleInvalidSubmit which - by default - tries to create a new form object and resubmit the form. It then sets a render parameter that will indicate to the render phase that this was an invalid submit.
10)Still in the action phase of a valid submit, the PortletRequestDataBinder gets applied to populate the form object with current request parameters.
11)Call to onBind(PortletRequest, Object, Errors) which allows you to do custom processing after binding but before validation (e.g. to manually bind request parameters to bean properties, to be seen by the Validator).
12)If validateOnBinding is set, a registered Validator will be invoked. The Validator will check the form object properties, and register corresponding errors via the given Errors object.
13)Call to onBindAndValidate which allows you to do custom processing after binding and validation (e.g. to manually bind request parameters, and to validate them outside a Validator).
14)Call to processFormSubmission to process the submission, with or without binding errors. This method has to be implemented in subclasses and will be called only once per form submission.
15)The portal will then call the render phase of processing the form submission. This phase will be called repeatedly by the portal every time the page is refreshed. All processing here should take this into account. Any one-time-only actions (such as modifying a database) must be done in the action phase.
16)If the action phase indicated this is an invalid submit, the render phase calls renderInvalidSubmit which – also by default – will render the results of the resubmitted form. Be sure to override both handleInvalidSubmit and renderInvalidSubmit if you want to change this overall behavior.
17)Finally, call renderFormSubmission to render the results of the submission, with or without binding errors. This method has to be implemented in subclasses and will be called repeatedly by the portal.
Workflow (in addition to the superclass):
1)Call to processFormSubmission which inspects the Errors object to see if any errors have occurred during binding and validation.
2)If errors occured, the controller will return the configured formView, showing the form again (possibly rendering according error messages).
3)If isFormChangeRequest is overridden and returns true for the given request, the controller will return the formView too. In that case, the controller will also suppress validation. Before returning the formView, the controller will invoke onFormChange(javax.portlet.ActionRequest, javax.portlet.ActionResponse, java.lang.Object, org.springframework.validation.BindException), giving sub-classes a chance to make modification to the command object. This is intended for requests that change the structure of the form, which should not cause validation and show the form in any case.
4)If no errors occurred, the controller will call onSubmitAction during the action phase and then onSubmitRender during the render phase, which in case of the default implementation delegate to onSubmitAction and onSubmitRender with just the command object. The default implementation of the latter method will return the configured successView. Consider just implementing doSubmitAction for simply performing a submit action during the action phase and then rendering the success view during the render phase.
org.openmrs.web
2)Controllers
SimpleFormController
Workflow from: http://static.springsource.org/spring/docs/2.0.x/api/org/springframework/web/portlet/mvc/AbstractFormController.html#workflow
1)The controller receives a request for a new form (typically a Render Request only). The render phase will proceed to display the form as follows.
2)Call to formBackingObject() which by default, returns an instance of the commandClass that has been configured (see the properties the superclass exposes), but can also be overridden to e.g. retrieve an object from the database (that needs to be modified using the form).
3) Call to initBinder() which allows you to register custom editors for certain fields (often properties of non- primitive or non-String types) of the command class. This will render appropriate Strings for those property values, e.g. locale-specific date strings.
4)The PortletRequestDataBinder gets applied to populate the new form object with initial request parameters and the onBindOnNewForm(RenderRequest, Object, BindException) callback method is invoked. (only if bindOnNewForm is set to true) Make sure that the initial parameters do not include the parameter that indicates a form submission has occurred.
5)Call to showForm to return a View that should be rendered (typically the view that renders the form). This method has to be implemented in subclasses.
6)The showForm() implementation will call referenceData, which you can implement to provide any relevant reference data you might need when editing a form (e.g. a List of Locale objects you're going to let the user select one from).
7)Model gets exposed and view gets rendered, to let the user fill in the form.
8)The controller receives a form submission (typically an Action Request). To use a different way of detecting a form submission, override the isFormSubmission method. The action phase will proceed to process the form submission as follows.
9)If sessionForm is not set, formBackingObject is called to retrieve a form object. Otherwise, the controller tries to find the command object which is already bound in the session. If it cannot find the object, the action phase does a call to handleInvalidSubmit which - by default - tries to create a new form object and resubmit the form. It then sets a render parameter that will indicate to the render phase that this was an invalid submit.
10)Still in the action phase of a valid submit, the PortletRequestDataBinder gets applied to populate the form object with current request parameters.
11)Call to onBind(PortletRequest, Object, Errors) which allows you to do custom processing after binding but before validation (e.g. to manually bind request parameters to bean properties, to be seen by the Validator).
12)If validateOnBinding is set, a registered Validator will be invoked. The Validator will check the form object properties, and register corresponding errors via the given Errors object.
13)Call to onBindAndValidate which allows you to do custom processing after binding and validation (e.g. to manually bind request parameters, and to validate them outside a Validator).
14)Call to processFormSubmission to process the submission, with or without binding errors. This method has to be implemented in subclasses and will be called only once per form submission.
15)The portal will then call the render phase of processing the form submission. This phase will be called repeatedly by the portal every time the page is refreshed. All processing here should take this into account. Any one-time-only actions (such as modifying a database) must be done in the action phase.
16)If the action phase indicated this is an invalid submit, the render phase calls renderInvalidSubmit which – also by default – will render the results of the resubmitted form. Be sure to override both handleInvalidSubmit and renderInvalidSubmit if you want to change this overall behavior.
17)Finally, call renderFormSubmission to render the results of the submission, with or without binding errors. This method has to be implemented in subclasses and will be called repeatedly by the portal.
Workflow (in addition to the superclass):
1)Call to processFormSubmission which inspects the Errors object to see if any errors have occurred during binding and validation.
2)If errors occured, the controller will return the configured formView, showing the form again (possibly rendering according error messages).
3)If isFormChangeRequest is overridden and returns true for the given request, the controller will return the formView too. In that case, the controller will also suppress validation. Before returning the formView, the controller will invoke onFormChange(javax.portlet.ActionRequest, javax.portlet.ActionResponse, java.lang.Object, org.springframework.validation.BindException), giving sub-classes a chance to make modification to the command object. This is intended for requests that change the structure of the form, which should not cause validation and show the form in any case.
4)If no errors occurred, the controller will call onSubmitAction during the action phase and then onSubmitRender during the render phase, which in case of the default implementation delegate to onSubmitAction and onSubmitRender with just the command object. The default implementation of the latter method will return the configured successView. Consider just implementing doSubmitAction for simply performing a submit action during the action phase and then rendering the success view during the render phase.
Learning OpenMrs Project, Source code(3)
1) org.openmrs.h7.web.*: h7 controller, servlet
2)org.openmrs.layout.web
layout?
3)org.openmrs.module.web
servlet?
ModelAndView?
Module load unload,
4)org.openmrs.module.controller
controller
5)org.openmrs.module.web.extension
abstract class of extension op
6)org.openmrs.module.web.extension.provider
link?
7)org.openmrs.module.web.filter
to allow module defined filter to be loaded and excute
8)org.openmrs.web.taglib
tag parsing?
9)org.openmrs.notification.web.*
notification? initBind? processFormSubmission?
10)org.openmrs.sheduler.web
formBackingObject?
referenceData?
11)org.openmrs.summary.web
PatientSummarySpecification
12)org.openmrs.web.controller
SimpleFormController?
webform controller & validator
13)org.openmrs.web.dwr
dwr?
Direct Web Remoting is a framework that allows us to translate java objects and methods to javascript objects and methods. Together with DOJO, DWR forms the basis of the AJAX in OpenMRS. The dwr.xml descriptor file describes which classes and methods are translated and made available to javascript calls. Most base DWR-able classes are placed into the org.openmrs.web.dwr package.
2)org.openmrs.layout.web
layout?
3)org.openmrs.module.web
servlet?
ModelAndView?
Module load unload,
4)org.openmrs.module.controller
controller
5)org.openmrs.module.web.extension
abstract class of extension op
6)org.openmrs.module.web.extension.provider
link?
7)org.openmrs.module.web.filter
to allow module defined filter to be loaded and excute
8)org.openmrs.web.taglib
tag parsing?
9)org.openmrs.notification.web.*
notification? initBind? processFormSubmission?
10)org.openmrs.sheduler.web
formBackingObject?
referenceData?
11)org.openmrs.summary.web
PatientSummarySpecification
12)org.openmrs.web.controller
SimpleFormController?
webform controller & validator
13)org.openmrs.web.dwr
dwr?
Direct Web Remoting is a framework that allows us to translate java objects and methods to javascript objects and methods. Together with DOJO, DWR forms the basis of the AJAX in OpenMRS. The dwr.xml descriptor file describes which classes and methods are translated and made available to javascript calls. Most base DWR-able classes are placed into the org.openmrs.web.dwr package.
Tuesday, March 30, 2010
Learning OpenMrs Project, Source code(2)
1)org.openmrs.messagesource
???
2)org.openmrs.module
module defintion, loader, factory
3)org.openmrs.notification.*
communication between users
4)org.openmrs.ob.*
observation?
5)org.openmrs.order/org.openmrs.patient
deal with order and patient
6)org.openmrs.propertyeditor
propertyeditor??
7)org.openmrs.report/reporting
deprecated, deal with report
8)org.openmrs.scheduler
Task/scheduler
9)org.openmrs.serilization
serilization
10)org.openmrs.util
security, db ,etc.
11)org.openmrs.validator
validation
???
2)org.openmrs.module
module defintion, loader, factory
3)org.openmrs.notification.*
communication between users
4)org.openmrs.ob.*
observation?
5)org.openmrs.order/org.openmrs.patient
deal with order and patient
6)org.openmrs.propertyeditor
propertyeditor??
7)org.openmrs.report/reporting
deprecated, deal with report
8)org.openmrs.scheduler
Task/scheduler
9)org.openmrs.serilization
serilization
10)org.openmrs.util
security, db ,etc.
11)org.openmrs.validator
validation
Monday, March 29, 2010
Learning OpenMrs Project, Source code(1)
1)org.openmrs
contain model definitions
official notes:
These classes represent the core domain objects for the OpenMRS project
2)org.openmrs.annotation
annotation definitions
on:This package contains classes associated with the custom java 1.5+ annotations
3)org.openmrs.aop
Need to dig~~
what is advisor?
on:This package contains the classes associated with Aspect Oriented Programming
4)org.openmrs.api
containing interfaces, exceptions
5)org.openmrs.context
context contains user context(could be n) and service context(only1)
On:This package describes the context framework through which authentication is performed and services provided for the OpenMRS system
6)org.openmrs.api.db
dao interface definition and exception definition
7)org.openmrs.api.hibernate
the hibernate implementation of org.openmrs.api.db
8)org.openmrs.api.handler
the handler class automatically called using AOP???
9)org.openmrs.api.imp
the implementation of the api interfaces
10)org.openmrs.arden
logic??
11) h7
special format for medical info?
12)openmrs.logic
build criterials for query
to be continues
contain model definitions
official notes:
These classes represent the core domain objects for the OpenMRS project
2)org.openmrs.annotation
annotation definitions
on:This package contains classes associated with the custom java 1.5+ annotations
3)org.openmrs.aop
Need to dig~~
what is advisor?
on:This package contains the classes associated with Aspect Oriented Programming
4)org.openmrs.api
containing interfaces, exceptions
5)org.openmrs.context
context contains user context(could be n) and service context(only1)
On:This package describes the context framework through which authentication is performed and services provided for the OpenMRS system
6)org.openmrs.api.db
dao interface definition and exception definition
7)org.openmrs.api.hibernate
the hibernate implementation of org.openmrs.api.db
8)org.openmrs.api.handler
the handler class automatically called using AOP???
9)org.openmrs.api.imp
the implementation of the api interfaces
10)org.openmrs.arden
logic??
11) h7
special format for medical info?
12)openmrs.logic
build criterials for query
to be continues
Subscribe to:
Posts (Atom)