2 Replies Latest reply on Mar 11, 2007 10:49 AM by pmuir
      • 1. Re: Move Seam JSF components to RF/A4J?

        Pete, I agree with your two points and just want to add one more:

        1. Most likely, the components with similar behavior should be united with summarizing the set of features. Such as s:graphicImage and rich:paint2D. At the same time, our practice says that superfluous generalization causes misunderstanding what the component for and how to use it. So, any changes in this area should be discussed upfront.

        2. The Seam specific component should stay in Seam to avoid a mess in understanding what component is a visual, but what one provides the specific framework behavior.

        3. The backward compatibility issue. Upgrading to the next release of Seam or RichFaces should not cause spending hours to move forward.

        • 2. Re: Move Seam JSF components to RF/A4J?
          pmuir

           

          "SergeySmirnov" wrote:
          1. Most likely, the components with similar behavior should be united with summarizing the set of features. Such as s:graphicImage and rich:paint2D. At the same time, our practice says that superfluous generalization causes misunderstanding what the component for and how to use it. So, any changes in this area should be discussed upfront.


          I think the only components here, rich:paint2D/s:graphicImage. s:graphicImage is supposed to be a drop in replacement for h:graphicImage, but which can load the image from a byte[], InputStream etc, and to which transforms (e.g. resize) can be applied. Perhaps paint2D fulfils a significantly different purpose to keep them as two components. This certainly eases the upgrade path.

          3. The backward compatibility issue. Upgrading to the next release of Seam or RichFaces should not cause spending hours to move forward.


          I think we should not change any attributes on a tag, which means that users have to just change the namespaces.