Deco

Most of my time at the sea sprint was spent working with David Glick and Gonzalo Almeida on the deco layout engine. David already provided a pretty detailed post regarding much of what we worked on so I’ll refer you to his post and the a brief deco demo video David created.

Overall we got a lot done and have a pretty solid start on the layout interface.

Some other things that need to get done:

  • More tiles! collective.cover already provides quite a few; however, they are not fully compatible with default plone.app.deco right now
  • Polish the interface
  • Saving layouts, letting users choose layouts to base deco page on
  • Update editing behavior of all plone content so it’s consistent with the way tile content is edited

UI 

I also spent some time discussing the UI related aspects of plone.app.toolbar, deco’s layout interface and modals popups with Timo Stollenwerk and Cris Ewing. We were able to have a call with UCLA’s Alice Tseng-Planas, who has had experience with tile editing along with plone’s current content editing interface and the problems she has noticed. Alice is very well versed in user interfaces and the phone call with her was extremely helpful.

Things to think about

First off, there are concerns with moving over to plone.app.deco, users will get an inconsistent editing experience when coupled with editing existing plone content type schema. Ideally, we somehow find a way to unify how deco content, plone schema and dublin core content is edited. With deco, we’ll have field tiles which will just render values set on the content and if editing those values is different than editing deco tiles, we’ll have a very inconsistent editing experience for users.

Secondly, we need to be certain that our placement of the toolbar, on top of the page, is optimal for users. Plone users might have to get used to the new location but is it even better for beginners to as well? We have no proof that it will be and some have already voiced concerns. 

Lastly, how do we deal with modal popup forms. For the most part, web users are getting quite used to seeing modal popups on web pages but they can get very confusing since it’s easy to mix work context. It’s especially nasty when Tiny MCE is inserted into a popup and then opens another overlay, over the top of the existing overlay.

Moving forward 

To start addressing our future Plone UI concerns, I’m going to make it one of the priorities of the Plone Conference UI Sprint to create testable UI examples of 1) unified editing interfaces, 2) toolbar placement. Alice said UCLA would be interested in administering user testing for us so we have proof of one interface working better than the other. 

I’ll also be working on providing UI guidelines for Plone. These will include guidelines on how to use modal popups correctly and when they are appropriate. 

 

Thanks to everyone that made the sprint happen. It was great and will help Plone move forward! 

Filed October 5th, 2012 under Javascript, Technical, Report

At the Sea Sprint my task was to help build the drag and drop layout system for Deco, working along with Nathan van Gheem and Gonzalo Almeida. This was an area where a lot of work was needed. Deco used to have these capabilities, but they had been lost earlier this year when Rok Garbas did a lot of refactoring to make sure that all of Deco’s javascript and CSS resources could be loaded in a separate iframe, to provide isolation from the frontend site. So at the start of the sprint, it was possible to drag tiles into a column, but there was no way to arrange rows and columns using a GUI. By the end of the sprint, we had re-created the ability to add, arrange, and remove rows and columns.

A brief demo: http://www.screencast.com/t/1BFjd89Xio

At the start of the sprint we were hoping that we could use one of the two existing codebases for creating tile layouts as a starting point, but unfortunately that didn’t seem possible. The first codebase is the one that Rob Gietema wrote for Deco several years ago. If you’ve seen screencasts of Deco in the past, this is what you saw. It provided an elegant user experience where the user could simply drag a tile around, and rows and columns would be created automatically if the tile was near the edge of an existing row or column. Unfortunately, this code was not written to support dragging between two separate iframes, and that is hard to retrofit into it (more on that below). In addition, several people who have been building Deco-like systems for clients have discovered downsides to creating rows and columns automatically. For one, it was too easy for inexperienced users to accidentally create rows and columns when they didn’t want to. Secondly, in some cases the action of creating layout (rows and columns) needs to be separated from the action of placing tiles in that layout so that different groups can be granted permission to do these different actions.

We also considered starting with the layout code in the collective.cover add-on that was created at the Cafecito sprint earlier this year. This implementation does separate the act of arranging rows and columns from the act of placing tiles in them. Unfortunately, it was also not built to handle drag and drop across multiple iframes. And it depends on the JQuery UI drag and drop library, which is too large and doesn’t perform well, according to Rok. So in the end we decided to do a new implementation using ideas from both of the existing ones.

