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 -~----------~----~----~----~------~----~------~--~---
