Page MenuHomePhabricator

Add a "WorkboardCardTemplate" class to make workboard client code easier to reason about
ClosedPublic

Authored by epriestley on Mar 11 2019, 3:17 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Mar 15, 10:44 AM
Unknown Object (File)
Sun, Mar 10, 5:20 AM
Unknown Object (File)
Feb 10 2024, 4:04 PM
Unknown Object (File)
Feb 8 2024, 4:05 AM
Unknown Object (File)
Feb 3 2024, 9:39 PM
Unknown Object (File)
Jan 25 2024, 1:51 AM
Unknown Object (File)
Dec 26 2023, 8:19 PM
Unknown Object (File)
Dec 24 2023, 4:32 AM
Subscribers
None

Details

Summary

Depends on D20266. Boards currently have several whateverMap<cardPHID => stuff> properties, but we can just move these all down into a CardTemplate, similar to the recently introduced HeaderTemplate.

The CardTemplate holds all the global information for a card, and then Card is specific for a particular copy in a column. Today, each CardTemplate has one Card, but a CardTemplate may have more than one card in the future (when we add subproject columns).

Test Plan

Viewed workboards in different sort orders and dragged stuff around, grepped for all affected symbols.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Mar 12 2019, 7:05 PM
webroot/rsrc/js/application/projects/WorkboardBoard.js
314

This might be a behavioral change / wrong, but I couldn't figure out why this check existed, and I've touched most of this code now in implementing the new "Group By Header" stuff. Generally, all the code handles updates to objects it already knows about gracefully, and the obvious cases (adding a new card / editing an existing card) appear to work fine, so I suspect this wasn't meaningful.

This revision was automatically updated to reflect the committed changes.