Now, there is a dirty little secret about how we handle dragging things from the Deco toolbar iframe to the main content frame: the dragging only happens in the toolbar. When you start dragging, the toolbar expands to the entire size of the window (but transparent), and when you stop, it shrinks again. The problem was that we couldn’t get the drag and drop library (jquery.event.drag and jquery.event.drop) to bind events in both iframes, so the toolbar was not getting drag events when the mouse was over the content. I spent a few hours trying to get the library to bind events correctly before giving up, for the time being. So we went with the trick, invented by Rok, which allows us to receive all the events in the toolbar iframe, and then the mouse position is compared to the positions of the potential drop targets in the content frame.

One of the big questions was what grid system to use for positioning the rows and columns. The javascript needs to be able to make some assumptions about what sort of grid system is present in order to position things correctly. We decided to try using the grid from Twitter Bootstrap, since it is widely used and developed at this point. But which bootstrap grid? It has fixed and variable-width, responsive and nonresponsive versions. For now we are using the variable-width nonresponsive version. So it will resize with the window (or not resize if you fix the width of the visual portal wrapper), but not merge columns when the window gets narrow. However, in theory it should be possible to use a different grid system as long as it uses classes called “deco-row,” “deco-column,” and “deco-span1,” “deco-span2,” etc. At this point it assumes a 12-column grid, but that can easily be made configurable.

One thing that I think is nice about our implementation is how deleting columns and rows is handled. You can only delete a column if it has no tiles in it. Any empty columns show a message saying you can either add tiles or delete, where “delete” is a link that removes the column. This avoids the question of what to do with tiles that are in the column when it is deleted. And it avoids having hovering buttons for columns and rows in addition to tiles, which could get pretty visually confusing.

The implementation has a good start, but there’s plenty still to do. Next steps are:

1. Add acceptance tests using robotframework and unit tests using busterjs.

2. There are still a few bugs that result in a broken layout.

3. Make it smarter about sizing new columns (they should divide the column they are being dropped on, rather than starting at a width of 1 grid cell).

4. Figure out how to support undo and canceling changes to the layout. At this point the layout is saved when you add or remove a tile. So you can cancel your changes before that, but once you have changed tiles (which causes persistent changes) you can’t.

5. Ideally, do a bit of refactoring to turn the layout system into a more generally usable jquery plugin that could also be used by collective.cover.

Many thanks to the sprint organizers, sponsors, and attendees for contributing to such an enjoyable and productive weekend!

Filed October 4th, 2012 under Javascript, Technical, Report

I’d like to start with giving a big thanks to the organisers of the event, Chris, Andy and Ian you did a great job! The houses were awesome and everything was very well organised so we could fully focus on sprinting.

After the kick-off meeting I picked my topic: Javascript Unit Testing. At the beginning of the sprint there were no Javascripts Unit Tests at all. Some effort was made to setup the QUnit boilerplate but no tests were created. I started by looking into different Unit Testing frameworks. QUnit is a commonly used one but lacks nice integration with p.a.testing and CI environments like Jenkins. I have heard people talk about BusterJS so I decided to see if that would fit our needs.

BusterJS is written in Node.js and uses the same approach as Google’s JsTestDriver. You fire up a server and let different browsers connect to that server as slaves. Now you can run your Javascript unit tests through the commandline. The commandline tool connects to the buster-server which runs all the unittests in the connected slaves and send the results back to the commandline tool. This can also be easily integrated in your editor of choice. The configuration is fairly simple; you write a configuration file where you specify your dependencies, your sources and your tests. BusterJS is really modular and a lot of plugins are available already. For integration with Jenkins for example you can specify that the output should be xml so Jenkins can read all the results.

BusterJS also ships with the SinonJS stub and mock framework. I’ve used this extensively when writing the tests for Deco. SinonJS lets you create a mock or stub and after the tests are ran you can assert if the mock or stub has been run, how many times, with what arguments and what the results were. You can also add a spy to an existing function. This will leave the functionality of the existing function as it was but will also provide you with the variables you can use to assert with after the tests have been run.

Next up was support for linting. The buster-link module provides both jshint and jslint integration, you can pick the one you prefer. You can also specify all the optional settings in your buster config which it should use. The lint is run together with your tests and will also output all lint errors.

