myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Marinschek <martin.marinsc...@gmail.com>
Subject Re: ResponseWriter with null argment fro componentForElement
Date Sat, 20 Aug 2005 10:21:08 GMT
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 <craigmcc@gmail.com> wrote:
> On 8/20/05, Martin Marinschek <martin.marinschek@gmail.com> 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

Mime
View raw message