Based on this thread I was able to get airbrake.io working with browsercms 3.1.2.

Below is a “tweak” using my tweaks gem. The important point for getting it to work with browsercms is to hack the error handler to store the exception in request.env[‘rack.exception’]

Its also an example of how a tweak can be a Rails Metal app. This is Rails 2.3.8.

# tweak for adding airbrake to bcms sites
#
# * includes a hack to get airbrake working with browsercms
# * airbrake configuration can be passed into tweak
# * environment.rn should contain :
#
#     config.gem 'airbrake'
#
# Sample tweak config :
#
# Tweaks.configure(
#   :airbrake,
#   :development_environments => [],  # required to enable airbrake in rails development mode for debugging
#   :api_key => 'sdhfjdhsfkdsfhfjksdfhjfjksdfjh'
# ) if RAILS_ENV=='production'

class RackBuzzAirbrake < Rails::Rack::Metal

  def initialize(aApp,aConfig)
    #super(aApp)
    @ab = Airbrake::Rack.new(aApp)

    Cms::ErrorHandling.module_eval do
      alias_method :orig_handle_server_error, :handle_server_error
      def handle_server_error(exception)
        request.env['rack.exception'] = exception
        orig_handle_server_error(exception)
      end
    end
  end

  def call(env)
    #@app.call(env)
    @ab.call(env)
  end

end

Tweaks.define(
  :airbrake
) do |cf,name|
  require 'airbrake'
  Airbrake.configure do |config|
    cf.each do |k,v| 
      config.send((k.to_s+'=').to_sym,v)
    end
  end
  ActionController::Dispatcher.middleware.use RackBuzzAirbrake,cf
end

lftp is an advanced ftp client for UNIX. It supports many variants of FTP, including “explicit mode” FTPS also known as “ftpes” as required by bigcommerce.com. lftp is also scriptable - with the -f option you pass a script file of commands to execute.

Note that lftp must be compiled with ssl. You can check this by typing

lftp -e 'set -a;exit' | grep ftp:ssl-allow

and you will see the following if you have ssl compiled in

set ftp:ssl-allow yes
set ftp:ssl-allow-anonymous no

Now create a file called script.lftp with the following content :

#debug  # optional for debugging info
set ftp:ssl-allow-anonymous yes
set ssl:verify-certificate off
set ftp:passive-mode on
set ftp:ssl-force on
set ftp:ssl-allow on
open -u <username>,<password> <server>.bigcommerce.com
lcd <local_dir>
cd "/content"
put <local_filename> <remote_filename>
exit

The fields in angle brackets need to be replaced with your specific info

Now execute it with :

lftp -f script.lftp

Enjoy !

brew install lftp

brew edit lftp // see http://stackoverflow.com/questions/3939651/how-to-modify-a-homebrew-formula

make the file look like this :

require 'formula'

class Lftp < Formula
    url 'http://ftp.yars.free.net/pub/source/lftp/lftp-4.3.3.tar.bz2'
    homepage 'http://lftp.yar.ru/'
    md5 '91757a201c1030714ac1996f27437cc7'

    depends_on 'pkg-config' => :build
    depends_on 'readline'
    depends_on 'gnutls'

    def install
        # Bus error
        ENV.no_optimization if MacOS.leopard?

        system "./configure", "--disable-dependency-tracking", "--prefix=#{prefix}", "--with-included-readline=auto", "--enable-nls", "--with-openssl", "--without-gnutls"
        system "make install"
    end
end

brew uninstall lftp

brew install lftp

