Ok Josh, I'll take you up on that. :) I submitted a patch on TAP5-1413
https://issues.apache.org/jira/browse/TAP5-1413
Please let me know if I submitted it right. I want to make sure I'm
submitting patches that can actually be used.
Also, I'd love to see this patch get included sometime as I thi
> I believe that is what is happening, but does anyone know if this
> "should" work? I want to make sure I'm not taking advantage of
> something that is just a side effect and may disappear in the future.
The docs for MultiZoneUpdate say:
A mapping from client-side zone ids to objects that can
r
On Fri, Jan 14, 2011 at 10:52 AM, Thiago H. de Paula Figueiredo
wrote:
> On Fri, 14 Jan 2011 14:40:52 -0200, Mark wrote:
>
It turns out there is a simple way to do this. So simple I was
overlooking it. When you create a multizone update you give it the
client id and the zone you wi
On Fri, 14 Jan 2011 14:40:52 -0200, Mark wrote:
It turns out there is a simple way to do this. So simple I was
overlooking it. When you create a multizone update you give it the
client id and the zone you wish to update. The zone will render with
the present context. However, you can also simp
>> It turns out there is a simple way to do this. So simple I was
>> overlooking it. When you create a multizone update you give it the
>> client id and the zone you wish to update. The zone will render with
>> the present context. However, you can also simply give it a string
>> with the contents
On Thu, 13 Jan 2011 23:16:32 -0200, Mark wrote:
It turns out there is a simple way to do this. So simple I was
overlooking it. When you create a multizone update you give it the
client id and the zone you wish to update. The zone will render with
the present context. However, you can also simp
It turns out there is a simple way to do this. So simple I was
overlooking it. When you create a multizone update you give it the
client id and the zone you wish to update. The zone will render with
the present context. However, you can also simply give it a string
with the contents you want rende
> Can you trigger the update via onchange instead of keyup? I'm not sure
> how to keep the focus, or why it's being taken away...
onChange will fire the update, but it requires the user move the focus
out of the changed textbox to do the update. Like I said this isn't
being designed for superman a
> Thanks for your suggestion. It sounds like I'm not overlooking
> anything obvious. :)
Well, at least not obvious to me!
> Redrawing the entire loop works with some
> issues. I figured if it was capable of redrawing the entire loop then
> I should be able to get access to what I need to redraw o
Thanks for your suggestion. It sounds like I'm not overlooking
anything obvious. :) Redrawing the entire loop works with some
issues. I figured if it was capable of redrawing the entire loop then
I should be able to get access to what I need to redraw only certain
parts of it.
The problem I'm hav
> but that just sets
> every price to the same thing as the row that is being updated. This
> is because the context of the row/event that triggered the updated
> doesn't provide the context for the zones that need to be updated.
Ah... static structure ;)
You have a single zone component and when
I have a form with a loop that looks something like this:
|__QTY__|_ITEM__|__PRICE__|
|__1_|_soup__|$1|
|__3_|_peas__|$3|
etc.
Users can change the quantity and it automatically changes the price.
Each price is in its own zone and the KeyUp action on the
cooresponding QTY
12 matches
Mail list logo
