Gary, I've seen this proposal on the struts-dev list. I haven't really had time to delve into it yet but in this case it seems to be solving the wrong tree. While it might be appropriate to programatically add components to the tree in some cases, it does not make sense in this case.
I have some issues with Heath's suggested workaround. I think JSP is the easiest and most logical way to configure how your columns would render (just like its done now with h:dataTable.) I am not looking for a better way to create these components as I see the creation of them to be unecessary. I will take a closer look at your clay proposal when I get some time to check in on Shale but I don't think it makes things any easier in this case. sean On Apr 11, 2005 3:25 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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] >
