Notes from today's Fluid dev meeting

[Colin Clark]

Hi all,

We had a productive Developer's Meeting today. I've attached some notes from the meeting below. 

These meetings happen every Wednesday at noon Eastern time. We tend to cover technical issues and questions about Decapod, CollectionSpace, Engage, and Infusion. All are welcome to join.

Colin


Things we talked about

* How cool is TestSwarm, really?
* Acceptance testing
* Framework next steps
* Components that don't know about each other but live inside the same markup and both get rerendered


Test Swarm

We've set up an instance of Mozilla's Test Swarm, which allows us to automate and distribute the process of running unit tests across a wide range of browsers. We're piloting with Infusion's test suite at the moment. Each time a new commit occurs, a new Test Swarm job is created and new unit tests are automatically pushed to every browser in the swarm. Here are some general next steps:

1. Look into setting up a server consisting of virtual machines with browsers pointing at TestSwarm
2. Find ways to communicate the results of test runs to everyone


Next Steps to using Test Swarm with CollectionSpace

1. Upgrade CSpace to the current version of QUnit distributed with Infusion 
2. Put a post-commit hook in CSpace's SVN repository that submits jobs to TestSwarm


Acceptance Testing Next Steps

1. Write a few reasonable tests with Selenium as a point of comparison
2. Determine what we need to do in order to work with the Doh robot
3. Choose a suitable strategy and start expanding CSpace's acceptance test coverage


Framework Next Steps

We're making small steps towards new features for the Infusion framework, driven by the requirements of our work on CollectionSpace. The short to medium-term plan looks like this:

1. Checkbox and repetition support for "proto trees" 
  * to support roles and permissions in cspace
2. Bring the transactional ChangeApplier out of a branch and into Infusion's main line
  * to allow some needed refactoring in CSpace DataContext
3. Two Phase initialization for components 
  * to reduce the ajax calls when fetching many templates 
  * it's also just better


Components and Rendering

There were some questions about how to handle components that render their own markup, causing other related components to lose their attachment to the DOM. Here's the recommended approach for dealing with this issue:

1. Components should render into correctly-scoped containers. If a component renders a list, it should  only render within a container of that list.

2. Where there's some kind of cooperative concern about some rendered markup, these components should have a decorator or subcomponent relationship. Affected subcomponents will need to be "zapped" as part of the parent component refreshing its view. As an example, Engage shows this pattern of implementing refreshView() in a number of components.


Colin

---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org