I'm not sure. What would the code look like if we introduce this subinterface? Do we pass Layout to Appenders or PagedLayouts? Would we need to check with instanceof? This does introduce complexity.
Paying the cost of complexity would be fine if we get some benefit in return, but what would that benefit be in this case? The current protocol for layouts that are not paged is to return null headers and footers. This is handled by the AbstractLayout class that is the superclass of all Layout implementations. How is PagedLayout going to improve this? IMO it should bring substantial benefit for the additional complexity it will bring... Remko On Sat, Aug 17, 2013 at 6:30 AM, Nick Williams < [email protected]> wrote: > Seems reasonable. > > Nick > > On Aug 16, 2013, at 1:07 PM, Gary Gregory wrote: > > In Layout I see (my bold): > > /** > * Returns the format for the layout format. > * @return The footer. > * * @doubt the concept of header and footer is not universal, should > not be on the base interface. > * (RG) I agree with this.* > */ > byte[] getFooter(); > > /** > * Returns the header for the layout format. > * @return The header. > * * @doubt the concept of header and footer is not universal, should > not be on the base interface. > * (RG) I agree with this. > * */ > byte[] getHeader(); > > So do we want: > > public interface PagedLayout<T extends Serializable> extends Layout<T> { > byte[] getHeader(); > byte[] getFooter(); > } > > ? > > "PagedLayout" is just a placeholder name, alts welcome. > > Gary > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > >
