We are trying to do something like this in Shale. The proposed plugin is called Clay. The basic idea is to allow defining a subtree of components using something other than the JSP tags.
We currently have three subtree composition options: 1) Define in XML only 2) Define at runtime with a postback method to the view controller/ managed bean 3) Tapestry like composition where HTML elements are bound to JSF components using a "jsfid" attribute. You can check out the progress here: http://issues.apache.org/bugzilla/show_bug.cgi?id=33752 The runtime time option (#2) might look something like this: JSP component: <sh:clay id="v1" managedBeanName="fullAddress" jsfid="RUNTIME" shapeValidator="#{fullAddress.createSubtree}"/> ViewController/Managed bean: public void createSubtree(FacesContext context, UIComponent component, Object displayElementRoot) { log.info("createSubtree"); ComponentBean root = (ComponentBean) displayElementRoot; Clay clayComponent = (Clay) component; // make the root a panelGrid AttributeBean attr = new AttributeBean(); root.setComponentType("javax.faces.HtmlPanelGrid"); attr.setName("columns"); attr.setValue("2"); root.addAttribute(attr); // make a static text field ElementBean messageElement = new ElementBean(); messageElement.setRenderId(1); messageElement.setJsfid("outputText"); messageElement.setComponentType("javax.faces.HtmlOutputText"); attr = new AttributeBean(); attr.setName("value"); attr.setValue("City:"); messageElement.addAttribute(attr); // make a input widget ElementBean inputElement = new ElementBean(); inputElement.setRenderId(2); inputElement.setJsfid("inputText"); inputElement.setComponentType("javax.faces.HtmlInputText"); attr = new AttributeBean(); attr.setName("value"); attr.setValue("#{managed-bean-name.city}"); attr.setUseValueLateBinding(Boolean.TRUE.toString()); inputElement.addAttribute(attr); attr = new AttributeBean(); attr.setName("size"); attr.setValue("20"); inputElement.addAttribute(attr); root.addChild(messageElement); root.addChild(inputElement); } The Tapestry like solution (#3) would look something like this: JSP tag: <sh:clay id="template" managedBeanName="fullAddress" jsfid="address2.clay"/> HTML template (address.clay): <table> <tr> <td> Body hide, will see value from the ViewController only: </td> <td> <select jsfid=states size=1 name=manual> <option value="AL">Mock 1 <option value="AK">Mock 2 </select> </td> </tr> <tr> <td> Body show, will see the options below and the values from the view controller: </td> <td> <select jsfid=statesBodyOn size=1 name=manual> <option value="AL">Mock 1 <option value="AK">Mock 2 </select> </td> </tr> </table> XML config: <component jsfid="states" extends="selectOneMenu" id="states"> <attributes> <set name="value" value="#{managed-bean-name.state}" /> <set name="allowBody" value="false" /> </attributes> <element renderId="0" jsfid="selectItem"> <attributes> <set name="itemLabel" value="Colorado" /> <set name="itemValue" value="CO" /> </attributes> </element> <element renderId="1" jsfid="selectItem"> <attributes> <set name="itemLabel" value="Illinois" /> <set name="itemValue" value="IL" /> </attributes> </element> </component> <component jsfid="statesBodyOn" extends="states" id="states"> <attributes> <set name="allowBody" value="true" /> </attributes> </component> Gary > I didn't say that that this functionality *had* to reside in the JSP. > My point is that if you want to render different types of data > differently then your idea breaks down a bit b/c its cumbersome to add > commandLinks, outputText, etc. programatically when you could just do > it in the JSP. > > An example would be a field for document number. That is one possible > field our users might want to select in their query. We'd like to > make that field a hyperlink in the report so that the user can jump > right to the document in question. So whenever this field is present > then we use different JSP than the default. > > sean > > > On Apr 11, 2005 2:37 PM, Heath Borders <[EMAIL PROTECTED]> wrote: > > Yes, we basically just did it programmatically inside our bean. I agree > > with you that rendering rules should be separate from the application logic, > > but that doesn't mean it HAS to reside in the JSP. > > > > Could you maybe give a JSP example? > > > > > > > > On Apr 11, 2005 1:28 PM, Sean Schofield <[EMAIL PROTECTED]> wrote: > > > How would this work exactly? Would the backing bean add column > > > children to the data table as needed? I suppose that could work but > > > it seems like a roundabout way of doing it. Plus what if I want to > > > render the data differently in the columns depending on their type > > > (similar to tree2?) That render information really belongs in JSP not > > > in the backing bean. > > > > > > BTW, this would be different than tree2 b/c there would be *no* > > > interface required for the data. You would just provide the names of > > > the methods to call on the data to get the information. Presumably > > > you would use an interface in the actual application that uses it but > > > there would be no such requirement to make the new functionality work. > > > > > > sean > > > > > > > > > On Apr 11, 2005 2:22 PM, Heath Borders <[EMAIL PROTECTED]> wrote: > > > > What is wrong with doing a component-binding and setting this stuff up > > in > > > > your bean? > > > > > > > > We've had a few cases where the datatable's columns cannot be defined > > inside > > > > the JSP and this has worked just fine for us. > > > > > > > > > > > > > > > > On Apr 11, 2005 1:06 PM, Sean Schofield <[EMAIL PROTECTED]> > > wrote: > > > > > We're trying to use x:dataTable in a project for work right now. > > > > > There are a few limitations that I would like to address with the > > > > > group's approval. > > > > > > > > > > The main problem we're having is that you cannot have an open-ended > > > > > list of columns in your data. Specifically, in our application we > > > > > have a feature where user's can build their own SQL queries and > > > > > generate custom reports. We display the reports in a table now but we > > > > > don' t have the sort or page functionality of x:dataTable. We can't > > > > > use x:dataTable as is b/c we don't know how many columns there are in > > > > > advance (or what name to give the header.) > > > > > > > > > > I'd like to add a few additional attributes to x:dataTable that would > > > > > allow you to specify value binding expressions for determining the > > > > > names of the column headers along with which facet to use for which > > > > > column type. Everything would work as before so this is just extra > > > > > functionality. If there aren't any objections I would like to add the > > > > > functionality and a simple example for people to look at. If there > > > > > are problems with it (or improvements) then we can back out the > > > > > changes or make further changes. I think the idea is easier to > > > > > explain with actual code. > > > > > > > > > > Please let me know if you have a problem with this approach. > > > > > > > > > > sean > > > > > > > > > > > > > > > > > > > > > -- > > > > -Heath Borders-Wing > > > > [EMAIL PROTECTED] > > > > > > > > > > > -- > > -Heath Borders-Wing > > [EMAIL PROTECTED]
