It generates a report of curricular information for a given program in a given year.
- when it gets taught (program, year)
- what gets taught (competencies/objectives)
- how it gets taught (courses/sessions)
- how much gets taught (hours from offerings/ilms)
But not!
- who teaches
- who gets taught
whiteboard time
- report info (year, id, etc)
- competency framework (PECRS, objectives, methods)
- events
- sequence blocks
- program
- objectives/competencies
- courses/sessions/offerings
curriculum_inventory_*tablescurriculum_inventory_institution--> schoolcurriculum_inventory_report--> programcurriculum_inventory_sequence(1 per report)curriculum_inventory_sequence_block--> coursecurriculum_inventory_academic_level(10 per report)curriculum_inventory_export(1 per report)aamc_pcrsaamc_methodsession_type_x_aamc_methodcompetency_x_aamc_pcrs
ilios.phpconfig scriptaamc_tables AND assoc. JOIN tablescurriculum_inventory_institution
Curriculum_Inventory_Manager- CRUD for report and sequence blocks.
- d/l and finalize methods for report.
- lightweight, deals with routing, input validation and some output (pre)formatting
- heavy lifting in business logic and model components
third_party/Ilios/Curriculum_Inventory/Exporter.php- deals with report data aggregation and xml export generation
- should really be two classes
- various
Curriculum_Inventory_*classes - most of them are Table Data Gateways, only one (
Curriculum__Inventory) is a true Data Access Object. - heredoc notation for SQL queries preferred, CodeIgniter query builder used where applicable (
where_in()) - of note:
Curriculum_InventoryandCurriculum_Inventory_Sequence_Block
index.phppage template- various
*_dialog.inc.phptemplates for dialog markup report_details_view.inc.phpview template- The rest of the markup gets generated dynamically via JavaScript DOM methods.
- namespace
ilios.cim - YUI2 - Y U no MVC?
- Model/View/???
application/views/curriculum_inventory/jsdir- work with the framework, not against it
- no dirty state! ever!!!!
- reuse as little of the pre-existing JS shit components as possible
ilios.cim.js- single
ilios.cim.Appobject - application container, event broker, application lifecycle manager
- no routing
- Controller?
- event driven
- talks to server backend via XHR calls
- deals with finalizing/deleting/exporting reports.
- deals with sequence block deletion.
- custom events YAHOO.util.CustomEvent
- collection management of views components
- where does it belong?
ilios.cim.model.js- namespace
ilios.cim.model - Data models and Collections
- meant for reusability (TODO: refactor out into common namespace)
- auto-generated client side id
- extends
YAHOO.util.AttributeProvider - fires
changeevent on attribute change - read-only attribute support
- associative array implementation
- add/remove/list/exists/get/walk/size methods
- extends
ilios.cim.model.ObjectMap - adds checkin/checkout capabilities
ilios.cim.view.js- "A View is a display element backed by a model.
- extends "YAHOO.util.Element`
- listens to model changes - updates itself accordingly
- may listen to application wide events as well (e.g. lock/unlock report during finalization or d/l)
- may be container for other page elements (such as buttons), and sub-views (e.g. nested sequence blocks)
- for reference: http://www.yuiblog.com/blog/2008/06/24/buildingwidgets/
-
all dialogs and toolbars
-
ilios.cim.widget.js -
built on
YAHOO.util.Element(toolbars) andYAHOO.widget.Dialog -
dialogs for changing model, form submissions/XHR POSTS directly to server backend. custom events firing on success/failure response
-
toolbars - containers for buttons
- server-side tests
- client-side tests