> 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. >
Im not worried about the size of the files because you can specify a comma delimited list of configuration files. A corresponding config file might work. The HTML templates are parsed on demand. The result is an object representation of the file. If the config files are changed, the cache is invalidated. The HTML templates are dependent on the XML metadata (inheritance). If the XML (core) files are modified, all of the cache is invalidated and the core is reloaded. We could take a similar approach for full XML views. The view Id could correspond to a XML configuration file that is loaded on demand. Maybe a requirement would be that the file would have to have a top-level component with the same name/jsfid as the view id. Top-level components could be shared between (core XML, on demand HTML and XML). We would have to assume that this type of top-level component had a unique suffix. That would fit very well into the existing mechanism. > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
