ActionScript Developer's Guide to Robotlegs. Building Flexible Rich Internet Applications Joel Hooks, Stray (Lindsey Fallow)

Dostępność produktu

Produkt nie został jeszcze oceniony pod kątem ułatwień dostępu lub nie podano żadnych informacji o ułatwieniach dostępu lub są one niewystarczające. Prawdopodobnie Wydawca/Dostawca jeszcze nie umożliwił dokonania walidacji produktu lub nie przekazał odpowiednich informacji na temat jego dostępności.

Spis treści książki

• ActionScript Developers Guide to Robotlegs
  • SPECIAL OFFER: Upgrade this ebook with OReilly
  • A Note Regarding Supplemental Files
  • Preface
    • Robotlegs: Something a little bit special
    • Who this book is for
    • Who this book is not for
    • Conventions used in this book
    • Using code examples
    • Safari Books Online
    • How to contact us
    • Acknowledgments
  • 1. Robotlegs is a lightweight framework for ActionScript 3
    • What does Robotlegs actually do?
      • Robotlegs is a communication-and-cooperation framework
        • Direct conversation
        • Passing messages
        • Robotlegs helps with direct conversations and message passing
      • Robotlegs makes use of three object-oriented architectural patterns
    • Do you need a framework at all?
      • Reasons to use a framework
        • Consistency
        • Common understanding brings easier collaboration
        • Peer-reviewed solutions
        • A well-tested skeleton
        • Less code to write
      • Reasons not to use a framework
        • Framework learning curve
        • Terminology confusion
        • Performance tradeoffs
        • Framework coupling
        • Black box code is hard to debug
      • Robotlegs aims to amp up the pros and minimize the cons
    • Less boilerplate code is a good thing...
  • 2. The Robotlegs dream...
    • 80% of the problems can be solved with 20% of the API
    • Coding for Robotlegs shouldnt tie you to the framework
    • Robotlegs aims to enable and not dictate
    • Most AS3 applications benefit from the MVCS approach
    • Testing, testing! (We test, and we make it easy for you to test)
    • Some final things every Robotlegs cadet should know
  • 3. Anatomy of a Robotlegs application
    • Joels Personal Kanban
    • Lindzs Mosaic Design Tool
    • How a Robotlegs application gets things done
      • Architecture begins with Events and Commands
    • Getting to grips with Robotlegs architecture
      • The context is the heart of your Robotlegs application
      • Your models and services are Actors in your app
      • The MediatorMap provides a way to join your views to your app layer
      • Robotlegs mediators are bridges, not view controllers
      • The CommandMap makes things happen
      • The shared event dispatcher joins everything together
        • ... and it goes a little something like this (event flow)
    • User stories as implemented in Robotlegs
      • Personal Kanban example: Moving a task from backlog to doing
      • Mosaic Design Tool example: Saving a design
      • The same but different
    • All of this is possible because of the Robotlegs Injector
  • 4. Automated Dependency Injection
    • So, what exactly is Automated Dependency Injection?
      • A dependency is just a requirement to use another object
      • You can fulfil a dependency in three different ways
    • You already use Dependency Injection
    • There are different ways to inject dependencies
      • Statics and globals make code rigid, brittle, hard to test, and prone to memory leaks
      • Locator patterns push extra responsibilities on your classes
    • Automated DI gets around the need to pass the parcel, but keeps code flexible
    • How does Robotlegs Injection work?
      • Automated DI is a handshake
        • You can specify an injection point in three ways
        • And you also have to tell the injector what you would like it to do
      • Robotlegs has different types of injection
        • If you only want one instance, use mapSingleton
        • mapSingletonOf keeps your code coupled only to interfaces
        • What if my class has to be created elsewhere? (e.g. a factory)
        • Named rules let you create multiple rules for each class (but theyre icky)
      • You need to tell the compiler to include the injection metadata
        • FlashBuilder/FlexBuilder solution
        • Flash CS4/CS5 IDE Solution
        • IntelliJ Solution
        • Flex SDK Solutioncommand line compiling
        • Flex SDK Solutioncompiling with ant
      • Automated Injection Gotchas
        • If an object has an [Inject]ed dependency you have to create it using the Injector.
        • You can map injection rules at runtime, but beware of race conditions.
        • The injection point and rule have to be of exactly the same type
        • If you override a method that has an [Inject] tag, you need to add it in the subclass
  • 5. The Robotlegs context in action
    • Provide the context with a root-view
    • Ask it to run startup()immediately or when youre ready
    • Use startup() to provide your injection rules, map your mediators to views and commands to events
    • Shutting down a Context
    • Now you have some Context
  • 6. The CommandMap in action
    • A Command is a concise single-purpose controller object
    • Commands are triggered by events
    • Commands can be any class with an execute method
    • Commands should do their thing and then die
    • Commands rely on their injections to be useful
      • You can inject the event that triggered the command
    • Commands know about the injector, command map, mediator map and context view
    • Commands can also dispatch events
    • Great command names pay dividends
    • Use helper classes for shared logic
    • Detain and release when you need your command to hang around
  • 7. Models and services: How are they different?
    • Models and Services usually extend Actor
    • They dont listen, they only talk
    • Use your API through a Command
    • Distinguishing Models from Services
    • Classes that dont dispatch events to the shared event dispatcher dont need to extend Actor
    • Configuring services
      • Configuring services using a command
      • Configuring services by injecting the configuration
    • Working with non-Actor models and services (including third party code)
      • Wrap them in an Actor
      • Use the command that acts upon them to dispatch the events
    • Model design tips for Robotlegs
      • Keep those responsibilities separated
      • Use strong-typed wrappers for collections
      • Never create mutually dependent models
    • Managing the relationships between models and services
  • 8. Connecting views with Mediators
    • Introducing the MediatorMap
      • Wiring views with the MediatorMap
    • Mediating your view components
      • Mediators are created when your view hits the stage
      • Mediator Structure
      • Avoid logic in your Mediators
      • Do your wiring in onRegister()
      • Using the EventMap
        • Use the eventClass parameter to make mappings that are type safe
      • You can do manual clean-up in onRemove
    • Why cant Mediators be injected into other objects?
    • Working with complex composite views
    • Using the same mediator with more than one view
    • A good Mediator is just a mailman
      • Signs that you need another mediator
      • Never put view logic into the mediator.
  • 9. Working with Robotlegs: Rich Examples
    • Feature implementation walk-through: Mosaic Tool
      • Challenge 1: Keeping things on a need-to-know basis
      • Challenge 2: Keeping the view snappy
      • Keeping the models in line with the visual design
        • The crucial Robotlegs mappings that tie it all together
        • The tile color update again, but this time with code
    • Feature implementation walk-through: Personal Kanban App
      • How new tasks are entered
        • The crucial Robotlegs mappings that make this sequence work
        • Adding a new task again, but this time with code
    • Wait, I want more examples!
  • 10. Testing your Robotlegs application
    • Your test provides the injections
    • Testing models
    • Testing services
    • Testing commands
    • Testing mediators
      • Testing that an event dispatched by the view results in the correct event being dispatched on the shared event dispatcher
      • Testing that an event received on the shared event dispatcher results in an action on the view
  • 11. Power-ups
    • Bootstraps can break up fat contexts
    • The ContextEvents help keep control
    • Tag methods with [PostConstruct] to run them after injection is complete
    • Use Signals between complex views and their mediators
    • Modular and multiple-context Robotlegs
      • ModuleEventDispatcher and child injectors make it work
    • Extend Robotlegs with utilities and add-ons
    • ViewMapinjection for your views
    • Mediator map performance
  • A. Troubleshooting tips
    • Problem: Injection doesnt occur
      • Broken injection point declaration
      • Metadata is being stripped by the compiler
      • Instantiating an object with injected dependencies using new
      • Injected properties are null in constructor
    • Problem: Things work for a while and then mysteriously stop
    • Problem: Event dispatch does not work as expected
    • Problem: Mediator isnt running onRegister
      • Make mediator mappings from the inside out
    • Problem: Handlers in the mediator are running repeatedly
    • Error: Injector missing rule for X
      • Missing injection mapping
      • Inconsistent injection mapping
    • Warning: Duplicate mapping in the injector
    • Error: Call to a possibly undefined method X
    • Where to get more help
  • B. Swiftsuspenders: The power behind the Robotlegs Injector
    • What does Swiftsuspenders actually do?
    • We think limited metadata is a good thing
  • About the Authors
  • Colophon
  • SPECIAL OFFER: Upgrade this ebook with OReilly

pokaż cały spis treści

ukryj recenzje