The last step was code coverage. The buster-coverage module provides lcov output for coverage results. When I tested the module all I got was very weird output. The number of lines and the lines numbers didn’t match at all with the actual source code. Since this was a very useful feature to have I started digging deeper into the buster-coverage module. After some debugging I found the error, fixed the buster-coverage module and did a pull request. The lcov file which is generated by the module also wasn’t very useful since we use the Cobertura format for Jenkins in our current setup for Deco for all the Python code. Since it was rather easy to write your own output I’ve updated the buster-coverage module to also support the Cobertura format.

With all the tools in place I started writing Unit Tests for p.a.deco. At the end of the sprint all tests were done with the exception of some code which was defined as “moving target”. BusterJS is really a step forward when it comes to Unit Testing Javascript and I will definitely use it in future projects.

Filed October 4th, 2012 under Report

Sea Sprint was an incredible success which would not have been possible without our sponsors:

  • Platinum:

    Anderson Leeb is a web consultancy focused on the Plone content management system.

    Anderson Leeb provided the Sea Sprint 2012 housing and ground transportation for the sprint.

  • Gold:

    Triangle Zope and Python Users Group (TriZPUG), soon to be known as TriPython.

    TriZPUG provided meals and ground transportation for the sprint.

    Sea Sprint is a strategic sprint of the Plone Foundation.

    The Plone Foundation provided travel support and financial services for the sprint.

    Four Digits develops software and web applications for companies and organizations, ranging from relatively simple websites to complex systems. Four Digits works with Plone, a user-friendly and adaptable package that enables you to fill your own website with content. In addition to being one of the safest platforms, it is also free and open source. Using Plone, Four Digits has created solutions for such organizations as home care provider Sensire and volunteer organization Humanitas.

    Four Digits provided travel support for the sprint.

    Timo Stollenwerk, Web Application Developer, Plone/Zope/Python.

    Timo Stollenwerk provided travel support for the sprint.

    The Plone users group of Seattle, WA.

    The Seattle Plone Gathering provided travel support for the sprint.

  • Silver:

    PretaWeb: High Availability, CMS Cloud, Multi-site Web Specialists.

    PretaWeb provided the kick-off dinner for the sprint.

    Cris Ewing offers development services across a number of platforms and operating systems to help you to find the right tool for your job and then get it done on time and on budget.

    Cris Ewing provided travel support for the sprint.

    Founded in 1999, Six Feet Up is a privately-held, woman-owned company that develops, hosts and supports sophisticated enterprise content management and collaborative intranet projects.

    Six Feet Up provided travel support for the sprint.

    Ageliaco, the Association for Free and Advanced Content Management , offers Plone site design, hosting, training, and support to member associations and institutions.

    Ageliaco provided travel support for the sprint.

    Wildcard provides enterprise engineering services to take the hassle out of your IT.

    Wildcard provided travel support for the sprint.

Filed October 1st, 2012 under Report

First off, wow! Andy Leeb, Chris Calloway and Ian Anderson coordinated an amazing event. The location was incredible, it was like a Corona commercial with a bunch of geeks sitting on the porch with their laptops. The food was spectacular. Big thanks to Chris for keeping us well fed at the sprint house, and another thanks to PretaWeb for sponsoring the kickoff dinner at Thai by the Sea. I ate so many shrimp one night, I nearly exploded!

corona_sea.jpgWhile it sounds like a Plone vacation, it was nothing of the sort. Since this was a short two day sprint, everyone was head down, trying to get as much done as possible. After the kickoff dinner on Friday night, we spent another three hours afterwards getting a solid plan in place for the first day of sprinting on Saturday. I was impressed by the tenacity of the sprinters coming from the west coast with very little sleep. Everyone hung in there to make sure we had a clear goal ahead of us.

During the planning, I decided to tackle bug fixes and unit tests. My first task was to upgrade plone.app.toolbar to Bootstrap 2.1.1. While it was a fairly smooth operation, it wasn’t clear if this would break anything once in place. I did some manual QA and verified it was working, then pushed the code. Of course, there were bugs, but with Rok’s help, they didn’t survive long.

