Blog entries with 'CourseManagement' tag

Currently the descriptions are absent and so we are setting the code to be the description.

Can we fix this?

This is our impl of getEnrollmentStatusDescriptions:

CourseManagementServiceUCDImpl.java

	@SuppressWarnings("unchecked")
	public Map<String, String> getEnrollmentStatusDescriptions(Locale locale) {
		//TODO: setup the NLS props on the connection based on locale?
		List<String> statuses = getHibernateTemplate().findByNamedQuery("findEnrollmentStatusDescriptions");
		
		//TODO: do we need human-readable descriptions here?
		Map<String, String> rv = new HashMap(statuses.size());
		for(Iterator i = statuses.iterator();i.hasNext();) {
			String code = (String)i.next();
			rv.put(code, code);
		}
		
		return rv;
         }

CourseSets play prominently in assumptions written into the CMS API (comments, at least)

CourseManagementService.isEmpty(String courseSetEid) for example assumes that the String param is a eid for a CourseSet and the OOTB hibernate implementation runs this HQL:

from CourseSetCmImpl as cs where cs.eid=:eid and
        	(size(cs.canonicalCourses) > 0 or size(cs.courseOfferings) > 0)

We have Meeting and Section implemented and mapped now.

So, before we can get a full CourseManagementService implementation that works, we'll need to decide what to do with some some remaining object mappings

There are other things to decide too.

In the meantime, I am overriding the parent class implementations of unimplementable methods and logging errors

Here are some of those methods. Do we need these? I don't know.

There's a method that uses the courseset eid along with the academic session eid to get courseofferings.

public Set findCourseOfferings(String courseSetEid,
			String academicSessionEid)

We will also need memberships in order to implement

public Map findCourseOfferingRoles(String userEid) and 
public Map findCourseSetRoles(String userEid)

...since roles are only in memberships

WRT CourseSets

public List<CourseSet> findCourseSets(final String category)

the String could be anything. This could be coded as well: "dept:chemistry", "loose affiliation: extension"

The key to me is to not think of CourseSets as having to statically point to specific named node in our enterprise hierarchy (like 'School') but can be qualified a bit.

WRT Grading Schemes

public Map<String, String> getGradingSchemeDescriptions(Locale locale)

I suppose this will be easy once we figure out how to get Membership objects impl'd

And then there's and sql thing....

public Set<EnrollmentSet> findCurrentlyEnrolledEnrollmentSets(final String userId) 

... currently uses this in the named query:

'select enr.enrollmentSet from EnrollmentCmImpl as enr where enr.userId=:userId and enr.dropped=false and
        	(enr.enrollmentSet.courseOffering.startDate is null or enr.enrollmentSet.courseOffering.startDate <= current_date()) and
        	(enr.enrollmentSet.courseOffering.endDate is null or enr.enrollmentSet.courseOffering.endDate >= current_date())'

... which would translate in one case to 'any user who has not dropped and belongs to an enrollmentset that has no start and no end date.'

I think we can safely remove the null checks here but ?

There's a similar issue with

 
public Set<EnrollmentSet> findCurrentlyInstructingEnrollmentSets(final String userId)

WRT sections:

public Set findEnrolledSections(String userEid)

public Set findEnrolledSections(String userEid, String academicSessionEid)

And, this needs sections and Memberships:

public Map findSectionRoles(String userEid)

..that's all for now

There is currently no way to get from an Enrollment to an EnrollmentSet in the CM API. The Sakai OOTB hibernate implementation has an EnrollmentSet object as a property to each Enrollment impl. As Josh has pointed out in emails before, this is a heavy memory object map. I proposed to Josh that he add a setter and getter for a String property for the EnrollmentSet's EID into the Enrollment interface. He said that he would look to add it for Sakai 2.5.

there should be a limited list of term type available in the course site creation wizard and so should be joined with active term tpes for the user

Eid's again

The ideal situation would be to have an opaque id generated by the process that updates the tables (I am thinking mviews here) this opaque Id can be indexed, one would think, and hibernate would be cheery that it had a real id, and it would be zippy to search.

cm authz provider

Question (TPA):
We are in the process of implementing CM and well as the cm-authz-provider. It almost seems like that the cm-authz-provider implementation could be general, usable by anybody, since it only makes calls to the CM API. Then if an institution implements/adjust the CM implementation, we wouldn't have to modify the cm-authz-provider and use it OOTB. Is that correct?

Answer (from Josh):
You are correct. There's no need to modify the group provider... just implement CM and configure the OOTB CM-based group provider in its components.xml file. More documentation will be coming, but the configuration is intended to be flexible and straight forward.

The older CM implementation objects used eid's in a way that did not ensure their uniqueness: CourseInfo object used eid=CRN and the CRN is not unique across all terms. The queries ensured the uniqueness at the DAO level by qualifying, in this case, with the TERM_CODE.

A unique eid would be in this case CRN+'_'+TERM_CODE', as one possibility.

But, we would lose the ability to take advantage of the underlying BANNER indexes in the tables on which our views are based if we tried to populate view columns with a concatenate as in select concat(CRN, TERM_CODE) as eid, ....

Composite Id's- with and with out component classes
Composite Id's using component classes seems to require that the classes can be written somewhere, since they must be serializable.
Not using component classes seems straighrfoward enough but

Not sure if a separatly mapped object can be used for this (in another table). That would work. But, since composite Id's seem to be generally frowned upon in hibernate, the next best solution would be to extend net.sf.hibernate.id.IdentifierGenerator and user that as a generator class.

Experimentation ensues.