Provide documentation that does not assume you have a web developer reading it.

[Richard-Cranium]

Your current documentation is incomprehensible; there is no description or external reference on how the components fit together. Simply stating "Convention over Configuration" is meaningless.

I've found using Netbeans RCP easier to develop against than Griffon. There appears to be a large amount of magic occurring with Griffon. Unexplained magic is not a good thing.

[aalmiray]

We always welcome feedback of all kinds. In this case it would be great if you could give us a bit more of details. The guide begins by explaining the history and motivations for the framework; then showcases a small example explaining each part; then moves on to explain each artifact/component type in its own section. Rounding up are chapters with other topics that are of interest.

There are indeed some places where "magic" occurs but they are also explained in the guide:

• event handlers follow a naming convention. This is explained in the Events chapter.
• MVC members follow a naming convention. This is explained in the MVC chapter.

What's is still left out of the guide are:

• testing
• package and deployment Include documentation for application distribution in guide? #120

So what exactly do you mean by "there is no description or external reference on how the components fit together"? Where you expecting to see code & annotations that put together window elements, similar to the ones found in NetBeans? An application model similar to the one found in Eclipse RCP (#30)? What kind of application do you have in mind?

It's true that the guide presents basic samples, but we also have tutorials (http://griffon-framework.org/tutorials/) and an explanation of MVC patterns usage (http://aalmiray.github.io/griffon-patterns/) [I think this article should be moved to the official documentation site, next to the tutorials perhaps].

[Richard-Cranium]

I do agree that the MVC patterns usage deserves to be moved to the official documentation site.

I believe that your sample-javafx-java/griffon-app/resources/sample/javafx/java/sample.fxml file in 1.2.4 is incorrect in that the fx:controller attribute points to sample.javafx.java.SampleController versus sample.javafx.java.SampleView. The MVC patterns usage document uses the view instead of the controller, which makes a lot more sense to me (since that's the class with the @FXML markup).

To get to other specifics:

In the examples, you don't tell me why I *must * use the @ArtifactProviderFor() annotation and what it does for me. I've unfortunately been exposed to Grails, so I find it curious that I'm putting classes in various directories (model, view, controller) but that's not sufficient for the framework to do that for me.

You don't actually come out and tell me what the convention actually is in chapter 4. You tell me how to create an MVC group without telling me why I must/should do so. Does that wire them together in some fashion? Beats me. If it does wire them together, how are they wired together? What did creating that MVC group do for me?

It would be nice if the JavaFX binding chapter had something other than TBD.

[aalmiray]

MVC pattern tutorial added with 944a2e8

[aalmiray]

Naming conventions for parent-child relationships were already explained at https://github.com/griffon/griffon/blob/development/docs/griffon-guide/src/docs/asciidoc/mvc-mvcgroups.adoc