After tackling a few issues, I moved on to help Rob Gietema and Ross Paterson with unit testing of Javascript code. We started to use a nice Javascript testing framework called Buster.js. Rob dove right in and wrote tests to cover most of plone.app.deco, then I started working on plone.app.tiles. This was a mind blowing experience for me. Imagine writing unit tests for code you didn’t write, in a language you are not very familiar with. By the end of Sunday I had covered about 90% of the Javascript code in plone.app.tiles, but had to go back and re-work tests as the code was changing underneath. I was very pleased with the end result.

While Rob and I were working on tests, Ross spent some time getting the tests running within zope.testrunner. I was really impressed with how he got this working. Now there is no excuse to leave Javascript untested.

There was talk of doing a topic focused Sea Sprint again next year. It won’t be hard to entice people to come hang out at the beach. I’d be there in a heartbeat!

Filed October 1st, 2012 under Javascript, Technical, Report, Testing

I was very surprised with the amount of work that got done in a relatively short sprint. Basically, there were only two full days available to the team to get work done and we took advantage of it. I’ve already done a quick reporting on the day 0 planning session that kicked off on Friday night, but here’s what got done from my side.

History Lessons

I was relatively new to the whole Deco bits so I volunteered to take on the task of pulling together the documentation and start curating and bringing it back into reality. Since I was new to the project, I started off just finding all of the places that the docs and notes for the project existed.

This project started around 2008 and at some point there was an active CoActivate space that was now suffering from sever bit rot. I collected anything of interest from that collaboration space and then found a person to delete it so that new folks looking for information about the project don’t run into this old content.

Deco has a huge potential to change how end content contributors interact with Plone and how site administrators can manage and easily change the layout of their sites without touching any HTML or Python code. All of this power comes from a combination of related python packages that manage the Toolbar, Tiles, Blocks, Panels and Layouts that exist. Each of those products had their own documentation that really belonged alongside the code. This is especially true in the case of plone.tiles since it has the potential to be used outside of Plone. This could be a huge obstacle for a new developer though as they would have to individually visit 5 or 6 packages documentation to see how everything goes together.

During the sprint, I took some time to learn a bit more about Sphinx and how to aggregate all of those docs from their individual packages into a single set of documentation. reStructuredText has a very powerful include function that works very well in Sphinx. You can now view all of the background technical documents in one place.

Since we were using Sphinx, I also took advantage of its ability to generate API documentation. Now the project includes the beginnings of the narrative documentation, the technical developer documentation and the API documentation all in one place published on github. Feel free to check it out and contribute:

http://plone.github.com/buildout.deco/

Next Steps

The technical documentation still needs some clean up to bring it in-line with reality as some things have changed since they were first written. I’d also like to include a section of end-user documentation with screenshots that can be updated each time the tests are run on our Jenkins server. It looked like this would be possible using the testing tools the rest of the team from the weekend put in place.

Thank You

I want to send a very sincere thank you to Chris Calloway for handling all of the logistics and being an amazing chef/pack leader over the weekend. We got the most out of the weekend and a lot had to do with his organization and leaving us to do nothing but sprint. I also want to thank Ian Anderson and Andy Leeb for helping bring this idea to realization and sponsoring the 2 sprint houses. What a great location and I can’t wait to see you all in 2 weeks at the Plone Conference.

Filed September 28th, 2012 under Report

I’m back home after the Sea Sprint.  Trying hard to catch up on lost sleep.  Trying hard to come back to earth after a completely transcendental coding experience.  The sprint was phenomenal.  The room was full of people totally dedicated to making some really difficult magic happen.  It was stunning to see folks surrounded by the kind of beauty that the Outer Banks have to offer spend 18 hours each day working their asses off.  No slackers, no free-riders.  Just great code coming from great minds at a great sprint.  

I went in to the sprint hoping to push forward some of my own agenda items for dealing with tiles.  Versioning and staging are about 80% in place.  I really want to make sure that we can honestly say that tiled content gets the full content management treatment, and that means ensuring that tiles are first-class citizens for must-have features like these.  But fate had another plan for me.  It became pretty clear by the end of the marathon post-dinner planning meeting on Friday (seriously, 3 hours, after dinner and drinks) that the sprint was going to focus on UI implementation.  That meant lots and lots of Javascript.

I’ve long had a certain antipathy toward Javascript.  It’s partly based in reality and partly in my own laziness with regard to learning how to work with the tools that exist to make it work.  Perhaps one of the biggest problems I’ve had with writing it (with myself, really) is that testing is a pain.  Because it’s such a pain, I’ve just avoided it entirely.  In my mind then, javascript is untestable and cannot be a real language.  Unassailable logic, no?

