Re: Work on Release 2.6: Maven Archetype and Tutorial Examples
Naveen Chawla <[email protected]> Mon, 21 Jan 2013 03:25:30 +0000
| Newsgroups | gmane.comp.java.prevayler |
|---|---|
| Message-ID | <CAGs7EcXNJK1-+nvfY=LGjqRFeGwMzo4oi7GRfBGq7s5mWemfZg@mail.gmail.com> |
On 20 January 2013 14:52, Klaus Wuestefeld <[email protected]> wrote: > Naveen, would you like commit rights? > > Yes ok. I don't know if I will use them though. > > > I'd also prefer the word "prevalentObject" (& "Prevalent Object") in the > > JavaDocs/manual/source code because "prevalentSystem" doesn't seem as > > specific to me. > > I disagree. The least specific you can be in an OO context is to call > something an Object. > > > Yes exactly, the word after "Prevalent" should be the least specific you can be in an OO context, that is, specifically the fact that it can be any type of object :) The word "system" seems to introduce a little bit of the unknown (instrumented?includes the disk content?includes the hardware?) - is the thing that is prevalent technically anything more than a plain old object? In reality no. Hence I believe it's more easily and more accurately conceptualized if it is called the "Prevalent Object". "Prevalent" is the sufficient qualifier to specify what for and how that object is used - that is, that thing you intend to persist using Prevayler. It's also the object (variable) you must deal with - "business objects", as you call them, are not. So instead of describing a "Prevalent System" with "Business Objects", I think it's better conceptualized as a "Prevalent Object". I have never had, nor have come anywhere near close to having the "baptism/initiation problem" thinking of it this way from the start. > > > I'd > > like the manual's code examples to not go beyond a simple class with a > > boolean. > > Too simple. It might seem you have to do that for every instance you > change in your system. It doesn demo the need to query from within the > transaction (what used to be called the baptism problem). > > > The key persistence rule at the start "To persist an instance of... " "ensure any changes to it are done via the prevalentObject variable in Transactions", plus the "//perform changes to prevalentObject here" comment in the code example, should satisfy both of those concerns. Please see them again (in context after the "What is Prevayler? paragraph). Query-by-id-and-change is only a small subset of possible transactions. It can be a straight top-level or non-collection-path method call too. So the intro/reference code examples should demonstrate what is required in the most general way. If you see my proposal it should satisfy all concerns, with only maybe just a few word tweaks to make it clearer. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 _______________________________________________ To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion _______________________________________________ "Databases in Memoriam" -- http://www.prevayler.org