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
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 javascri
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 liste
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
> bef
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
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:
> 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:
> 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 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
>
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
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 imple
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 m
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 poi
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 EJ
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
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 app
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 Ord
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
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 befo
19 matches
Mail list logo
