Re: [jsr-314-open] <h:dataTable> binding vs. ui:repeat

Ok, so perhaps I should explain my dataTable/ui:repeat use case a little bit more, since it seems like some of these options are not going very smoothly for me. I've labeled 3 questions, just to keep this long message slightly more organized. *The Scenario:* ----------------------------------------------------------------------- Everything on your website is RequestScoped -- There are no stateful pages or SessionScoped beans whatsoever. That means that data is loaded every time a user accesses a page via GET, POST, etc... if an ajax event on a page updates some value - it actually needs to be updated via a service call on the back-end. You have an Object: "Task" -- a Task has an Assignee, a few Dates, and a Status. In order to keep the look and feel of Tasks consistent on the UI, you've created a "taskBlock.xhtml" composite component to handle the layout. However -- you would like inline editing and updating of the Task data to work via Ajax. Each taskBlock component instance needs to be able to save, delete its given Task object instance. Hence, you need: * a delete(Task) action to occur on a commandButton action event (this part is easy thanks to JBoss Seam/EL2) * a save(Task) method to be called on a ValueChangeEvent for each editable field The latter is the hard part, because the task object may have come from a list, it may have been passed in by itself. A workaround would be to have a "Save" button, but that's an extra click for the user, and ugly, etc, lots of reasons why you wouldn't want this. ValueChanceListeners do not accept properties, or allow user-specified ValueChange Methods to be supplied. *Solutions?* ----------------------------------------------------------------------- I tried including a hidden commandLink in the Ajax execute="" attribute in order to trigger the action after the ValueChangeEvent, but it never fires -- not sure if that's a bug or intended. ***Question 1: *Almost every AJAX framework I know of allows you to simply execute a method on the server side, with or without params, and return a result... is this possible with JSF's Ajax framework? What would be optimal, would be if you could supply, as mentioned in a previous message in this chain, a ValueChangeMethod: <h:inputText> <f:valueChangeMethod method="saveTask(t)" /> </h:inputText> or <f:valueChangeMethod method="saveTask(event, t)" /> Which is even more powerful if you consider the new EL, or JBoss EL. If the method contains a "ValueChangeEvent event" in the method signature, it should be injected into the call. Thus, you would not have to write extra classes, or bind any objects, or retrieve any rows from a DataModel or DataTable. ***Question 2:* Without changing the Spec, how would you achieve this and ensure the user interaction is the same? The value needs to be saved via Ajax when they change it on the UI... without clicking a save button. If there is no way to support this type of functionality in the spec currently, then I propose we add it. ***Question 3:* Is this really an uncommon use case? Does everyone make a separate view/edit page for lists of items? The UI JavaScript, CSS, and HTML is not my strong point -- perhaps a component writer would invest more time with JSF's Ajax JavaScript in order to get the behavior right via custom JS, CS, and HTML..? I'm basically trying to figure out if I'm way off base here, and need a paradigm readjustment. It seems like nobody else is raising issues like this online, so it's possible that JSF doesn't need to change; I'd just like to know what everyone else is eating before I push for a change ;) --Lincoln On Fri, 2009-08-07 at 14:14 -0700, Alexander Smirnov wrote: > ui:repeat is a normal JSF component that supports binding but > <c:forEach> is compilation directive only that has no component > associated with tag. > The question just recalls me one forgotten problem: h:dataTable and > ui:repeat is complete different components that doing similar jobs. > While ui:repeat knows about UIDataTable and works well inside it, > DataTable itself has no clue what UIRepeat is iteration component, > therefore rendering a set of tables using ui:repeat is not possible. > > > On 08/03/2009 12:54 PM, Lincoln Baxter, III wrote: > > So here's one of those,"why is this different than that?" questions: > > > > Unless I'm mistaken, ui:repeat is not a component and therefore cannot > > be bound to a backing bean, but -- would it make sense to support > > something *like*<h:dataTable> in order to support determining the > > selected row on action events and value change events? A component that > > would privide a bindable DataModel / List<Object> row access like > > <h:dataTable>? > > > > *My use case is this:* > > > > * Managed Bean contains a List of objects > > * Each object rendered to screen with input field > > * User submits the input field (with a command link or button, etc) > > * ManagedBean needs to take action on the appropriate row values > > > > > > I have a list of objects - I need to render them onto the screen (not > > necessarily in an HTML table, maybe a<ul> would be nicer) but I can't > > use<ui:repeat> because each row has a commandLink, and I need to be > > able to determine which row the user clicked on in order to take the > > appropriate action. > > > > EL2 helps with this, but... now what if I have a ValueChangeEvent for an > > input field on each<li> row? Now I can no longer use EL2 to pass the > > row into the ValueChangeListener, and I would have to use something like > > <f:setPropertyActionListener> which is not only getting increasingly > > complicated, but I'd also have to set an attribute /inside/the VCL > > itself, or in a bean VCL knows about - then referencing it - which is > > terribly ugly. Now try to fit all that into a composite component and it > > gets really ugly to try attaching tons of VCLs or ALs or SPALs to values > > inside the component. > > > > Am I attacking this problem in the wrong way? Is this one of those > > things that has an easy solution I'm not seeing? Or is this a genuine gap? > > > > --Lincoln > > > >