Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

1.8 Release Sprint

geojeff edited this page · 132 revisions

Sprint Dates are Friday, Feb. 24 through Monday, Feb. 27 (But we can continue as we can up until the release):

Procedures

Please monitor and read this wiki page and those linked to it, and use the mailing list thread and irc to communicate with one another about adding tasks, volunteering, scheduling meeting times for group work on tasks, etc. There are wiki pages for individual task topics, ready for taking notes and updating with progress reports (especially one at the end to summarize work).

When you make a comment on a wiki page, most commonly as a bullet item, you can prefix it with your nick, e.g.

  • [geojeff, AddressBook] Some comment about the AddressBook app...

Find a topic you want to address, propose it if it isn't listed yet. Please email geojeff@sproutcore.com or catch him (geojeff) in irc to volunteer for specific task topics, or to ask for other assistance regarding the sprint.

IRC channel to use: #sproutcore

SproutCore mailing list: http://groups.google.com/group/sproutcore

Preparation

Preparation for running Master for Sprint

Until there is a new gem release (as of the week of the sprint, and probably during the sprint), in order to run against a clone of master in your apps frameworks directory, you need to install the latest abbot.

Here are instructions, which will be valuable even after we get proper installers:

On OSX: https://gist.github.com/1760855 (used by geojeff and others), https://gist.github.com/1928558 (used by wesw02)

And for Linux: https://gist.github.com/1860325 (used by unicolet)

If you do the bundler steps in those instructions to create SC command line tools in, say, myapp/bin, you can then check things by doing:

  cd ..
  ./myapp/bin/sc-init helloworld
  cd helloworld
  ../myapp/bin/sc-server

And, you should have Hello World up. You can also hit http://localhost:4020/sproutcore/test_controls to check that. Then you should be good to go on other things.

But, don't forget to run sc-server from that bin directory (.../myapp/bin/sc-server) -- otherwise you will get the globally installed sc-server in an installed gem, if you have one.

Preparation for using the SproutCore Guides (sproutguides) system

http://sproutcore.com/guides/contribute.html

You can use the wiki pages to do prep work if you want, if there is a need to collaborate. You can also share your github account where you have the guides with collaborators.

Either way, the end game is to prepare pull requests if you can, but just having wiki notes might be the way to solve some tasks.

Participants (Please let me know if I missed anyone; This was updated after a survey of what was accomplished -- geojeff)

  • Rodrigo Basa (rad)
  • Jason Dooley (jdooley)
  • Tim Evans (tce)
  • Topher Fangio (topherfangio)
  • Michael Gillogly (seze)
  • Evin Grano (etgryphon)
  • Tyler Keating (publickeating)
  • Michael Krotscheck (Krotscheck)
  • Maurits Lamers (mauritslamers)
  • Mahesh Mukundan (maheshm)
  • Luke Melia (lukemelia)
  • Umberto Nicoletti (unicolet)
  • Jeff Pittman (geojeff)
  • Rajesh Segu (rajeshsegu)
  • Wesley Workman (wesw02)

Documentation Task Topics:

Getting Started Pages

  • PRIORITY This covers the landing pages, enumerables, view pages for both traditional and template-based views. [geojeff, mauritslamers, publickeating, tce, topherfangio] This one got some of the most work.

Sprint Results:

The plan is to rewrite the guides getting_started pages as follows (getting_started, getting_started_2, and getting_started_3 were accomplished during the sprint, plus the new Todos app):

getting_started is the first page, covering

  • Install SproutCore on your machine.

  • Use the SproutCore tools to generate a basic starting application. (TodosOne)

  • Run the SproutCore development server to test your application.

  • Modify the application to ensure your changes are visisble.

getting_started_2

  • sc-gen statechart_app TodosTwo

  • basic layout with statechart.js and states/ready_state.js

getting_started_3

  • sc-gen statechart_app TodosThree (A more complete, best-practices app)

  • How an app is organized into views, controllers, a statechart, and models,

  • How bindings and actions coordinate views with a controller system, which includes a statechart,

  • How the controller system ties to models,

  • How SproutCore contains powerful programming constructs.

getting_started_4

