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