Well, imagine my surprise.  It turns out that when you’re using Plone, testing your javascript is no longer impossible, or even very hard.  Thanks to the tremendous work of shining stars like Ed, Rob, Godefroid, Timo, Asko and others (I apologize if you should be in this list and are not), we now have a couple of integrated ways to test javascript.  They work with our existing test runner.  There’s really no excuse anymore.

It was my great pleasure during the Sea Sprint to write a series of javascript acceptance tests for plone.app.toolbar and plone.app.deco.  Yeah, my pleasure!  Thanks to the beauty of robot framework keywords, you can write tests for javascript functionality that look as simple as this:

Edit tab should open edit view
    Log in as site owner
    Go to  ${TEST_FOLDER}
    Wait Until Page Contains Element  id=toolbar
    Select Frame  id=toolbar
    Wait Until Keyword Succeeds  3  5  Current Frame Contains  Edit
    Click Link  Edit
    Location Should Be  ${TEST_FOLDER}/edit 

Amazing, eh?  This test starts a browser, logs in as site admin and opens the pre-arranged test folder.  It is able to wait for animations to complete, and then can look inside an iframe for a given element, click it, and assert that the right thing happens.  With some effort (okay, a __lot__ of effort), you can even write tests for complex interactions like drag-and-drop:

Tile can be dragged to column
    Log in as site owner
    Go to  ${TEST_PAGE}
    Open Deco Editor
    Drag From Toolbar And Drop On Content  xpath=//*[@id="plone-tiletype-plone-app-texttile"]  xpath=//*[@id="content"]/div/div/div  25  25
    Wait Until Page Contains Element  id=add_tile
    Element Should Contain  id=add_tile  Add Text tile 

The xpath in there isn’t very pretty, but the long-and-short of this is that we can log in, open a deco page and activate the deco editor. Then we can drag a tile from the toolbar to the content area and assert that the form for adding the tile appears.  

And how exactly do we run these magic tests?  Like so:

$ bin/test -s plone.app.deco

Yep.  That’s it.  No extra commands needed.  Just set up your package to require the right stuff, add some minor test setup, and start writing UI tests that really exercise your Javascript code.  There’s documentation on this available on ReadTheDocs. It’s a bit rough, but the folks creating this stuff are dedicated to making sure it’s clear and complete.  

The above tests use the Robot Framework integration the Plone community members mentioned above have created.  There are more tests, js unit tests, that are supplied by integration with BusterJS.  These are equally cool and easy to run.  But since I worked exclusively on the acceptance tests, I can’t tell you much more than how fun it was to see coverage reports of Javascript code.  Damn, I must be a geek.

A final word or two about this sprint.  Andy Leeb and Ian Anderson of AndersonLeeb went out of their way to put on an amazing experience.  They were great hosts, and there could not be a better place to work than the location they scouted out.  And if you ever have a chance to attend a sprint where Chris Calloway is involved, do it.  You will never regret it.  I’ve been now to two of ‘em and that man just knows how it’s done.  

Thanks everyone for an amazing time, and see you in two weeks in Arnhem 

Filed September 26th, 2012 under Javascript, Technical, Report, Testing

While still in the States and waiting for my departure back home, I thought it would be nice to gather thoughts and impressions about the incredible last few days at Sea Sprint. Of course, I’ll be only writing from my perspective and about work I’ve been doing, but expect other participants of Sea Sprint to do the same in coming week.

Day -2 (Wed) and Day -1 (Thu)

I’ve arrived 2 days before sprint to prepare a bitt and to finally do some proper tourism in the States. Last year at Plone conference in San Francisco I was really disappointed that I didn’t stay at least day or two longer to actually see and experience the city. I said I’m not going to do the same mistake again and I’ve enjoyed in southern hospitality of people of Wilmington, NC. Also, my intention to buy a longboard failed since the store ran out of the model I want. Maybe next time.

Day 0 (Fri)

Andy Leeb (a sponsor of sprint) picked up Nathan Van Gheem and me in Wilmington and drove us to Oak Island where everybody was already enjoying the warm day and warm sea. Once we go settled in we took off for dinner which was sponsored by Dylan Jay of Pretaweb (thank you dylan). At dinner you could notice a certain excitement about the task that we had for the weekend and people were slowly already switching into programming mode.