A tool called repo-builder (http://github.com/geojeff/repo-builder) was written to extract code blocks, shell commands, and git commands from a given guides textile file. After parsing, repo-builder writes out a git repo, doing the shell commands and file edits/adds, interspersing git commands and commits, per the order in the textile file, to build a repo as if it had been done manually. The assures that code in docs is the same in sample apps, and enables freer updating.


PLUS we made notes and did other useful work as we went during the sprint, some of which is shown below here (some notes are not up-to-date with the above summary):

  • mauritslamers has suggested that these landing pages ask the new developer to manually make directories and files, to better register the layout and design. However, with the new, now more substantial Todos app approach, this is not practical. So, the new guides page attempts to leverage use of sc-gen to lessen the load on the new developer who wishes to do it all manually. The new guides page is written as if they are doing it manually, but we can expect that most devs would chose to clone or copy the code and examine already made directories and files as they read.

Traditional Views Coverage

  • [seze] Add info covering FlowLayouts

  • [seze] Add more info covering layouts in general, discussing how child views can't display outside the bounds of their parent view, and how child view layout positioning is relative to the parent view container. Examples similar to this would be helpful as well. ( I'm assuming that this is a true statement based on my observations, needs verified by someone with more experience)

Core View Concepts page (AddressBook App)

  • [geojeff] The existing view concepts page has an AddressBook app: Core View Concepts. Code for this app on the existing "Core View Concepts" guides page was used to create an actual app: https://github.com/geojeff/AddressBook

  • [geojeff] Rename CreepyApp to something less odd; Replace names of real people with made-up normal names

  • [geojeff] Make AddressBook a real functioning app that can be checked out from github; Pull code samples from the real sample app.

  • [geojeff] Make PersonView a generic view, instead of the one-off real-person-specific view [To be done by Krotscheck, who will update AddressBook]

Template-based Views

