After prototyping it, I don't think camel-casing BXML file names containing Bindable objects is such a good idea. There are lots of cases throughout the codebase where we have BXML files that don't contain Bindable objects. When the two naming styles are mixed, it gets pretty confusing.
So I think it makes sense to stick with the current BXML naming convention, but change .json to either .styles or .resources as appropriate. Comments welcome. G On Jul 15, 2010, at 9:41 AM, Greg Brown wrote: > Another advantage of this approach is that it would clearly distinguish > "typed" BXML from untyped: > > MyComponent.bxml - root element is a bindable code-behind class > my_component.bxml - root element is not a bindable code-behind class > > The same applies to the style files: > > MyComponent.styles - typed style definition > foo.styles - untyped style definition > > > On Jul 15, 2010, at 9:38 AM, Greg Brown wrote: > >>> MyComponent.java >>> my_component.bxml >>> MyComponent.styles >>> MyComponent.resources >> >> One advantage of changing the BXML naming convention is that the BXML source >> file would appear next to the associated Java file in an IDE or file system >> browser. Using the current naming convention, the BXML files appear after >> all of the Java source files, because they all begin with a lowercase >> letter. In practice, I have found this to be a bit inconvenient. >> >
