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 _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
