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

Reply via email to