Newbie question on Models with CB 2.6.x

My apology, first up, on the possibility this will be a somewhat length email. I'll try to keep it as short as possible.

Background

Try disabling caching on the “errorInfo property” object. It shouldn’t be cached as it needs to be fresh and new for each user.

In other words, instead of disabling all model caching, disable it on that specific model.

  • Gabriel

I wonder how many people actually know the true definition of a Value
Object?

Regards,
Andrew Scott
http://www.andyscott.id.au/

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of Kevin S. Anderson
Sent: Tuesday, 9 November 2010 9:39 AM
To: coldbox@googlegroups.com
Subject: [coldbox:6619] Newbie question on Models with CB 2.6.x

My apology, first up, on the possibility this will be a somewhat length

email.

I'll try to keep it as short as possible.

Background
--------------
Having switched to CB, one of the problems I've ran into is the

persistence

and shared scope when dealing with Model objects. In my past
development, I have used the following:

* Value Objects which contain the properties of a business entity (often
mirror of database table schema). The value objects primarily contain
encapsulated data with a few utility methods (inherited from a superclass)
for things such as collecting values (like CB's populate()), etc.
* Service Models which function as DAO/Gateway service.

In past applications, the service (model) object contained an "errorInfo"
property, which is a complex value object. Operations on a value object,
through the model, would trap any errors (logic and/or business rule
violation), and would populate the errorInfo. The handler, upon return

from

a model method, would simply check the isError() method, and if true, and
error had occurred. The error messages would then be extracted from the
service model (via getErrors()), and would be populated on the view.

Enter ColdBox
------------------
Needless to say, because of the persistence of models in CB, this got

really

UGLY!!! An error raised by one visitor was displaying to all, and a single

visitor

would see multiples of the same error (eg: 3 invalid login attempts would
show "Invalid log" three times, and because the errorInfo property was
persisting, they could NEVER log in).

I resolved this problem, temporarily, by disabling model caching, but that

is

not a long-term solution and may even be dangerous, right!?!

My question
----------------
Hence, my question, but first, a couple of assumptions:

1. It appears to me that models, in CB, should never have persisting data

(ie:

properties other than DSL).
2. It also appears that the models should always operating on the value
object, which is passed into a method as an argument, get manipulated or
evaluated, or whatever, and appropriate status returned.

Assuming the above, I've tinkered with two solutions, as follows:

1. Since the value objects are always instantiated in the handler, or via

a

model method return, I've considered wiring the error object into the

value

object itself. In the event of a business rule violation, the check for

error

state would be via object.isError(), etc. The only downside of this, that

I see,

is that it makes the value objects much more weighty than I prefer.

2. The other option is to have all service methods return a complex

structure,

Hi, Gabriel:

Thanks for your reply. Also, thanks for a useful response.

The errorInfo object is being instantiated via the new class() method, in variables.instance struct rather than via DSL. Any other wisdom? :wink:

Kevin

  1. “The other option is to have all service methods return a complex structure, with the errorInfo and any other return data structures.”

Your #2 is reasonable then. Although, I’d recommend re-factoring so that an object is returned that has, for example, getErrors(), hasErrors() methods among others instead of returning some type of structure.

A very simple result object can be seen on this page (2nd batch of code). You can modify it as needed to have whatever behavior you need.
http://www.12robots.com/index.cfm/2008/8/13/Form-Handling-and-Validation-with-ColdBox-ColdSpring-and-Transfer-Part-2

  1. Then your service could work a little like described in this comment:
    http://www.12robots.com/index.cfm/2008/8/13/Form-Handling-and-Validation-with-ColdBox-ColdSpring-and-Transfer-Part-3#cC1639611-FFE1-BE4C-43F2D8E27E92A15B

3: Then in your handler or even your view if you pass the result to it, you could do something like below.

resultFromServiceCall = myService.doSomething();

if resultFromServiceCall.hasErrors(){

}

  • Gabriel

Also, if you’re able to, you may want to jump straight to version 3.0 which is still under development and skip 2.6.x altogether.

  • Gabriel

Thanks, Gabriel! I actually started with 3.x (after buying Luis’ book [which is great]), but had some issues, most probably due to the learning curve. I downgraded to 2.6 simply because of a very short delivery schedule and 2.6 has worked beautifully. Next project will definitely be a 3.x one!