Timetable Creator: Merge consecutive cells with the same course

[david-yz-liu]

If a section is two or more hours long, there shouldn't be a border separating the cells. Also, the course name should only appear once.

This should probably be done by generating the grid dynamically and adding "colspan" attributes to the cells.

This hopefully would lead to support for off-hour courses too.

[Ian-Stewart-Binks]

Adding rowspan (colspan's trustee row spanning companion) has become troublesome. When the top-most time's rowspan is set to a value greater than 1, the timetable pushes its cells outwards. This is not the behaviour we want. To achieve behaviour that we want, I started to use jQuery's hide and show methods for the corresponding table cells. This proved troublesome for various features, such as the conflict feature, among others.

To clarify, the rowspan approach finds the times for a section- say CHM151- and climbs up the corresponding cells, until it finds the topmost one, and sets that topmost cell to the calculated rowspan based off of the number of cells that it has climbed. It hides the cells that it has climbed.

The troubles with rowspan have me more motivated to apply an Object Oriented approach sooner (I haven't done it yet, but would like to more). This could ease future headaches.

The other option is to give the illusion of rowspan. The can be achieved by changing the border-top of the current css. I have made a new branch to do this, and it is fairly successful. In any case, we should discuss this further because the feature seems to demand more effort than initially assumed.

(With my current approach, the only dissimilarity that I am concerned of is the 2 back to back cells. With rowspan in place, the title of the course will be in the center- however, this takes a bit of wizardry to produce with just eliminating the border and limiting the course title to the first displayed cell.)

Do you have any thoughts on how to simplify the task?

[david-yz-liu]

I'm okay just changing the borders for now, and leaving the course name at the top. That's what ROSI does, too.

The right way to handle the grid is to keep an object in memory storing all of the grid's properties, and then just render it (or a part of it) every time something gets changed. Perhaps this is what you meant by an "Object-Oriented approach". However, I hope you know that what I just described has nothing to do with making either course or section classes.

[Ian-Stewart-Binks]

I agree, and that's what I meant by Object Oriented Approach. Not just limiting it to course and section.

[Ian-Stewart-Binks]

In the below figure it is difficult to distinguish which course owns that M3S td slice. Should I add in the name in this circumstance or keep it as it is?

[david-yz-liu]

Yeah, I think that makes the most sense.

On August 2, 2014 6:17:46 PM EDT, Ian Stewart-Binks notifications@github.com wrote:

In the below figure it is difficult to distinguish which course owns
that M3S td slice. Should I add in the name in this circumstance or
keep it as it is?

---

Reply to this email directly or view it on GitHub:
#146 (comment)

Sent from my Android phone with K-9 Mail. Please excuse my brevity.