Maksimenko Alexander wrote: > > > yes it will work too but needs useless duplications of jsfid in mapping > element (I afraid of duplications ;)) > In this case the last one registered would win. We have the same thing with JSF components and managed beans?
> why it's not possible just while executing isClayTemplate method in > ClayViewHandler search weather viewId is equal to jsfid of any top level > component? In that case we get all what I've told about The Clay component metadata is handled by two config classes. One is for returning a component bean from the XML config files. The other returns a component bean from an HTML template/XML config files. The suffix of the jsfid determines what config handler will return the component information. The suffix "*.clay" is the default but I think that most will want to override with "*.html". If we went with a suffix "*.clay" for Clay full XML views, it would need to be configurable. I would worry that someone would try to make both full XML and full HTML suffixes the same. > 1) templating whole pages in terms of components - not jsp fragments I like this idea. Maybe we could call it full XML views verses full HTML views. > 2) scoping subcomponents jsfid in html views: when I define submitButton > in profile.html and it's not conflicting with component submitButton in > main.html We talked about adding a namespace to each XML config file. But the problem is with inheritance. One component can extend another in any of the registered config files. I think a naming convention would be the best solution based on a functional domain. <component jsfid="core:outputText" componentType="javax.faces.HtmlOutputText"/> <component jsfid="blueWidgets:outputText" extends="code:outputText"/> > Look forward for your opinion > Gary
