[jsr-314-open] Ajax inside a DataTable

[Cagatay Civici]

Hi,

I've faced with an issue in our app I'd like to share when trying to update the 
datatable itself from a command element located inside a column. Case is to 
select a row, execute logic and update the datatable. Basic code:

h:dataTable id=cars var=car value=#{tableBean.carsSmall}
h:column
f:facet name=header
Model
/f:facet
h:outputText value=#{car.model} /
/h:column

h:column
f:facet name=header
Action
/f:facet
h:commandButton value=Some Action 
actionListener=#{tableBean.handleRowAction(car)}
f:ajax render=cars /
/h:commandButton
/h:column
/h:dataTable

As datatable has a rowIndex = 0 during rendering of commandButton f:ajax 
defines the component id to render as cars:{rowIndex} where I should expect 
cars only. This is due to UIData.getClientId implementation as UIData
adds rowIndex for unique row ids. This causes an issue with a nested f:ajax 
case.

Regards,

Cagatay Civici

Re: [jsr-314-open] Ajax inside a DataTable

[Martin Marinschek]

Hi Andy,

 This is exactly what Trinidad's UIXCollection does.

ok, great, than this will fly.

 Perhaps one reason why I had a mental block on the UIData being a valid
 execute/render target is because I was always hoping that we could  avoid
 the findComponent() calls altogether and instead just use basic string
 manipulation to produce relative ids.   (We would use findComponent() in
 development mode just to verify that the specified id was valid.)   All of
 this component tree searching seems expensive, particularly when stamping
 out f:ajax content repeatedly (eg. in a data table).

I totally agree with you - and finding the component in development
mode sounds reasonable.

 This ties into another related topic that we left unfinished in JSF 2.0...
  Ideally we shouldn't need to send execute/render ids to the client at all
 as:

 1.  These ids can be expensive to produce (require findComponent() calls)
 2.  These ids bloat the size of our rendered HTML content.

 For 2.1 perhaps we should consider adding a mechanism by which Behaviors can
 hook into the lifecycle early enough to allow AjaxBehavior to set up the
 execute/render ids on the PartialViewContext after the postback occurs.
  This would be more efficient than requiring AjaxBehavior to aggressively
 render out the execute/render lists each time it is asked for a script.
  (Again, this could be especially important in the stamping case.)

Sounds nice as well! I have already heard complaints that the ajax
call-length was too large if used in table-cells, especially for
mobile devices.

best regards,

Martin