Hey... I did a little follow-up on this and decided to create an "event-safe
loop" that can restore the state of the loop variable using the page
activation context. It's not quite perfect, but it's good enough for my
needs right now. For my application, the resulting code ended up looking
much c
Probably the tip I needed was this:
"When using an EventLink inside a loop, be sure that your event handling
method does not refer to any loop variable either directly or indirectly.
Especially be cautions of referring to parameters that may have been bound
to any loop variable or a field of a lo
Nathan, since you invested considerable amount of time debugging a
case that seems to be just a standard event bubbling behavior, do you
think that there is anything you'd think the framework or somebody
could do to make the logical error in your code more visible? I know
Tapestry documentation has
For future reference... this in fact turned out to be a bug in my code.
Under normal circumstances Tapestry will NOT attempt to perform parameter
bindings when processing the EventLink. However, I accidentally left a line
of code in my event handling method which referenced one of the parameters
On Mon, Feb 15, 2010 at 3:21 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Mon, 15 Feb 2010 03:51:08 -0200, Nathan Kopp
> wrote:
>
> This looks like a bug in your code, most probably by working in a T4-ish
>>> way in T5.
>>>
>>
>> Well, it's certainly a "bug" in that I'm tr
On Mon, 15 Feb 2010 03:51:08 -0200, Nathan Kopp
wrote:
This looks like a bug in your code, most probably by working in a T4-ish
way in T5.
Well, it's certainly a "bug" in that I'm trying to do something that T5
doesn't seem to handle out-of-the-box.
I disagree. A bug is something that doe
I agree... It sounded like a normal use case to me and I was fully expecting
it to "just work." But it didn't. I'm not trying to complicate things...
I'm looking for an uncomplicated solution... but I have not found one yet.
All of the code necessary to run this example can be found in my origin
On Sun, Feb 14, 2010 at 3:07 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Sun, 14 Feb 2010 00:10:02 -0200, Nathan Kopp
> wrote:
>
> There are two things preventing this from working:
>> First, Tapestry does not replay the loop when processing the eventlink
>> (like it did
I also think that you're over-complicating this. To me this sounds like a
very normal use case, looping over items and creating a form for each one.
It should "just work". And it shouldn't be too many lines of complicated
code either, so the code listed here confuses me a bit.
Someone should post
On Sun, 14 Feb 2010 17:33:43 -0200, Nathan Kopp
wrote:
Even with your suggested change, this would still generate a null pointer
exception (NPE) in the same place, since the problem lies with
"fooLoopVar" being null when the eventlink is click is processed by
Tapestry.
You simply can't
Good thought, but the copy of Donkey isn't the problem. (Actually, when
using Hibernate or JPA, you'd want to make a copy to allow "cancel" to work,
because altering a JPA entity by binding directly to the "real" instance
could cause the database to be updated immediately... JPA/Hibernate doesn't
Hi!
On Sun, 14 Feb 2010 00:10:02 -0200, Nathan Kopp
wrote:
There are two things preventing this from working:
First, Tapestry does not replay the loop when processing the eventlink
(like it did in the 3.x and 4.x days). Therefore, "fooLoopVar" never
gets changed from its default of nul
Hi Nathan,
> Anywhere on my site where I display a Donkey, I want to let the user edit the
> instance.
So then do exactly that... Tapestry 5 is sometimes simpler than you might
expect, to me it seems you are complicating things unnecessarily... why are you
creating new instances when editing? Y
13 matches
Mail list logo
