In general terms, If a feature of MyFaces can be implemented in a JSF-independent way, put it in tomahawk so everyone can take advantage of it.
If a feature of MyFaces requires special code in impl so that it cannot be used elsewhere, then it should be configurable, and the feature should probably be disabled by default. However, we shouldn't dump a potential feature just because it's only usable in our implementation. On 3/9/06, Manfred Geiler <[EMAIL PROTECTED]> wrote: > On 3/9/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > > > > > DummyForm was a special feature of MyFaces, that was wrongly put into > > > the implementation - it should have been put into tomahawk, where it > > > belongs to. > > > > > > Right? > > > > > No, DummyForm is a *feature* of the MyFaces impl. There is nothing in > the spec that forbids additional features in an impl and the DummyForm > is one of the additional features. The DummyForm is worth a discussion > though. Why? Not because it does break the spec, but because it makes > users develop apps that are not 100% spec compliant. Whenever there is > a feature that adds some value by adding kind of automatic > intelligence or fault tolerance, we bring people to making > assumptions. And these assumptions will make their webapps fail on a > different JSF impl. > Our problem? > Yes: > * We all believe in the JSF idea, because it is a standardized > framework. Adding features that bind users to our implementation is > nice when thinking in commercial or competitive dimensions. But is > misplaced in the free open source world IMHO. > * People that are unable to run their app on the Sun impl will shout > and say MyFaces is not spec compliant because it behaves other than > the *reference* implementation! > > So, I agree - with a heavy heart ;-) > +1 to move any value-add feature to tomahawk that otherwise would > bring users to making assumptions > > Manfred >
