Gary VanMatre wrote:
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.
I think it's not a problem - just determine that component defined in
clay-config have higher priority than from templates (or vice versa)
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"/>
may be it would be more practical if for each component defined in html
template (e.g main.html) clay component try to find definition in
corresponding config file (e.g main-clay.xml) and only if it can't find
there it tries in standard clay-config.xml
it prevents that clay-config.xml becomes huge.
Thanks for your answers and for your work - hope clay will be very
flexible and handy ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
