Robotlegs 2.0 - the path from here
As many of you will know, the core Robotlegs team (less Joel) has just spent 5 days holed up in a villa in Spain, thrashing out a path for the future of Robotlegs.
We're ultra excited about the feature set we're homing in on, and the ways in which it will make your workflow even more enjoyable.
There isn't a deadline for releasing Robotlegs 2 (though you can ballpark Q4-2011 if the wind blows the right way) but we wanted to give you some reassurance that we're going to open the process up as soon as we possibly can - and there will be numerous ways in which you can get involved in helping to bring Robotlegs 2 to life.
We want to take a little more time to kick our feature list around between ourselves before we release it - but what we can fill you in on is the plan in terms of how we're going to develop and release Robotlegs 2.
Let's start with our plans for Robotlegs 1
We're still maintaining Robotlegs 1
Robotlegs 1 is not going to be lying dormant: there will be another 1.x release shortly, addressing a couple of minor non-breaking bugs we've found, and we'll continue to show 1.x some love.
The great Robotlegs taste you know and love, with 20%* less fat
As soon as possible, we will release a special '1B' version which will have the Robotlegs 1 API but use the new Robotlegs 2 architecture under the hood - giving existing projects the benefit of optimisations without having to change any code. [* Arbitrary percentage with no mathematical or factual basis, possibly not even in base-10.]
No code left behind...
Many features we have decided on for Robotlegs 2 can be implemented through utilities in Robotlegs 1 - just not as easily or as efficiently. We realise that there are many projects (including some of our own) which are too deeply invested in version 1 to move to a new API, and we'll help you to create utilities that replicate the new functionality if you want to make use of specific features without revising existing code.
Moving forward with Robotlegs 2
Minimising the wait
We realise that the prospective release of a new version makes it tricky for people to choose Robotlegs for their architecture for a new, long-running project. So immediately after releasing the '1B' version we'll be providing a 2.0 Beta 1 which will contain all the existing RL 1.x functionality but with the new API.
Stable API on all Beta releases
We will not break 2.0 Beta API features in future releases. Our betas will only contain the parts of the API which we have decided upon - we'll work on a feature at a time, so that you can get access to new stable API as fast as possible. Features with API still being debated will only be included in our Alpha releases.
What? I don't understand... if the Beta is stable API, why isn't it a release candidate?
Beta releases may still have bugs, non-optimised code under the
hood and so on - the key thing you need to know is that if a piece
of functionality is called using commandMap.loadFlow(
UserRegistrationFlow ) in the Beta, it will still be the
same code in the final release. (Yes, that was a hint ;) ).
Minimum-credible-implementation = 2.0
We'll target a 2.0 release of the core feature set, pushing bells and whistles back into 2.1 and 2.2 following rapidly afterwards - we understand that many project managers are uncomfortable with using beta libraries.
Utility migration support
We'll work with those of you who have developed a 1.x utility to help you figure out how to port that utility ahead of release. In some cases we'll be contacting you shortly to discuss pulling your utility's functionality into the Robotlegs 2 core.
Your Robotlegs will still be fast and light, but will also be much bendier
The main feature Robotlegs 2 brings to the table is flexibility. We're pretty confident that the new 2.0 features are going to be powerful and yet still fun to use and easy to learn. Our focus has been on solving the problems that Robotlegs users most frequently bang up against, and improving performance, while still making sure we don't break what people have loved about Robotlegs 1.
A few headlines that we can commit to already...
Robotlegs and Swiftsuspenders are getting married
Swiftsuspenders - the Dependency Injection engine that makes Robotlegs work - is no longer going to be separated from Robotlegs. For excellent reasons, Robotlegs 1 was decoupled from the DI engine - incase people wanted to make use of alternatives. In reality, Swiftsuspenders is so fantastic that we don't see any downside to coupling Robotlegs to it. In practice this means you'll still be able to use Swiftsuspenders without Robotlegs, but not Robotlegs without Swiftsuspenders.
We're going to leave Flash Player 9 behind
Flash Player 10.x provides the Vector.<Type>
class, and the performance benefits over Array (for
our use cases) are too big to ignore. Vector also provides some
(though not perfect) compiler checking for lists of objects, and so
we don't see Robotlegs 2 being compatible with Flash Player 9 out
of the box.
That said - anywhere you can use a Vector you can generally use an Array - so if your project genuinely requires Flash Player 9 support we'll help you to port Robotlegs 2 to FP9.
The investment you've made in learning Robotlegs 1.x will still pay dividends
We realise that it cost you something to learn how to build your applications using Robotlegs. Overwhelmingly, our feedback shows that this has paid off for you, but you probably don't want to have to go through that learning process again. For that reason, and because we still believe they are great conceptual tools for building applications, we'll continue to support the patterns implemented in Robotlegs 1. There may be some small changes in API - which we hope will make your code flow more naturally - but we're not about to require you to change how you think about code again (though there will be more flexible support for other ways of mentally modelling software).
How can I get involved?
Add a comment to this message initially. We'll be seeking alpha and beta testers - both experienced and new to Robotlegs. We'll also be sharing the source, accepting patches and running a backlog just as you'd expect, as soon as the core functionality is whipped into shape. Performance testing is another area where help will be appreciated - especially if you have access to an alternative platform such as set-top-box. Anyone will be able to access the code and builds, but our testers will be actively asked to give new versions a whirl.
TELL ME ABOUT THE FEATURES!
Sorry... not quite yet... but soon, we promise!
Showing page 2 out of 2. View the first page
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
31 Posted by neil on 12 Aug, 2011 02:27 PM
I tend to use my own implementations of the mvcs classes, as I just don't use any of the event based things. It's a strength of rl that it is so flexible, but it also means that I am out of synch with the standard.
What I would LUV would be an opt it for everything. You start with a.bare context that has nothing but the injector, then every thing else is pluged in with a line of.code.
That way I.don't have to hack out bits I don't want.
Xxx
32 Posted by Rick on 26 Aug, 2011 02:28 AM
i have used RL on a few projects...been working with extjs 3/4 for the last few months. My return to actionscript is currently with swiz. I miss RL. I will provide any help needed. Would love to be involved in some way.
33 Posted by James on 03 Oct, 2011 01:47 PM
I'm quite experienced with PureMVC and have been considering porting my project to RL.
Should I wait for version 2 and only have to port once, or should I learn RL 1 first, port the project (and continue development using RL1), and then port again when RL 2 is released?
The project is still in development so I suppose the time savings of RL1 will still be beneficial.
Any advice would be greatly appreciated!
Support Staff 34 Posted by Till Schneidere... on 10 Oct, 2011 11:10 AM
Hi James,
sorry for not getting back earlier - most of the RL team was at a
conference last week.
The good news regarding that is that we worked hard at getting RL 2
closer to release during that week. The bad news for you is that it
will still be a couple of months until that new version is
production-ready. So if you're developing right now and want to start
porting sooner rather than later, I'd recommend starting with what's
currently available.
We will enable full or, at the very least, almost full backwards
compatibility, meaning that getting started with porting to RL 2 will
in the best case simply mean switching out a .SWC file and in the
worst case doing some simple search-and-replace stuff on your
codebase. Also, keeping conceptual backwards compatibility is one of
our highest priorities. That means that what you'll learn about RL 1
now won't be a waste as the fundamental concepts won't be thrown out
at all.
hope that helps,
till
35 Posted by jce on 27 Oct, 2011 10:21 AM
Hi Stray,
Saw your talk at FOTB this year, it was most excellent!
Quick question for RL 2.0: will there be any features added to the core of the MVCS implementation that deals with asynchronous command chaining? This 'commandmap.loadFlow(...)' you hinted at sounds like it may be something along these lines. Most of my apps go through a bootstrap process to load external resources, hit various webservice APIs etc. before I can put my view in 'ready' mode. Since switching to RL I've tried chaining synchronous commands (feels dirty), tried Joel's state mancine utility (pretty verbose), and various other approaches. I still haven't managed to find the procedure that feels as nice as the asynchMacroCommand utility I used in the PureMVC days: http://trac.puremvc.org/Utility_AS3_AsyncCommand even though this approach might be a bit 'naughty'
Do you have any thoughts or comments?
Cheers & thanks for all the hard work!
best,
jc
Support Staff 36 Posted by Stray on 27 Oct, 2011 10:31 AM
Hi jc,
the good news is there will be not one but TWO solutions for this, with a built in flexibility for rolling your own solution if neither of ours feels right to you.
So - you'll be well provided for there - and Robert Penner is currently beavering away on one of those solutions so it's bound to be performant, efficient and free of naughtiness!
We're also working hard to make it as easy as possible to upgrade a RL1 project to RL2 - so you may even be able to drop the new solutions into your current projects.
We'll have more news on that (and the rest of our progress) very soon.
Stray
37 Posted by jce on 27 Oct, 2011 12:16 PM
@stray - that's music to my ears! Can't wait!
Support Staff 38 Posted by creynders on 27 Oct, 2011 02:06 PM
Will RL2 have some kind of hooking mechanism to allow to react to object instantiation?I saw in the_future branch of SS that he's implementing various events to be dispatched upon mapping, instantiation etc. Will these allow us to hook into the process and for instance map a command that configures an instance when it's created? Allowing for lazy instantiation and configuration? Are these events system wide? Or SS adapter specific? And I suppose there'll be some kind of mechanism to map a command to a specific class instantiation?
I'll stop with the questions now. :)
Support Staff 39 Posted by Till Schneidere... on 27 Oct, 2011 02:23 PM
RL2 will most likely do away with the adapters as it is becoming
unfeasible to do an adapter that still allows you to fully exercise
the Swiftsuspenders API. So yeah: You'll be able to hook into all
instance creation internal to RL2.
I'm not sure I understand what you mean by "I suppose there'll be some
kind of mechanism to map a command to a specific class instantiation",
can you clarify?
Support Staff 40 Posted by creynders on 27 Oct, 2011 03:40 PM
I meant: will it be possible to listen for the instantiation of one type specifically? or will we have to check what type was instantiated ourselves? The latter seems extremely expensive.
Something like
Support Staff 41 Posted by Till Schneidere... on 27 Oct, 2011 03:51 PM
Ah, sorry: I was a bit dense there.
Yes: We will provide hooks for commands and mediators at least. I
think that covers your needs, right?
Support Staff 42 Posted by creynders on 27 Oct, 2011 04:42 PM
It certainly does, thanks!
43 Posted by Eli Atlas on 05 Nov, 2011 10:46 PM
I started learning Rl couple of weeks ago. Just started a new mobile project with it.
Would be glad to help in any way to RL 2.0.
Tweet me at @ateli, or mail me in case you will need anything.
44 Posted by Denis on 01 Feb, 2012 08:49 AM
Hi,
I am working on big enterprise project and really missing proper mediation for flex popups. Would like to help you with testing.
Support Staff 45 Posted by Shaun Smith on 02 Feb, 2012 03:55 PM
Hello all,
Just a quick update. RL2 is coming along at a good pace. If you're feeling adventurous you can head over to GitHub and browse the source (or even build yourself a SWC):
https://github.com/robotlegs/robotlegs-framework/tree/version2
Please bear in mind that the APIs are still in flux and may change before the official beta.
There are a number of readme files in the repo which you can read directly on GitHub:
https://github.com/robotlegs/robotlegs-framework/tree/version2/src/...
https://github.com/robotlegs/robotlegs-framework/tree/version2/src/...
https://github.com/robotlegs/robotlegs-framework/tree/version2/src/...
https://github.com/robotlegs/robotlegs-framework/tree/version2/src/...
You can also file issues and take part in the framework development discussions here:
https://github.com/robotlegs/robotlegs-framework/issues
And of course, pull requests are most welcome! But please ensure that you have created sufficient unit tests for any new/altered code.
Support Staff 46 Posted by Till Schneidere... on 02 Feb, 2012 04:03 PM
How could I let this opportunity to piggy-back pass by?
If you want to do a first step towards converting your existing apps
to RL2, you can do so by using RL1 in conjunction with Swiftsuspenders
2. I have uploaded a special build of Robotlegs 1.5.2 to my fork on
github:
https://github.com/tschneidereit/robotlegs/downloads
This build contains Swiftsuspenders 2 and a modified Injector adapter
and context to make it a drop-in replacement for Swiftsuspenders 1. In
theory, and I hope in practice, too, everything should continue to
work as before. I'd be happy to get confirmations for that or bug
reports, though.
Also, if you want to start using the new API of Swiftsuspenders 2, you
can simply inject the injector itself with the type "Injector" instead
of "IInjector" and do so. An oh so very short outline of that new API
can be found in the README here:
https://github.com/tschneidereit/SwiftSuspenders/
cheers,
till
47 Posted by Nikos on 21 Feb, 2012 05:01 PM
Nice one guys, I look FWD to seeing what you come up with!!!
Support Staff 48 Posted by Ondina D.F. on 27 Feb, 2012 12:53 PM
Till Schneidereit’s FITC 2012 Amsterdam presentation on Robotlegs 2
http://www.slideshare.net/tschneidereit/fitc-2012-rise-of-the-modules
Robotlegs 2 demo: https://github.com/robotlegs/robotlegs-demos-Bundle/tree/rl2/CafeTo...
49 Posted by Rick on 27 Feb, 2012 07:08 PM
[email blocked]
Ondina D.F. closed this discussion on 27 Aug, 2012 10:37 AM.