Once we got back from dinner the sprint started in real sense. We talked Deco and Toolbar in all directions, gathered ideas, turned them into tasks and delegated them among us. It was amazing how quickly we got started and productive. But since everybody was a bit tired from the trip we all got to bed early.

Day 1 (Sat)

Anybody who has had the opportunity to work with TinyMCE knows how happy a programmer is when you need to fix something regarding TinyMCE. My Plan for the day was to fix the TinyMCE inside text tile. After the day was over I had:

  • TinyMCE initializing properly (not only the first time like before),
  • styles inside the content area of TinyMCE should be the same as the styles in the content frame and they were copied,
  • The TinyMCE toolbar was bloated with buttons that really didn’t fit into the text tile, so i limited themto only the buttons we need.

I can’t explained how happy I was when I saw text tile working. If I remember correctly I did a quick “I ro(c)k” dance and got myself a glass of rum.

Day 2 (Sun)

“IFrames, Overlays, Javascript and some more IFrames” … its going to be definitely a bit weird day if you wake up with this kind of thoughts. I went straight down to work and forgot about time…

  • updated bootstrap to 2.1.1
  • applied patch that enabled dynamic height of modals in bootstrap
  • wrote first tests for plone.app.toolbar  and figured out that busterjs really kicks ass
  • simplified javascript registration of tiletype (now it’s optional)
  • helped get part of image tile working

I think I was already half a sleep when I pushed last code to github and don’t really remember how I got to bed.

Final words

With few minor bugs still on the list, a release of work that we’ve been doing will be made available in next days so everybody can get dirty with Deco. I intentionally didn’t write what others were doing. I can only say I was amazed by the results and that many frustrations that I had with javascript and Plone are addressed and the result is n amazing set of tools you’ll be using very-very-very soon.

I must highlight Chris Calloway and his amazing cooking. Tthank you Chris for all the amazing dinners we had. As participant I was really only taking care of programming while everything else was taken care of. I know that my English vocabulary is pretty poor and it even shows more when I can’t find superlatives to describe the awesome logistics, hospitality and amazing work that has been done last weekend.

Thanks all and see you in Arnhem in 2 weeks…

Filed September 25th, 2012 under Technical, Report

Sea Sprint Report Out Day 2

Testing

Cris Ewing

  • acceptance tests on plone.app.deco
  • deco ui is there
  • edit p.a.toolbar works differently on deco page
  • dnd tile on target - mr. ewing made wild assumptions that were just right for the test
  • dnd by offset works well
  • 14 acceptance tests yesterday p.a.toolbar
  • 12 today on p.a.deco
  •  much love sent to Ed Manlove for being present to help in irc
Eric Steele
  • jenkins set up
  • selenium grid setup - FF, IE, Safari, can pick specific versions dependent on VM
  • 4 windows vm’s - “livin’ the dream”
  • dealing with IE
  • runs a test from jenkins server, windows VM: login test using IE!!!
Clayton - “we wrote many tests over the two days”
  •     unit tests for javascript
  •     shows us a test:
    • plone.tile.js
    • init tile
    • show it
    • hide it
  • buster test cases
  • spy - wraps methods to call original methods but adds extra variables
  • help from Rob Gietema to get it all working
  • Node.js passes it off to buster test runner
Ross Patterson - “I use stump WM”
  • demo
  • testrunner runs buster test layer
  • p.a.deco, p.a.toolbar, p.a.tiles
  • jenkinsbuster - integrated test buster into our suite of tests
  • selenium launches buster, but is not involved with test execution
    • controllable via enviornment variables
  • todo: remote driver to connect to selinium grid
  • bin/test runs them all
  • js lint + coverage - Rob Gietema
Timo Stollenwerk
  • control panel for deco - useless, removed but only after testing
  • example.tile package - added new tiles
  • zopeskel template - bin/templer plone_tile: title of tile + integration tests
  • screenshot issue - screenshots during robot selinum tests and include in documentation, drop images to docs/images
  • highlight certain elements in screenshot
    • how to filter on bin/test -s to find module to run, -t picks individual acceptance tests - via labels on robot tests
