Skip to content
This repository has been archived by the owner on Nov 9, 2022. It is now read-only.

Meeting 2013 08 19

Jump to bottom
Eric Bollens edited this page Aug 19, 2013 · 7 revisions

Meeting Information

  • Location: Math Sciences 5907
  • Date/Time: Monday August 19 from 1:00 to 2:00 PM
  • Conference Line: 888-921-8686 #3102061670

Attendees

  • Eric B (UCLA)
  • Alfonso R (UCLA)
  • Alex W (UCSD)
  • Logan F (UCSB)
  • Jeff R (UCSC)
  • Lloyd N (UCLA)
  • Brett P (UCSD)
  • Jeff L (UCLA)
  • Chris P (UCLA)

Agenda

Community

MMWCON

  • Three weeks away (September 10 - 12)
  • Schedule has been finalized
  • Currently 62 local attendees and 4 remote attendees signed up

Outreach

WebBlocks 1.0

Version 1.0.09 released several weeks ago

Changes included:

  • Improved Javascript compile reliability with semi-colon insertion
  • Fixed bug with flat-ui dark color variation generation
  • Added Rake helper tasks test:unit and test:build
  • Added debug mode as an option in the builder
  • Added flat-ui extension as an option in builder
  • Edited submodule doc for correct WebBlocks-ie.scss setup step

Version 1.0.10 has not yet been defined

WebBlocks Build Server 1.0

Released v1.0.00 with following changes since last meeting:

  • Added enable/disable toggles for all operations
  • Added absolute path support
  • Improved repo hashing to include WebBlocks repository path and version

Release v1.0.01 with additional changes:

  • Added complete set of tests for app routes
  • Fixed bug with view helper now throwing status code
  • Tweaks to exit traps

UCLA IT Services getting ready to stand up a build environment

WebBlocks Roadmap Discussion

Semantic Versioning:

The current roadmap as listed in the docs:

  • User Interface Elements Several elements, such as Entity/Nav/Bar, will receive overhauls, while new elements will be added such as mega-menus, tabs, pills, mastheads and layout arrangement helpers such as galleries and prioritized content semantics. Additional Extend modules will also be added for niche functionality such as responsive tables and typography.
  • Compiler The compilation process will be optimized to reduce compile times, and new features such as watch and partial builds will be added. It will also be made easier to attach packages, modules and adapters without adding handlers to WebBlocks directly.
  • Module Architecture Namespaces will be reorganized to provide greater flexibility regarding elements compiled into a build. New SASS pre-compiler directives will be added for conditional requires and to force a determinant load order to guarantee the intended cascade. Javascript precompiler directives will also be added for greater dependency control.
  • Element Configuration Existing configuration options will be streamlined, and some will be renamed, for better clarity. New configuration options will also be added for further element customization. Build Optimizations Precompilers are known for generating redundant CSS, and WebBlocks is no exception. Module implementations will be revisited to reduce CSS size, and packages will also be added to provide greater CSS, Javascript and image optimizations.
  • Adapters Integration of WebBlocks settings into Bootstrap style generation will be improved, and additional adapters to other third-party frameworks may be added. Packages New packages will be added as submodules, including additional common libraries, expanded effects drivers, responsive media and browser polyfills.
  • Compatibility Support Modifications will be made to the architecture to allow for finer-grain compatibility targeting rather than just two-tier allocation into primary and IE stylesheets.

So what's the problem?

  • Semantic Versioning will not let us roll significant architectural changes into v1.1
  • Going straight to v2.0 may take too long for some stakeholder needs

New proposed approach:

  • v1.1 - Dec 2013 - new content types
  • v2.0 - Apr 2014 - architectural changes

Which content types will appear in v1.1?

  • This is an open question
  • Eric is engaged with IT Services on their CMS portal - which will advise some
  • We've already got some in the issue tracker as well
  • Community should nominate things that they want to see in v1.1
  • If it has an issue in the tracker, post on it
  • If it doesn't have an issue, create one
  • Meeting in two weeks, we'll focus on this question and define exactly what goes in from the backlog

What will change architecturally in v2.0?

  • WebBlocks currently defines four different modular primitives:
  • Packages - Third-party plugins checked out as Git submodules
  • Adapters - SASS and Javascript code that binds a package to WebBlocks
  • Extensions - Custom SASS and Javascript loaded into WebBlocks before your own sources
  • Modules - Sub-divisions of SASS and Javascript that are included by way of a configuration directive
  • Arose because of organic growth, not because it was right
  • Confusion arises when trying to explain these differences to people
  • No reasonable software engineering reason to keep them separate
  • Goal is to turn everything into modules
  • Bower for module-level dependency management
  • Module definition file for file-level dependency management - much more flexible than Bower
  • Compiler linker step will work by generating DAG and then topologically sorting
  • Strongly linked components can be compiled into sub-files for SASS/Compass compile cache benefit
  • Advantages are:
  • No more confusion between all these different types of modularized entities
  • Adapters will be bounded to the elements they define rather than in their own component
  • Much greater flexibility regarding how a module influences compilation
  • Possible to compile a module all on its own - meaning a bunch of mini-frameworks
  • Optional wether the complexity of the definition + implementation layer is needed
  • Simple to add your own modules, as opposed to current system
  • Overhaul should allow us to refocus on speed of compile

Some early experimentation is in https://github.com/WebBlocks

  • Concept is that "core" is the compiler core and "toolkit" is the skeleton a user usually checks out
  • Have not implemented the Ruby DSL for the module definition file yet

Discussion

  • Jeff R: Can Grunt figure into this?
  • Eric B: Yes, as a call-forward, similar to the Rake call-forward (see Integration/Submodule docs)
  • Jeff R: Will the watch command be supported?
  • Alfonso R: Seconds this as "critical" to getting greater support - simpler and easier
  • Eric B: Yes, this should be built in - viable given the strongly-connected caching speedup of compile
  • Anfonso R: Can we make it easier to do CMS dynamic CSS assembly (such as Moodle)?
  • Lloyd N: Drupal also supports but not currently using it
  • Eric B: Same with Plone.. We should definitely look into this further
Clone this wiki locally