While working on the XML sequencer, I determined that I will need access (via the SPI project) to some "well-known" namespace URI's in order to build node names, types, and path segments correctly. There are a few options here:
where by "define", we could either:
- Define the URI's in a separate class or interface, or
- Con: The need for an "artificial" class just to hold constants always feels a little non-OO (although I guess that argument could be made for anything that's considered globally accessible).
- Con: It is not necessarily an intuitive place for developers to look when working with a particular API.
- Pro: This could provide a "default" location to store other constants that we determine we need during the course of development.
- Define them in an existing class, such as the org.jboss.dna.spi.graph.NamespaceRegistry interface.
- Pro: The constants (or methods) would be defined near the methods with which you would most likely use them, potentially making it easier to know where to look for them.
- Con: There may not always be an appropriate class to define such constants (or methods).
- Con: When the constants are appropriate for use with multiple classes, it may be difficult or somewhat arbitrary deciding in which class they should be defined.
I don't really have a religion regarding this one way or the other. I just want to establish a pattern up front that everyone is comfortable with, and so I can put as little thought as possible towards this in the future.
- Provide constants for the URI's (e.g., public static final String JCR_URI = "http://www.jcp.org/jcr/1.0"), or
- Pro: The value of the URI would be readily apparent within the JavaDocs (via @value).
- Provide methods to return the URI's (e.g., similar to NamespaceRegistry.getDefaultNamespaceUri()).
- Pro: This may provide more consistency with other methods (such as the example above).
- Con: Not sure if a method would be the intuitive place to look for a constant value.
_______________________________________________ dna-dev mailing list dna-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/dna-dev