Current page for template-based views is: Using Handlebars

  • [geojeff, Friday] Per recent discussions, move template-based view coverage after a traditional treatment. I just saw a comment in a mailing list thread expressing surprise at this order of presentation, and there are pros and cons, but I checked on previous discussion and see an agreement to go back to SproutCore's roots for a focus on traditional views, with template-views as an alternative, without setting any de jure style of rendering. In an email thread recently, I referred to templates as being kept as a "first class alternative", but when I look back at notes from discussions I see variation in opinion -- whether the distinction between traditional and template views is even that valid (See Tyler's "unification" proposal, now closed; next bullet item), ranging to a preference that templates should be moved to a kind of add-on framework. In no case, in my opinion does it make sense to pooh-pooh templates -- it is a different approach that fits certain use cases. So, for the sprint, I think that we can do the rearrangement of the presentation, and leave the sorting out of the mechanics for later.

  • [geojeff, Friday] There is really good information in this now-closed proposal to unify traditional and template views (Again, how this is solved doesn't matter so much for the need to tweak the docs in the sprint; In this and in other github discussions, we may find good info on the merits of templates, etc.) https://github.com/sproutcore/sproutcore/issues/690

  • [geojeff, Friday] We could do a templates treatment for a https://github.com/geojeff/TodosTemplates app, starting with code in the new Todos. follow this TodosTemplates Activity Log

    • [geojeff] NOTE: Development of this as a separate app is now ON HOLD because it was realized that the sc-init new app -template switch (and the current guides docs) make a directory structure layout that is different from the traditional. So focusing first on the Todos app, which will have core.js, main.js, resources/main_page.js etc. -- templates can be added INTO this structure perhaps.

Models/Records/Store

PRIORITY This one was not addressed.

Theming

This one was discussed, but the theming part will likely go into the TodosFour sample app and the getting_started_4 guides page.

Notes on my past experience with SC.Button Theming [Seze]:

I was trying to create my own custom buttons that I would use in a toolbar. I made some basic images in Photoshop, expecting to be able to use basic CSS to handle all the button states and interaction. The issue I ran into was that the default button had certain styles added to it that I couldn't easily reset. What I really wanted was a blank slate to work with. It was suggested to me to just create my own theme for my buttons, but I didn't want to lose the original button styles. I tried creating a sub-theme for my buttons, but I was still unable to disable some of the default theme styles. I then dug into the Sproutcore source to see how it was creating the styles. What I found was that there are actually different types or sizes of buttons setup in the default theme. Each size was just a separate sub-theme. I then created a new sub-theme for my style of buttons, and set the controlSize of my buttons to the name of my sub-theme. Doing this disabled the default button styles, which gave me a blank slate to work with.

I think it would be a good idea to state in the theming guides for what the best practices are for when to create your own theme (use when you want to replace absolutely everything), create a sub-theme and apply using classNames or themeName (use when you want to adjust the default styling), or create a sub-theme and apply using controlSize (use when you want to create new style completely from scratch). My experiences are limited to SC.Button, but I think would be relavent to any control that implements the controlSize parameter.

  • API Docs PRIORITY Regenerate? Check for recent changes? Identify problems? This one was only discussed.

"Eat our own dogfood" Role-playing Task Topics

PRIORITY [maheshm, rad] This one got some action by maheshm and rad, but there wasn't much time to look at results; Still they gave important feedback for the getting_started pages writing.


[rad] Todos app has unexpected behavior when focus is redirected from text input box.

  • Load Todos app
  • Type a task, click anywhere in the page. Click on text input box. Focus goes back to text input box.
  • Type a task, press enter/return. Works.
  • Type a task, click Add button. Works.
  • Leave text input box blank. Click anywhere in the page. Add button becomes disabled (grey). Text input box cannot be clicked and get focus. This goes for about 30 seconds before the text input box gains focus and the Add button becomes enabled (blue).

Tested on the following:

  • Safari 5.1.2 on OS X 10.7 - Fails as described above
  • Firefox 8.0.1 on OS X 10.7 - Fails as described above
  • Firefox 10.0.2 on Windows 7 - Fails as described above
  • Chrome 17.0.963.56 on OS X 10.7 - Fails as described above
  • Chrome 17.0.963.56 m on Windows 7 - Fails as described above
  • IE 9.0.8112 on Windows 7 - WORKS!

[tce] Are these bugs being tested against master? Also, @rad, when the button becomes blue, it's because it's the default responder, not because it's enabled. The button is actually always enabled.


[rad] Regarding debugging sproutcore apps using the javascript console. I followed the new_todos tutorial, but I made a typo. In resources/main_page.js, I mistyped "SC.AutoReisze". This naturally resulted in a blank browser window and errors:

Safari

SC.Object.extend expects a non-null value.  Did you forget to 'sc_require' something?  Or were you passing a Protocol to extend() as if it were a mixin?
TypeError: 'undefined' is not an object (evaluating 'Todos.getPath( 'mainPage.mainPane' ).append') -- showing_app.js:3

Firefox

uncaught exception: SC.Object.extend expects a non-null value. Did you forget to 'sc_require' something? Or were you passing a Protocol to extend() as if it were a mixing?
Todos.getPath("mainPage.mainPane") is undefined -- showing_app.js:3

Chrome

Uncaught SC.Object.extend expects a non-null value.  Did you forget to 'sc_require' something?  Or were you passing a Protocol to extend() as if it were a mixin?
Uncaught TypeError: Cannot call method 'append' of undefined -- showing_app.js:3

It may be expected of a Javascript programmer, but it might be good to point out early on in the tutorial that the errors the console lists might not directly reflect the problem in the code. In my case, the mainPage object was not properly instantiating thus the problem lay in resources/main_page.js. Knowing now that it was a typo, I half-expect an error stating that SC.AutoReisze is undefined, but I don't get that error.


[maheshm] I loved the comments provided in the code. It helps the beginners a lot. It would be great if there are more comments in main_page.js and in completed_todos.js (esp regarding the property)

Code is working fine in FF 7.0.1 in Ubuntu 11+ except for that the textbox is not properly shown. Will try to fix it.

New Guides Pages

  • Sample Apps This would be a page with description blurbs for several sample apps to show variation in approaches, ideas for best practices, discussion, and with links to the github repos for the sample apps. Start with the TestControls app, then to the sample apps. [tce, nicolet, geojeff] Great to find out about Mappu, and to discuss ideas about how to present them.

  • Build Tools Write a guides page to describe the use of build tools such as sc-gen, sc-init, sc-server, ... [publickeating] Wrote a new guides page and added a draft in sproutguides.

  • Class Names List that can be targeted for each UI control (to make it easier for styling, and to avoid having to do DOM lookup) [Krotscheck] Not addressed.

  • Deploying [geojeff] Not addressed.

Resources Searching and Tabulation

  • For these general topics, everything under the Sun is fair game -- see what the user will find in searches, see what they encounter on a best guess path through the guides pages for a topic, and what they might find, or might even need, elsewhere.

  • Old Wiki Gleaning As a focused search through the old wiki, making notes / links in the wiki to identify portions that are still needed and relevant. If the old wiki is kept, perhaps we can make a new guides page as an interface to it. If the old wiki is deleted, we need to pull out the good stuff for guides pages. Not addressed.

  • Statecharts Statecharts is such an important topic, but the docs are scattered all over. Find and tabulate resources, comparing inline docs with what is found on blogs and on the mailing list. Perhaps the solution is to update the inline docs so that they are the canonical source, perhaps even including links to old blog posts. Not addressed.

  • Views As for statecharts, there is great information found on blog posts and the mailing lists. Accumulate links and short descriptions at least. Not addressed.

Codebase Task Topics:

  • Real-world app testing against 1.8 PRIORITY (Specifically kick the tires of 1.8 against proprietary or in-house testing apps) [geojeff, lukemelia, unicolet, wesw02] This one got a lot of important action.

  • Write tests Not addressed.

  • Validators (might not be a sprint task, if mitchless is not able to participate) Not addressed.

Specific Frameworks Task Topics:

  • sproutcore-upload (docs, use case descriptions, hacks) [topherfangio, geojeff] Not addressed.

  • media (does HTML5 audio/video playback in Safari now, but needs work for Chrome, etc.) [Krotscheck] Overcame installation and configuration battles, and made progress.

  • experimental (e.g., split_view -- ready for prime time? other frameworks in experimental?) [geojeff, jdooley] Split view differences investigated.

1.8 Release Task Topics:

(Don't have to prioritize, because several of these have to happen)

  • outstanding pull requests, especially important ones for 1.8 release [etgryphon, publickeating] Several pull requests were attended to during the sprint.

  • blog / mailing list release announcement preparation (Needs to incorporate sprint outcomes/determinations) [publickeating] NOTE It would be a good idea to update the main SproutCore README file with the names of people who are new committers or who have helped out recently -- especially during the sprint. Perhaps these contributions can be celebrated in the 1.8 announcement. Will wait for release time.

  • SproutCore Installer / Gem preparation and testing [seze] This one got a lot of discussion -- great to see progress by seze on employing the rack file in abbot.

  • Gem install / Bundler Instructions and testing [geojeff, unicolet, wesw02] Instructions were put in several gists, and several people used them. Frustrating, and it will be good to have installers, but there is value in seeing command line histories in the gists.

  • Demo Apps

    • Github-hosted Demos: tce has instructions for doing deployment to github, as follows:

      • [tce] started with blank app, sc-init LearningSc, which made a learning_sc dir, with Buildfile, README, and apps dir

        1. git branch gh-pages
        2. git co gh-pages
        3. Add the directive :url_prefix => '<GITHUB_APP_NAME>/static' to the root Buildfile
        4. sc-build <YOUR_APP_NAME>
        5. mv tmp/build/<GITHUB_APP_NAME>/static ./
        6. cp static/<YOUR_APP_NAME>/<SHA>/index.html ./
        7. git add static
        8. git add index.html
        9. git ci -m "Hosting my app on Github"
        10. git push origin gh-pages

Or use tce's script:

Deploy script for hosting tagged versions of the todos app on github.

Simply run ./deploy and it will checkout gh-pages, update it's references and create a directory (and built app) for each tag.

!/bin/sh

git checkout gh-pages
git reset --hard origin/master

for tag in $(git tag);
do
    git checkout $tag
    echo "config :all, :required => :sproutcore,
                       :url_prefix => 'todos/$tag/static'" > Buildfile
    rm -rf tmp
    echo "Building todos/$tag..."
    sc-build todos
    build_number=$(sproutcore build-number todos)
    cp -R tmp/build/todos/$tag ./
    cp $tag/static/todos/en/$build_number/index.html $tag/index.html
done

rm Buildfile
git checkout Buildfile
git checkout gh-pages

for tag in $(git tag);
do
    git add $tag
done;

git commit -m "Host todos on Github"

Housecleaning: Check the apps that show at demo.sproutcore.com -- There are outdated apps on there, and out-dated test_controls, Greenhouse, etc., that may need to be removed as well. demo.sproutcore.com can just point to the fresh github-deployed instances we wish to run, via the steps above. Not addressed.

Items Deferred to 1.8.x

1.8 should have fixes done to "get it out," so there might be some not-so-big, but not-so-critical changes that come up, that could be listed here to help us sort things out.

  1. [unicolet] improved IE support (even only for versions >= 9), not high priority on mybook, but perhaps important to new developers

Wiki Help

Use github wiki help, or ask in irc. If you need to make new wiki pages, remember that the file system is flat , and we should start all pages with '[https://github.com/sproutcore/sproutcore/wiki/1.8-Release-Sprint] and tag on a subtopic name following the pattern of the task topic page. For example, say you are working on the statecharts topic. The page for that is '[https://github.com/sproutcore/sproutcore/wiki/1.8-Release-Sprint-Dev-Learning-Statecharts]. If you wanted to add a separate page on concurrent states, you would add something like '[https://github.com/sproutcore/sproutcore/wiki/1.8-Release-Sprint-Dev-Learning-Statecharts-Concurrent-States]. You can read the help pages on how to make links to pages. Basically you use square brackets around the link text, with the URL in parentheses abutted just after.

Something went wrong with that request. Please try again.