> have no problem with this, as Wicket is doing the same thing in reality. > One > additional problem for both Pivot and Wicket is that the API is not very > clear, and in fact many classes are "polluted" by properties and
view/model interaction, and view styles are also APIs, even though the > methods are intended to be hidden. This is the nature of the "accepted > approach" and perhaps not too much can be done about it. > The API being clear I'd agree with, insomuch as our documentation is very lacking (and currently being addressed). But I think it's very consistent, which makes it very clear once you work with it. I'm curious what instances you found of the view talking directly to the model, since the view layer is the skin, and it should only be talking to the component, which is the controller. The styles are are exposed through a layer of indirection - not by API. The fact that they're backed by real bean methods would be something that ideally wouldn't be exposed to callers. In an ideal world, we wouldn't provide Javadoc for the skins on our documentation site, but instead "style docs" that were generated using either annotations or introspection. > In the long term, I expect a stable 2.0 emerge that follows the general > comaptibility guidelines and the cruft has been removed. Once that happen, > I > think we should be much more stringent than now. > Yup - I agree.
