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)
Thu, Apr 25, 3:41 AM
Unknown Object (File)
Fri, Apr 19, 3:03 AM
Unknown Object (File)
Thu, Apr 11, 10:49 AM
Unknown Object (File)
Fri, Apr 5, 3:04 PM
Unknown Object (File)
Fri, Mar 29, 5:07 AM
Unknown Object (File)
Mar 15 2024, 10:44 AM
Unknown Object (File)
Mar 10 2024, 5:20 AM
Unknown Object (File)
Feb 10 2024, 4:04 PM
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
Branch
grip4
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 22245
Build 30415: Run Core Tests
Build 30414: arc lint + arc unit

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.