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

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

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

No demo app yet (boo for us) but there will be one (or more) soon.

Also, do you by any chance have a sample application using the Beta? (like http://www.benclinkinbeard.com/swiz/SwizUserAdmin/srcview/index.html)

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!

Serdar BADEM