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_pcrs
aamc_method
session_type_x_aamc_method
competency_x_aamc_pcrs
ilios.php
config 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_Inventory
andCurriculum_Inventory_Sequence_Block
index.php
page template- various
*_dialog.inc.php
templates for dialog markup report_details_view.inc.php
view 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/js
dir- 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.App
object - 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
change
event 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