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

Wed Aug 12 19:45:45 EDT 2009

my +1.

2 steps:

1) add a method-attribute to the f:valueChangeListener-tag
2) get Unified-EL to also support passing the formal parameters (see
my mail to the spec lead)

with that, everything should be sorted.

regards,

Martin

On 8/13/09, Pete Muir <pmuir at redhat.com> wrote:
> IMO this is not an uncommon use case, and we should support via (1)
>
> On 12 Aug 2009, at 23:31, Lincoln Baxter, III wrote:
>
>> 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
>>> >
>>> >
>
>

-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces