Steve Shucker wrote:
I need everything in one form
because the checkbox states should be persisted even when the popup
dialog is submitted.
[...]
My options as I see them:
[...]
- use a separate form with an async submit for the popup (may work,
but then I'd have to return some javascript to
Steve Shucker wrote:
Http only submits one set of form data. If I have two forms, only the
data from the form I submit is transmitted back to the server.
Tapestry wouldn't receive the other information I want to persist.
An async submit would get around this by not re-rendering the page to
Sam wrote:
I suppose Spring's transaction management would start a second
transaction after rolling back the first one, but ONLY if you call a
second service method that is wrapped in a transaction after getting
an exception in a prior one. Generally, my code is written such that
a listener
Thiago H de Paula Figueiredo wrote:
On Tue, 19 Jun 2007 18:24:10 -0300, Norman Franke [EMAIL PROTECTED]
wrote:
1. As Michael noted, they aren't thread safe.
2. This really gets to a bigger issue, in that these objects aren't
valid outside of a session. Once the session closes, they are
Steve Shucker wrote:
I just realized I had a bug relating to this yesterday and I could
use a little help solving it. I think the solution is to force the
hibernate session to flush before the response is committed, but I'm
not sure how/where to inject that call into tapestry. If I knew
Steve Shucker wrote:
Keep in mind the difference between a flush and a commit in hibernate.
A flush executes all the queued sql against the database without
committing the transaction. Hibernate does this whenever it has
changes that needed to be sent to the database before a query is run.
Steve Shucker wrote:
I'm really fishing for a hivemind guru to tell me how to inject some
code in the tail end of the WebRequestServicer.service() method.
Looks like something similar was discussed here:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg00316.html
Howard mentioned a possible
Steve Shucker wrote:
Unless I'm really screwing up, my check works with friendly URLs. I'm
using them. They way I understand the pipeline is that service
encoders take the original http request and do some preprocessing
before you end up with a WebRequest. Look at RequestCycleFactoryImpl
Steve Shucker wrote:
You're right and now I feel stupid.
It's an easy mistake to make, I think. Especially if it used to work and
something
in the internals of Tapestry changed at some point. I didn't mention it before
because I just assumed you weren't using friendly URLs...
(needed it in
Sam wrote:
In my case, I'm using Spring's transaction management code to inject,
via AOP, transaction semantics around service method calls. This
means that my transaction commits when the service method (called from
the listener, almost always) returns, so I can catch any exceptions
before
Geoff Callender wrote:
You are right, it's a type of EJB. Your question is all about
plumbing, and what I like about EJB 3 is that it does the plumbing
for you, so only have to think about pages, business services, and
entities.
[...]
As you can tell, I am almost as enthusiastic about EJB 3
carlos f wrote:
Why not rely on Hibernate's version support for detached objects and
versioning?
[...]
Why clone the detached object graph? Why not have the DAO reattach
it to
the session and save it -- assuming it passes your version check?
I don't mean to speak for Norman, but the point
carlos f wrote:
Unless I am mistaken, which happens all the time, but it appears that the
crux of his thread safety is, 1) storing detached instances on the client
side -- I am assuming that persists in the client page is a reference to
the ClientPropertyPersistenceStrategy
Sorry for my lack
Sorry again for the not 100% Tapestry related question, but I got such helpful
responses from my last question, and it's clear that there are a lot of people
on
this list that have already solved these issues that I'm running into (and I'm
getting jack from the Hibernate forums ;) )...
I've
Hi,
Thanks for taking the time to respond, this is really helpful information.
Norman Franke wrote:
My application only uses detached objects that it persists in the
client page for change detection (to determine if the record they
were editing changed while they were editing, which I flag as
Hi Geoff, thanks for the response,
Geoff Callender wrote:
Do any of these problems exist if you get a session bean to do the
work for you?
For example, a page to edit the user, using a session bean called
OrderService and an entity bean (using Hibernate if you like, as I
do) called Order.
Hi Steve,
Steve Shucker wrote:
I'm not sure if this will completely solve your problem, but I wrote
my own WebRequestServicerFilter that only applies the
session/transaction wrapping on non-asset requests.
Interesting! Thanks for that. There will still be some non-asset requests
in my
Steve Shucker wrote:
The only problem I've seen is if a user tries one of a
few long operations and then changes their mind and clicks on
something else. My filter still waits for the long operation to
complete or timeout (configured to 20 seconds) before beginning the
user's new request.
I know this isn't strictly Tapestry related, but since there has been a lot of
discussion here over the years related to integrating Hibernate with Tapestry,
I was
hoping I could draw on the community knowledge about this topic and get a little
advice. My apologies if this has been discussed
19 matches
Mail list logo
