Is there a list of available fragments?

[Craig A.]

Hi,

Is there a list of available fragments that we can use in our modules? Would this be a good thing to get started on the wiki or is it too cumbersome to keep up to date?

Here's an example of a table:

fragment provider	fragment name	parameters	description
coreapps	patientHeader	[ patient: patient.patient, activeVisit: activeVisit, appContextModel: appContextModel ]	TBD

Sincerely,

Craig

[Muhammad Safwan]

Hi Craig,

In OpenMRS wiki there's a github link of a basic module already developed. It contains fragments as you are saying. Kindly have a look. You just have to import it.

Thanks,

MUHAMMAD SAFWAN

Software Engineer

Interactive Health Solutions

www.ihsinformatics.com

--
OpenMRS Developers: http://om.rs/dev
Post: d...@openmrs.org | Unsubscribe: dev+uns...@openmrs.org
Manage your OpenMRS subscriptions at http://om.rs/id
 
Register today for our Maputo 2015 Implementers Meeting: http://om.rs/moz15

To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@openmrs.org.

[Daniel Kayiwa]

Craig,

Am not aware of any.

Even if it is not kept up to date with all the new ones, i still see its existence as better than not having anything at all. :)

Do you want to start on it?

Some body else could start thinking about automating it. :)

--

If we keep uppermost in our minds the unkind and unjust acts of others, we shall find it impossible to love them as Christ has loved us; but if our thoughts dwell upon the wondrous love and pity of Christ for us, the same spirit will flow out to others.

[Darius Jazayeri]

I think that having a wiki page that is presumed to be incomplete and outdated is not really helpful. So I don't personally think it makes a lot of sense.

Something that pulls javadoc from *FragmentController in github.com/openmrs could be straightforward to automate, and valuable.

-Darius

[Craig A.]

Hi,

I'm interested on working on and agree that it would be best to automate this idea. I'm training a crawler at import.io to test the concept and want to make sure I capture everything appropriately. I've written a brief example for the coreapps patientHeader followed by some questions.

coreapps patientHeader Example:

Here's the line that we call on the groovy page to include the fragment:

${ ui.includeFragment("coreapps", "patientHeader", [ patient: patient.patient, activeVisit: activeVisit, appContextModel: appContextModel ]) }

Clearly "coreapps" is the module name, "patientHeader" is the fragment name and the parameters are a list.

So, to extract these components from FragmentController.java docs we would need to use the following:

RAW Github URL: 
https://raw.githubusercontent.com/openmrs/openmrs-module-coreapps/master/omod/src/main/java/org/openmrs/module/coreapps/fragment/controller/PatientHeaderFragmentController.java

I can pull the module name and fragment name from the URL and some of the parameters from the "@FragmentParam" property.

Questions:

1) Is there a problem with the capitalization of the letter P in "PatientHeader" in the URL vs the call "patientHeader" in the ui.includeFragment function?

2) I see that I can get some of the parameters by searching the text for "@FragmentParam". Is this the right thing to do? What about other parameters such as "activeVisit: activeVisit" from above? That isn't explicitly stated as a Fragment Parameter. 

3) Would it be as useful to provide the github link to the fragment controller instead of trying to define the parameters in the table?

4) Are there any sources for a "description" column? 

Sincerely,

Craig

[Darius Jazayeri]

Hi Craig,

Thanks for investigating!

Briefly:

• Yes, it's intentional that the controller class would have the first letter capitalized (per Java conventions).
  
• It's possible to have a fragment with only a view and no controller
• I suggest that you fetch the javadoc if there is any. (There will be very little now, but having it automatically build some documentation might nudge people to do more.) I like the idea of pointing to the github version of the code.
• In practice there's no way to 100% determine what parameters may be used without inspecting all the code. But it's better than nothing to look at the method signature of the controller() method and list off each thing that is annotated with @FragmentParam.

-Darius