Well, it was _almost_ applied, but was missing two of the test-case .cs files in the patch.
I'll try and make the time to get those into the patch, but otherwise it seems that the patch was OKed. Right now, I'm moving between two different countries. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jason Townsend Sent: den 17 juni 2009 18:02 To: [email protected] Subject: Re: Troubles with Automatic Transaction Facility (or something completely different) W -----Original Message----- From: Jan Limpens <[email protected]> Date: Wed, 17 Jun 2009 08:24:24 To: Castle Project Users<[email protected]> Subject: Re: Troubles with Automatic Transaction Facility (or something completely different) hi hendrik, any news of the trunk-state of the transaction patch? --jan On Jun 12, 2:46 pm, Jan Limpens <[email protected]> wrote: > sorry, never meant to upset you! as project lead you are kind of > obliged to do that, of course, broad places of castle need resharper > code cleanup! > I just wanted to say, if I had to review the patch, in the position of > the lead receiving it from a 3rd party, I'd have a hard time to tell > what is actually changing :) and thus probably err on the side of > safety (an tell the dev to provide a cleaner patch before applying > it). > > apology accepted? > > so as the lead, I can ask you - will the patch enter the trunk, or > will it be necessary to maintain the patched classes in my local copy? > > --jan > > On Jun 12, 2:24 pm, "Henrik Feldt" <[email protected]> wrote: > > > Have you tried applying it and then looking at the code directly? > > > I don't force anyone to accept the patch, I did it because I needed it. And > > I'm the project leader for that project.................. It followed the > > guidelines and I think the methods are re-ordered to match the interface... > > Anyway, you do as you wish, the patch works and I have tested it. > > > -----Original Message----- > > From: [email protected] > > > [mailto:[email protected]] On Behalf Of Jan Limpens > > Sent: den 12 juni 2009 16:42 > > To: Castle Project Users > > Subject: Re: Troubles with Automatic Transaction Facility (or something > > completely different) > > > On Jun 11, 11:16 pm, "Henrik Feldt" <[email protected]> wrote: > > > No, on the development list. Castle-project-devel > > Cannot find this anywhere, very strange. > > > It's very difficult to understand your patch because resharper made quite a > > mess with it. I seems it reordered every member of every class, so it is > > impossible to see what has changed. I would be surprised, if the path was > > accepted that way... > > > Right now I am a bit inclined to have nhibernate leak towards my controllers > > and leave the repository pattern to gain access to sessions and > > transactions... > > quite a bit of work, but could be done incrementally. > > > > -----Original Message----- > > > From: [email protected] > > > > [mailto:[email protected]] On Behalf Of Jan > > > Limpens > > > Sent: den 12 juni 2009 00:11 > > > To: Castle Project Users > > > Subject: Re: Troubles with Automatic Transaction Facility (or > > > something completely different) > > > > On 11 Jun., 01:21, "Henrik Feldt" <[email protected]> wrote: > > > > Not quite. If you apply the patch I sent to the mailing list for the > > > > transactions a few days/weeks ago, you can decorate your method with > > > > [InjectTransaction] and have a parameter: "ITransaction tx" which > > > > then will have a method: "SetRollbackOnly()" which you can use to > > > > roll the transaction back. > > > > Interesting! Are you sure it was_this_ list? I could not find such a > > > post (I searched the group for 'InjectTransaction'...) > > > > > (Also only getting the innermost exception instead of the full > > > > stack-trace can probably cause you some trouble in the future when > > > > you don't know what code-path the thing went down.) > > > > In 99% of the cases this is where I get the relevant info from (and > > > the stack usually shows where it came from). But you are right, this > > > can go the wrong way... > > > > > In your case though, you have_a lot_ of things going on in your > > > > controller and you should definitely move it to a few domain and > > > > application services to maintain separation of concerns. That way > > > > you can also expose them as web services should you need to. > > > > Yip, this is the one super big method I am having in this site. But > > > actually it is already consuming a few services to construct an Order > > > object. This is a complicated process, but I doubt it would be less > > > complicated, if I put it into several methods without reuse. To me, > > > this would be a smell just as well... > > > > > May I ask how come you're returning view datas from your controller? > > > > Which view engine is that? > > > > I created a custom return binder, that puts the returned object into > > > PropertyBag["viewData"]. Just a few lines of code, but I hardly > > > address PropertyBag + strings that way. On view side I just go $ > > > {viewData.SomeProperty}. The action needs the attribute > > > [return:PropertyBagReturnBinder] > > > > using System; > > > using Castle.MonoRail.Framework; > > > > namespace ProjectBase.Utils > > > { > > > [AttributeUsage(AttributeTargets.ReturnValue, > > > AllowMultiple = false, Inherited = false)] > > > public class PropertyBagReturnBinderAttribute : > > > Attribute, IReturnBinder > > > { > > > public void Bind(IEngineContext context, > > > IController controller, IControllerContext controllerContext, Type > > > returnType, object > > > returnValue) > > > { > > > > > > context.CurrentControllerContext.PropertyBag > > > [Name] = returnValue; > > > } > > > > private string name = "viewData"; > > > public string Name > > > { > > > get { return name; } > > > set { name = value; } > > > } > > > } > > > } > > > > Thanks! > > > > Jan > > > > > Cheers, > > > > Henrik > > > > > -----Original Message----- > > > > From: [email protected] > > > > > [mailto:[email protected]] On Behalf Of Jan > > > > Limpens > > > > Sent: den 10 juni 2009 22:43 > > > > To: Castle Project Users > > > > Subject: Re: Troubles with Automatic Transaction Facility (or > > > > something completely different) > > > > > > Catching all exceptions will make the transaction try to commit. > > > > > So the only way to stop a transaction from committing would be to > > > > actively throw an exception and present it to the user as a rescue? > > > > I thought, the transaction would have been rolled back, before the > > > > exception was thrown to me. > > > > I am quite in a bit of trouble, if this is as you say... > > > > > > Could you send a small .sln with a repro? > > > > I will try... > > > > > > You're kind of eating the exceptions in a lot of places... Have > > > > > you tried letting the exception bubble out of the action instead, > > > > > using a [HandleError] page? > > > > > Actually I am catching my exceptions at the last possible instance, > > > > at the controller, where I am actually in the position to do > > > > something about it, if at least informing my users or redirecting or > > > > trying some different approach. > > > > > Most of the transaction intensive actions (form post actions) use > > > > JSONReturnBinder. I use a defined Json format to inform my users of > > > > possible errors. Dunno if I can use a [HandleError] page (== > > > > rescue??) > > > here. > > > > > In this special case everything goes fine database wise. The > > > > transaction_should_ commit, but it does not due to a failure in a > > > > totally different service. > > > > > Thanks! > > > > > Jan > > > > file_tx_delta.rar > > > 29KViewDownload > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en -~----------~----~----~----~------~----~------~--~---
