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