Whew! It’s been a while since the alpha release and have we ever been busy! Due to the monstrous list of changes and improvements you see below, we’re not going to try covering all of them in depth in this post. Many of these features will get posts of their own, so keep an eye out for those coming soon. In the meantime check out the changes, dive into the code or grab the SWC and head over to the list with any questions or comments.
Update: Because I am a bone head, and I was running low on time, there were some potential problems with the initial SWC. The two files below *actually* support pop up injection, and the one whose name implies as much is compiled with the Flex SDK set to external. If you are using Flex I would recommend that one, so you can choose which SDK to build against. If you are using pure AS3 you will need to use the one with the SDK included, as we have not yet completely separated the logging from the Flex framework. Sorry for any inconvenience.
v1.0.0-beta-patched-externalSDK
v1.0.0-beta-patched
Changes and additions in Swiz 1.0.0 Beta:
- SwizConfig
- SwizConfig is back and better than ever
- injectionEvent, injectionEventPhase and injectionEventPriority fully customizes the listener that triggers inspection of your views
- injectionMarkerFunction allows you to specify a decision maker function that determines if a view should be inspected and processed. Easily checked for property existence, interface implementation or any other custom criteria.
- eventPackages and viewPackages support for .* – we’ve seen people get tripped up by specifying packages with a trailing *, so we added support for it
- loggingTargets to see what Swiz is doing behind the scenes
- Parent and child Swiz relationships
- Swiz instances declared on IEventDispatcher instances that are descendents of another Swiz dispatcher become child instances
- Child instances can use beans declared in parent instances
- Child instances inherit eventPackages and viewPackages from their parent
- Parent instances can mediate events dispatched from child instance
- ISwizInterfaces
- ISwizInterface is the parent interface for a few interfaces beans can implement to have Swiz give them special treatment. Interfaces are fulfilled after all metadata has been processed. The interfaces are as follows:
- ISwizAware – Implementers will be provided with a reference to their containing Swiz instance.
- IBeanFactoryAware – Implementers will be provided with a reference to the BeanFactory for their containing Swiz instance.
- IDispatcherAware – Implementers will be provided with a reference to the event dispatcher used by their containing Swiz instance. Useful for non-display list beans that need to dispatch system events.
- IInitializing – Implementers will have their init() method called.
- Service utils
- Consistent with our principle of never making you extend Swiz classes, we’ve moved the functionality previously provided by AbstractController into their own utility classes.
- executeServiceCall() is now provided by ServiceRequestUtil
- executeURLRequest() is now provided by URLRequestUtil
- You can instantiate these classes directly, but the recommended practice is to define them as beans and inject them by type.
- AbstractController still provides these methods in order to ease migration pains. Convert to the utilities when you’re ready.
- Generic chaining support
- We have added a fantastic, robust and extensible chaining infrastructure to the framework.
- Event chains and command chains available “out of the box”
- Create custom chain types by extending a base class and overriding a single method
- Processor priorities
- Metadata processor execution is now ordered using a priority property
- Configure your custom processors to run at any position in the list of default processors
- Ignore metadata starting with _
- Thanks to some new metadata generated by Flex 4 debug builds, we ignore all metadata tags starting with an underscore
- Support for multiple Mediate tags
- You can now pile on as many [Mediate] tags as you want to a method, and it will be called in response to all the specified events
- Support for [Mediate( "MyEvent.*" )] syntax
- To facilitate easy support for front controllers and the command pattern, specify that you want a method to be called in response to all event types matching public static constant values on a given class
- Currently in raw form, will be refined in future versions
- Support for properties on dynamic events
- We’ve corrected the logic that runs in response to tags like [Mediate( event="MyEvent.FOO", properties="username, password" )] to allow the use of dynamic event classes
- Storage beans
- SharedObjectBean and EncryptedLocalStorageBean added to simplify usage of this type of functionality
- [VirtualBean] has been renamed [Outject]
- Same functionality, new name
- Initialization changes
- We completely revamped the way Swiz initializes and processes beans
- Prototype is now correctly implemented offering deferred instantiation and (by default) a fresh copy to each request for its type/name
- Each bean is fully initialized and processed before being handed back to whoever requested it, providing full support for proper cascading
- [Inject] is the new [Autowire]
- [Autowire] is still supported, and will continue to be for the foreseeable future, but it has officially been deprecated
- If you are listening to Swiz’s logging, you will get a warning for each [Autowire] tag instance
- Injections are now considered required by default. If a dependency is optional, use the following format [Inject( required="false" )]
- Metadata processors API updated
- Processors that deal with one tag at a time can simply extend BaseMetadataProcessor and override the public function setUpMetadataTag( metadataTag:IMetadataTag, bean:Bean ):void
- Processors that need to process groups of tags for purposes of ordering or coordination may override public function setUpMetadataTags( metadataTags:Array, bean:Bean ):void
- Corresponding tearDown methods are provided as well
- If you prefer not to extend a Swiz class simply implement IMetadataProcessor
- Metadata processors can support multiple tag names
- metadataNames specifies the tag names a processor will handle. This is how InjectProcessor handles both [Inject] and [Autowire]
- [PostConstruct]
- We’ve added support for [PostConstruct], which can be used to decorate methods that will be run after all [Inject] tags have been processed.
- Supports an order attribute for executing multiple methods in a specific sequence
- SwizLogger and loggingTargets
- Swiz’s internal classes now use the static SwizLogger class to properly log output in a standardized way
- The loggingTargets property of SwizConfig allows you to specify an array of ILoggingTarget instances, with full support for filtering, message customization, etc
- Work in progress, logging has not yet been fully implemented across all Swiz classes. Swiz will be *very* chatty before everything is said and done.
- MockDelegateUtil
- TestUtil has been renamed and reworked into MockDelegateUtil
- Provides createMockResult( mockData:Object, delay:int = 10 ):AsyncToken and createMockFault( fault:Fault = null, delay:int = 10 ):AsyncToken methods
- AMFUtil
- Useful for parsing stored AMF3 data, particularly helpful when combined with MockDelegateUtil to create a mock service layer
- Added FlexFormatter prefs to GitHub
- Pop up support
- Pop up views can now be properly wired
- IBeanProvider.dispatcher implemented
- BeanProvider and BeanLoader now include a dispatcher property (again) that is the IEventDispatcher used for “system events” in a Swiz instance.
- Useful for providing non-view classes a way to dispatch events that will be heard by Swiz.
- Same instance provided to implementers of IDispatcherAware
- Main dispatcher processed as bean
- The main view/event dispatcher on which Swiz is defined can now be properly wired
Enjoy!
{ 31 } Comments
Wow, impressive list of changes, Swiz 1.0 will be a great release. Thanks for your effort!
Is this a joke? Swiz.swc includes all flex classes! What the hell? it’s unusable because I have some flex classes overridden (defined in my project)
Yes kurwa, this is absolutely a joke. We thought it would be funny to screw up your project.
In actuality, the logging system has not yet been completely decoupled from Flex so we are unable to compile with the libraries set to external at this time. If this presents a problem you can either not use the beta, or you can compile the library yourself with libraries set to external. The resulting SWC will work for Flex projects, but not pure AS3 projects.
Oh and next time, be a bit more professional with your comments and questions, or they will be deleted.
thank you for your work. i was using 1.0 alpha. this is good news. do you have a time frame when 1.0 rc is out ?
We hope to have a RC out within the month.
Hi guys,
I saw Chris’s presentation. After briefly evaluating Mate, I decided to give Swiz a try. We have been using Cairngorm in a number of enterprise scale web application projects. I am a little bit nervous with the immaturity of Swiz, but will keep you guys posted on the journey.
Serdar BADEM
Hey Serdar,
The first version of Swiz was released the same day as the first version of Mate, we are now just at two years old. I would not consider Swiz immature at all, and our feature set is growing considerably with all the new extensibility features, such as custom processors.
I hope you find working with Swiz as much a breath of fresh air as the rest of us!
Great job on the updates guys! As an avid fan of the 0.6.4 release, I’ve decided to switch my project over to the Beta and try out all of the new stuff. I’ve been really busy and had a tough time keeping up with all of the comments on the forum. Would you say the framework is still “brutally simple”?
Also, do you by any chance have a sample application using the Beta? (like http://www.benclinkinbeard.com/swiz/SwizUserAdmin/srcview/index.html)
Hey Erich, all the core pieces are still there, we have just added some features, flexibility and extensibility. It is still brutally simple, there are just more layers of goodies if you feel like digging.
No demo app yet (boo for us) but there will be one (or more) soon.
Hey Erich,
I am cross posting this that I just posted to the mailing list:
I just went and reviewed the alpha demo app (http://swizframework.org/files/examples/1.0.0-alpha/flex3/) and there are only a few minor differences from the beta.
Anywhere you see [Autowire], it should be [Inject]
Anywhere you see [VirtualBean], it should be [Outject]
The custom metadata processor API has changed a bit, for a current example see MediateSignalProcessor (http://blog.foomonger.com/2010/02/26/swiz-signals-and-mediatesignal/ & http://j.mp/bPnuEk)
Thanks,
Ben
Documentation!
Guys, you really need to focus on your documentation and examples. I know you are busy and I know that docs are not top priority, but if you are the only ones that know how to use your product, it is of no use to anyone else.
I’ve been using 0.6 for some time now and it took me ages to figure it out from bits and pieces scattered over many URLs. There does not seem to be any real documents at all, just redirections and snippets.
I saw 1.0b released and thought I’d give it a go, but you introduce features as if we have know all along what they do. Case in point:
“Pop up support
* Pop up views can now be properly wired”
What does this mean? Can you please explain what features are used for, why this is advantages and give an example. I tried 1.0b, but had to fall back because there simply is nowhere, where it is properly explained. I know it is a beta, but there is no excuse for changing this and not documenting it. How can I test it or try it without any notes?
Please take this as positive criticism. I REALLY LIKE Swiz, but I am getting put off it because you are spending too much time on coding and not enough on documentation. Your framework is way better than the others, but your are losing people who are not MVC rocket scientists just because you are not explaining your framework properly.
You are not going to get attention and the share of development use you need because of this.
My 10c worth & hope to see better docos soon.
Des
Des,
As you pointed out, we’ve been focused on the code up to this point. Without code there isn’t much to document, is there? We’re currently in beta, so it is for early adopters. If you don’t like to dive into code to tinker and experiment, a pre-release probably isn’t for you. We will have full documentation ready for the 1.0 final release, but plenty of people have been able to get up and running with the beta as is.
I thought “Pop up views can now be properly wired” was pretty self explanatory. If you use PopUpManager to create/add a view, you can now inject into, whereas you could not before.
I understand you intended to provide positive criticism, but that really isn’t how it came off. Saying there is “no excuse” for something is not positive. In actuality, there is a very good excuse. We all have families, day jobs and other responsibilities outside of writing and documenting free software. I’d appreciate it if people would keep that in mind the next time they have an issue with free software, whether that software is Swiz or something else entirely.
Ben
Ben,
Agree 100% with your comments and yes, I tried to keep it positive but might have got carried away
I appreciate the effort and work put into this, as I have a day job and doing development at night as well. Might be some of that spilling over in my frustration. I find that if I document what I am coding, it tends to ensure that I code according to what I intend to use it for. That’s just my style.
I’ll stick to the released builds for now, as I do not really have the time to dig in the code and figure it out. Looking forward to the 1.0 docos and I can certainly offer help on reviewing if needed.
Thanks
Des
Wow impressive list of changes.
As much as I love using the previously-known TestUtils, I wonder if such a feature really belongs to Swiz’s lean architecture. Do you have plans to factor them out into a separate library perhaps?
About the documentation, my initial experience with Swiz was much like the previous commenter. If you argue that Swiz has been around as long as Mate, then perhaps a comparison of the documentation quality should be considered.
Despite the outdated docs, I just dove in and gave it a try and was honestly surprised at how easy it was as advertised..
Keep up the good work
The utilities will likely stay as part of the core SWC for the foreseeable future. We are, however, considering the creation of an extensions SWC that houses custom metadata processors, so you don’t have to worry about core getting much bigger.
A 1.0 release would be great (if only to make management and other non-technical people “feel” better). I’ll second (or third?) the importance of keeping the core as small as possible. This will be important for the future as “competing” architectures continue to grow, adding bloat and complexity, as similar libraries often do.
Thanks guys for this… in my opinion Swiz is the shiz.
Can’t agree with Ansury (and others) more on the importance of keeping the core as small as possible. I am attracted to Swiz for one reason only: IT DOESN’T DO ANYTHING except for helping to better organize Flex code.
Guys, keep up the good work to keep the promise of the “brutally lightweight”-ness of Swiz. Thanks!
Just wanted to say thanks for all the hard work. Swiz is wonderful to work with.
DM
Thanks Daniel, that’s great to hear.
Ben
I’ll look forward to documentation when 1.0 is released also. I’ve been struggling to get running with Swiz. The only progress I’ve had at all is to cobble together a skeleton app from a combination of SwizHelloWorld and bits of code from the “Getting Started” pages. I even had trouble just trying to duplicate SwizHelloWorld by hand-coding. Maybe it’s because I’m running Flash Builder 4? Swiz 0.6.4 works OK with Flash Builder 4 in SwizHelloWorld but I sure have been having problems with it.
I realize you guys have limited time but I’ve run into a lot of open source projects that were only half-baked. Eventually, I get tired of trying and give up. Swiz looks like it has a lot of promise so I’ll keep trying. I know how hard it is to fit in time, though. I run a user group and am volunteer webmaster for several groups.
Maybe I’m asking a very stupid question but I don’t understand what the “catalog.xml” file mean or what should I do with it. (I mean the file included in the “swiz-v1.0.0-beta-patched-externalSDK.zip” file) I should do something special to start using swiz with flex3?
Thanks a lot for your efford on this framework, it seems awesome. I am really anxious to start using swiz on a project for the first time
Hi Don,
I think your system mishandled the download. The link is to a SWC file, not a ZIP. While a SWC essentially is a ZIP, and always contains a catalog.xml, your system should not have treated it as such or unpacked it.
HTH,
Ben
Hi Ben,
You are rigth! I don’t get how could I missed also that when unpacked the zip file one was the xml and the other an swf. There was no swc and I couldn’t see it!.
Thanks a lot for your help.
Don
Hi,
I am trying to use swiz 1.0 beta using as reference a this project:
http://www.webappsolution.com/flex/blog/examples/emp-mgmt-console-swiz-passive-view-0/srcview/
The problem is that I can’t find the properties:
mediateBubbledEvents and beanLoaders for the tag SwizConfig.
How should I do that in swiz1.0?
Thanks a lot for this framework,
Pola.
Hi I have found in another post a solution to my last question, however I still can’t find a replace for the dissapeared property “mediateBubbledEvents”.
How should I set that?
thanks you
mediateBubbledEvents has been removed as a public property and permanently set to true.
HTH,
Ben
I haven’t seen anything around the usage of Chaining Events. Is anyone using the new Command Chaining mechanism with 1.0 Beta ?
Hi Serdar,
RC1 is right around the corner with some chaining updates and improvements. There will be a good docs page around how to use them as well.
Ben
Thx guys for the good work. Im looking forward to this RC1. Im using the 0.6.4 since a while and I was afraid to update (no time to spend on it). Slicely changing my mind
Gogo SWIZ! May the force be with you.
create GenericDAO framework in AS3 with Swiz, like IBM Generic DAO (Java /Spring/ Hibernate)
Check Wiki, to see How it works
http://github.com/nsdevaraj/SwizDAO
{ 2 } Trackbacks
[...] The latest and greatest release for the little-framework-that-could Swiz has finally been promoted to “BETA” status. Grab the SWC here: http://www.swizframework.org/files/swiz-v1.0.0-beta.swc. Read the full list of changes/additions here: http://swizframework.org/2010/03/swiz-1-0-0-beta-now-available/ [...]
[...] Download Swiz 1.0 Beta [...]
Post a Comment