Rob Gietema
  • coverage for buster
  • upstream buster package was broken - fixed
    • weird issue - line numbers were offset - fixed
  • test set up for buster tests
    • libs, source for tests
    • specify extensions
    • coverage options - number of times a line has been called - does not work with jenkins 
      • created new report for coverage xml based “enterprise”
    • can have different xml files per browser

Layout

David Glick/Nathan Van Gheem/Gonzalo Almeida
  • demo
  • dnd layout of tiles on a page (deco page)
  • edit mode - two rows and two columns: resizeable, moveable, add new row
    • add a tile: (texttile) 
  • todo: add a column, have col divide itself by two (I think this is done as of 09/24)
  • multiple tiles in a col, reordable
  • must move tiles from col to be deleted
  • can’t delete last column
  • building deco ecosystem: templates
Rok
  • fixed modal - dynamic height
  • patched bootsrap
  • fix tile urls, VHM will work!
  • added bootstrap.js for p.a.toolbar test creation of iframe
  • configure new tile with a new icon almost working
  • lots of little tests all day
  • need to be drunker to finish tests

 

Image Tile - Ian Anderson, Andy Leeb
  • image traverser
  • white list stuff for overlay so buttons clicks don’t get swallowed
  • custom widget
  • image scaling

Documentation

Calvin Hendryx-Parker
  • buildout deco docs
  • automatically pulls readmes into a central location, combines some as they make sense
  • add end user docs w/screenshots
  • templer setup
  • github pages sites sphinx documentation submodule no need to switch branches, breaks jenkins tho…
    • (git submodule init)
Left to do:
  • Finish image tile, text tile (TinyMCE), merge branches, finish uat, David Glick will relelease packages in the next couple of weeks, dnd bugs
  • Layout has essentials, probably corner cases exist, get people to build stuff with it and report back
Chris Calloway
  • all must blog on coactivate site
  • give your own view of the sprint, how you see it or what you did 
  • get an idea of what it was, how you see it

Too Many Possums

Retrospective

  • we got the ecosystem in place
  • keep it (sprint) off season
    • closer to Plone Conf for European folks
    • longer sprint 4 - 5 days (thurs - tues)
    • right size group good focus
  • Invitational only? find contributors, maybe less known
  • maybe bring in a couple new folks to get them up to speed
  •  

 

 

 

Filed September 24th, 2012 under Technical, Report

Sea Sprint Report Out Day 1

UI Team - video conf with UCLA UI/UX

  •     editing consistency b/t tiles and metadata/schema content
  •     rethinking in-line editing -> expand it to metadata, consistent inline editing
  •     editing experinece consistent with Deco
  •     overview context - use overlay for specific action on context, contents tab should not be overlay, no overlay for context change
  •     other tech issues w/overlays
  •     place boundary on using overlays
  •     toolbar - on top
  •         what is site wide
  •         what is contextual
  •         identify actions as global or contextual
  •     p.a.toolbar - too many overlays?
  •     UCLA shared doc on good UI practice

Acceptance Testing - plone.app.toolbar

tests for:
  •     toolbar shows up
  •     items in toolbar
  •     elements in toolbar
  •     10 passing tests 2 fail started with 2

Layout - David Glick, Nathan Van Gheem, Rok Garbas, Gonzalo Almeida

  •    dnd cols & rows on layout
  •    not implemented a grid system yet everything is 100px
  •    red lines are drop zones currently

Rob Gitema - Buster Tests for Deco

  •     most of deco is covered now 41 tests!
  •     dnd is not covered currently moving target
  •     wired in a way to run buster tests in eggs in buster.cfg, in jenkins
  •     jshint

Clayton - plone.app.tiles coverage

  •     upgraded bootstrap in plone.app.toolbar

Calvin

  •     api - documentation, sphinx
  •     narrative next

Image tile - Andy Leeb, Ian Anderson

  • now uses namedfile (again!)
  • added event listener for IObjectModified

Rok

  •     TinyMCE is working
  •     styles working
  •     buttons, configuration

Eric

  •     selenium robotframework - configure jenkins for them
  •     jenkins grid - different servers with different browsers
  •     “I had to white list about://blank to download firefox. That should answer everything”
  •     windows is that bad

Timo

  •     unit tests for plone.tiles never really worked at all, fixing them
Filed September 23rd, 2012 under Technical, Report
Next Page »