I am developing my first mobile app with Adobe Flex 4.5.1 for Mobile and the cool Eskimo library from PIA (http://e-skimo.com/). I am using the DeleteableList control since I think it provides exactly what is required for many simple mobile “lists of things” - that is clickable text names, plus the ability to delete.

However I discovered that it didn’t size very well - when you have only a couple of items, the control is some arbitrary minimum size, and below your items is just blank space. Seeing as screen real estate is paramount in mobile, this isn’t exactly ideal!

So I set out to fix it, and here is what I found :

• DeleteableList uses the Adobe sdk skin “spark.skins.mobile.ListSkin” (not to be confused with “spark.skins.spark.ListSkin”)
• DeleteableList gets its size from its skin, and ListSkin gets its size from the embedded Scroller and then DataGroup
• The DataGroup has a VerticalLayout, and on line 125 of sdks/4.5.1/frameworks/projects/mobiletheme/src/spark/skins/mobile/ListSkin.as we see “layout.requestedMinRowCount = 5;”
• In my opinion this is a bug

To fix it, in a createComplete handler you can do :

var sk: spark.skins.mobile.ListSkin = list.skin as spark.skins.mobile.ListSkin
sk.dataGroup.layout['requestedMinRowCount'] = 0

Enjoy!

Note

This article was written while researching development of a non-Mobile application. Flex Mobile skinning follows the same approach, but has many differences with greater constraints (especially greater emphasis on Actionscript over MXML), less features, and replacement classes (eg. for text rendering) in order to achieve decent performance on less powerful mobile devices. See http://www.adobe.com/devnet/flex/articles/mobile-skinning-part1.html for specifics.

Background

1. The Flex 4 component architecture is designed so that the visual appearance of each component is provided by a separate, but associated “skin” class, that can be created in various ways by a designer or developer.

2. A designer using Flash Catalyst can select some artwork, then convert it to a skin class, specifying the standard component it should map to. This class library can be used in a Flash Builder project.

3. A developer can easily use the “New…” menu item in Builder to create a skin class based on a standard template. This generated class descends from a generic skin class, and includes a non-trivial amount of code.

4. Skins are responsible for rendering their children.

5. Skin parameters can be given in CSS, then used by the skin code.

6. Flex 4 has some very significant improvements in CSS, including more advanced selectors

7. For a custom component to appear in Catalyst for skinning, it must follow some strict rules, including being developed in AS3 not MXML. http://www.adobe.com/devnet/flashcatalyst/articles/flashcatalyst-compatibility-checker.html, http://learn.adobe.com/wiki/display/fcc/Flash+Catalyst+CS5.5+compatibility+schema and http://www.slideshare.net/danorlando/360flex-2011-optimizing-the-designer-developer-workflow-using-flash-builder-4-flash-catalyst-cs5 slide 18.

8. A very useful ability of Flex is the simple separation of areas of an application UI into reusable components containing subcomponents. These can be skinned as a whole, but it is quite complex and ultimately not worthwhile. Instead the container can be skinned as simply a container, and then the subcomponents skinned separately. CSS allows selecting of subcomponents just like in HTML. Also the subcomponents are likely to be standard components anyway, so can be skinned accordingly, not treated as special because they are inside a container.

9. Some discussion on the web says that compared to Flex 3, Flex 4 skinning makes some simple things much harder, but advanced things much easier.

10. Builder generates AS3 skins, subclassing Skin, SparkButtonSkin and probably others.

11. Catalyst generates MXML skins, subclassing Skin and adding states and drawing code.

The issues

1. The standard components and skins are lacking basic functionality

Flex 4 skins don’t have as many configurable parameters as Flex 3 components, and you are often forced to use skinning even for some trivial customisations

eg. the Flex 4 Button lets you change the text color, but not the background color in CSS

2. Adobe implicitly encourages skins to be created as application specific, without inheritance or linking in shared code

Builder generates code from templates for the standard components, and this code will therefore be repeated for each custom component you create. Like any code this needs to be maintained, debugged etc and violates DRY (Do not repeat yourself). If Adobe later updates their template for this code, your components will of course not be updated.

Skins created in Catalyst don’t use CSS at all eg. to seperate out assets or colors from rendering code. Please consider and support users in creating configurable components (via CSS), and properly supporting inheritance to maximise reuse.

3. Round-tripping is not the Holy Grail

There is no need for both Builder and Catalyst to be able to edit the same application or library project, and this is an enormous task for Adobe to implement, full of gnarly issues now and into the future. Anyway, developers are quite capable of using Flash Catalyst if necessary, and probably already have or could be given a license to do so. Flash Catalyst applications or libraries only really need to be edited by Flash Catalyst.

Instead we need a linear workflow from designer to developer. The designer should be able to open and edit the FXP/L file as they need, without interference from the developer (although the developer would need to occasionally view and edit). When a developer gets the latest FXP/FXPL by updating from version control, ideally they would be able to rebuild the application in Builder and see the result including the latest FXP/FXPL. This would mean allowing Builder to link in (not import) an FXP/FXPL from Catalyst. Manual exporting and importing is a timewaster and error-prone.

Supporting the FXP format in Builder and encouraging its use in workflow tutorials means that its very easy for developers to do things inside a FXP that are valid in Builder but will make them incompatible with Catalyst. Imagine spending hours on skins that work fine in Builder, only to find you have ruined compatibility with Catalyst and your designer. Adobe provides a compatibility checker to assist in avoiding this, but it is still a productivity risk. Developers shouldn’t try to be too clever in an FXP.

4. FXPL is not a real project format in Catalyst

FXP is the application project format for Catalyst. It is equivalent to a zipped Builder application project. Builder can also load, save and edit FXP files. Catalyst also provides some support for the FXPL format, which is equivalent to a zipped Flex Library project. In Catalyst however, FXPL’s aren’t real projects. You can’t open or save them - you import them into your FXP, or you export your FXP as a FXPL. This is a fundamental faux pas - applications and libraries are different animals - its going to end in confusion when designers unwittingly export one as the other type.

In Catalyst, importing an FXPL does not link the given library, it merges a copy of its files into the current project, once again violating DRY. And so if we are using Catalyst and want to make a minor change to an FXPL, we must begin with an FXP, import the FXPL, make the change and export to FXPL. Presumably the result won’t just have our minor change, the whole FXP will be included too. Catalyst does not support linking of libraries of any sort into an FXP.

On the Builder side, we can import an FXPL from Catalyst into a Builder Library Project, and that seems like a potential way of working intelligently with a version control system, doing a roundtrip to the designer and back using FXPL as a transport format, and checking it in on each return, and perhaps throwing away the FXPL. But it is a manual process for the designer to pass it over, and the developer to receive it. Ideally the designer would just open, save and edit an FXPL, and potentially export a swc for simple linking into the Builder application.

5. FXP/FXPL files are not version control system-friendly

Being zipped into a single file defeats the merging abilities of version control systems like subversion or git. It means that if a designer and developer both modify a common Catalyst project, their changes cannot be automatically combined, and they will have to choose who’s project will be the next version, then apply the other’s changes to that. With a normal unzipped Builder project however, a version control system can merge changes automatically. Simply allowing Catalyst projects to operate on an unzipped folder would solve this problem, but admittedly tempt them into modifying and corrupting the contents without the tool.

There are also some issues with .svn folders being deleted by Builder and Catalyst. See http://kb2.adobe.com/cps/899/cpsid_89968.html

This is not a problem if we treat FXP/FXPL as merely a transport format (a concept I wouldn’t encourage), or if it is very unlikely that two users would work on the same FXP/FXPL at the same time.

6. Skins in Catalyst projects can’t be linked into the application in a Builder project.

We need to view and edit skins in a Catalyst project, then somehow link (not import) that into a Builder application project. Builder can link to SWC files and Flex Library Projects, but Catalyst won’t output a SWC, or work with FXPLs properly.

How to fix the situation

1. For now, use this script to compile FXP -> SWC

Catalyst projects are FXP. For linking into Builder, the ideal format is SWC. Therefore we need a simple conversion process from FXP -> SWC. Thankfully this has been solved here : http://www.rogue-development.com/blog2/2009/06/compiling-fxp-swc-a-catalyst-workflow

2. Develop a reusable set of components skins calling getStyle() instead of hardcoded values, drawing code or embedded assets.

The Flex 4 skinning model is actually a great opportunity for component developers as it completely separates the component logic from appearance and interaction. Most of the reasons we may have had for making a custom component in Flex 3, may only require a custom skin in Flex 4. This also means we don’t have to duplicate, maintain or replace component logic when are only interested in the appearance or interaction.

There is now an opportunity for the Flex community to develop open source skin libraries that replace the standard Spark skins and provide adequate customisability via CSS, such that a single skin can work for the requirements of most applications.

Messages to Adobe:

1. Please make the standard skins + CSS good enough for 90% of use cases. This would greatly reduce the need for skinning for general applications.
2. Round-tripping is not the Holy Grail. Linear workflows are easier to implement, and keep Catalyst accessible in its licensing and distribution to both designers and developers.
3. Please allow loading and saving of FXPL projects in Catalyst
4. Please allow linking of FXPLs into FXPs in Catalyst
5. Please allow building of FXPLs and FXPs to SWCs in Catalyst
6. Please allow linking of libraries into Catalyst
7. Provide a commandline method of compiling a FXP/FXPL to a swc
8. perhaps provide an option where a parallel swc is recompiled whenever the project is saved in Catalyst, for automatic linking into builder.

A small conundrum : For a designer to develop their skin classes, they need to lay out instances of them, compile, run and play with them. Normally this would require an application project, not library project ie an FXP. On the other hand, a library project is more like what we are trying to achieve - a project linkable into the application. This is solved by compiling FXP -> SWC, or if Catalyst fully supported FXPL projects, it could allow components to be dropped onto a pasteboard for experimenting with, and this pasteboard would not be compiled into the production SWC.

References & interesting links

http://www.developria.com/2011/01/as-a-developer-have-you.html

http://www.scribd.com/doc/54315969/85/Handing-off-to-developers

http://learn.adobe.com/wiki/display/fcc/Flash+Catalyst+CS5.5+compatibility+schema

http://www.rogue-development.com/blog2/2009/06/why-i-like-my-proposed-catalyst-workflow/