Hi, No, on the development list. Castle-project-devel
I attached it to the mail. Nice with the return binder. I'll have a look into that myself ;)... Cheers, Henke -----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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
file_tx_delta.rar
Description: Binary data
