Ok, right, I think this is how it is done anyways. So if there is something not working like this, we should open a bug request for this certain part of the code.
regards, Martin On 8/21/05, Adam Winer <[EMAIL PROTECTED]> wrote: > There should not be any need to pass a UIComponent for all tags - > all that matters is that the UIComponent is passed to the > top-most tag. IDE's should be smart enough to deal with > this (JDeveloper is, and reading between the lines of Craig's > message, it sounds as though Creator is too). > > So, for HtmlDataTable, there is no need to pass any component > for "tr". However, for "td" and "th", you should pass the UIColumn > instance for best results. For SelectOneRadio, you should ideally > pass any UISelectItem instance (if one exists) to startElement > calls for the "input" and its associated "label". > > -- Adam > > > On 8/20/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > Ok, I see. > > > > What I remember of the MyFaces codebase, the UIComponent attribute is > > set for the top-most html tag element (the one which is one to one > > linked to the component), but not for the children tag elements. > > > > e.g, for the table in the HtmlDataTable case, but not for the tr/td > > tags. We will need to change this then. > > > > Can I ask Frank Ye again to open a jira request on this? > > > > regards, > > > > Martin > > > > > > > > On 8/20/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > On 8/20/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > > > So you are saying that for every tag that is rendered for a certain > > > > component the component needs to be passed? > > > > > > > > My impression was that this parameter was only to be set for like the > > > > main tag of this component, in this case the table component. > > > > > > > > If that is necessary, this will be a major change in the sources. Are > > > > you going to open a jira-issue on this? > > > > > > > > > > I cannot speak to the specifics of the MyFaces implementation (haven't > > > had time to look), but I'd like to discuss the motivation for why the > > > startElement() has a component argument in the first place. > > > > > > Consider a visual development tool like Sun Java Studio Creator (for > > > which I am the architect), where you drag a Data Table component onto > > > the design surface. Now, let's assume that, within the context of a > > > particular tool, you have bound the data table component to some > > > underlying source of data, and created a bunch of column children > > > components (with grandchildren for the actual data your table is > > > presenting). > > > > > > Now, put yourself in the role of the developer using such a tool. She > > > wants to change some properties on the individual component for a > > > particular column. So, she moves her mouse over the visual > > > representation of this component on the visual design surface, and > > > clicks the mouse button. > > > > > > What happens next? > > > > > > In the ideal scenario, a tool will detect that the mouse click > > > occurred over an instance of the detail component included in the > > > corresponding column, and will highlight that detail component in the > > > visual representation (and expose that component's properties on a > > > property sheet). But that only works if the design surface can detect > > > that the mouse click belongs to a *child* component of, say, the table > > > being dispalyed ... otherwise, such a mouse click can only be > > > attributed to the table component itself. > > > > > > The moral of this story is that *all* components should faithfully set > > > the UIComponent property of the ResponseWriter.startElement() call. > > > If you (as a component developer) do not do this, you will be at a > > > competitive disadvantage to other components (with equivalent > > > functionality) that understand how important it is to create > > > tool-friendly components. > > > > > > If you are a component developer, you should *always* make sure that > > > the UIComponent parameter to the startElement() call is the finest > > > grained JSF component relevant to your particular use case. > > > > > > If the MyFaces components *never* specify a component argument to the > > > startElement() call, then this is going to be a significant barrier to > > > them ever being robustly supported by GUI-oriented design time IDEs. > > > (((Side note to component developers -- put away your snide comments > > > about what kind of development environment *you* use. This is all > > > about what your *customers* use.))) > > > > > > Craig McClanahan > > > > > > > > > -- > > > > http://www.irian.at > > Your JSF powerhouse - > > JSF Trainings in English and German > > > > -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
