Re: Yes, but what is business logic? (was: Business Logic in View a bad thing (was floating point types))

[Lloyd Llewellyn <su...@twilight-systems.com>]

> Think about it: "if the user's score is this..." this is BUSINESS LOGIC. You
> should never have this kind of code in your view.

This is not necessarily business logic - where the boundary lies between
business logic and the view depends on the application design.  The
requirements of an application's view may simply be "display the results
to the user".  The business logic doesn't care how that is done as long
as the results are clear.

If you get too pedantic about separation of view and content, you end up
with a situation where deciding whether a pixel on a monitor should be
on or off becomes a "business logic" decision.  Not all logic is
business logic.  Some logic is required to render the view.

Rather than focusing on the example presented in the previous message, I
believe the question is: Is the float data type so complex and
incomprehensible to the designer that all manipulations of that data
type should be the exclusive domain of the developer?  I submit that it
is not.  

A float is no more complex than, say, a string.  It's a basic data type
- there is no reason why designers shouldn't be able to inspect and use
floats.  There is no logic to a float - it is simply a data type. Please
tell me where logic of any kind - much less the business logic that
defines an application - comes into play here.

I believe there is no legitimate connection between the prohibition on
floats and the separation of view and business logic.  If anything,
forcing a designer to have knowledge of utility objects placed in the
context in order to deal with a fundametal data type like a float
threatens this view/logic separation more.

Re: Yes, but what is business logic? (was: Business Logic in View

[Nick Bauman <ni...@cortexity.com>]

> 
>> Think about it: "if the user's score is this..." this is BUSINESS
>> LOGIC. You should never have this kind of code in your view.
> 
> This is not necessarily business logic - where the boundary lies
> between business logic and the view depends on the application design. 
> The requirements of an application's view may simply be "display the
> results to the user".  The business logic doesn't care how that is done
> as long as the results are clear.

Your point, that business logic is a grey area, defies the definition
entirely. It's pretty clear: Business logic is logic applied to the model of
the application. :) Deciding what something should look like is clearly not
business logic. Webiste navigation decisions are clearly not business logic
either. Deciding whether a user's test score is valid or not... That is
CLEARLY business logic that belongs in the model of the application. 

Writing applications that are not clear on what is and is not business logic
indicates poor design, not "grey area" definitions of what can and cannot be
business logic.

> If you get too pedantic about separation of view and content, you end

It's not pedantic. It's very clear.

> up with a situation where deciding whether a pixel on a monitor should
> be on or off becomes a "business logic" decision.  Not all logic is
> business logic.  Some logic is required to render the view.

You just proved my point with that last sentence.

> Rather than focusing on the example presented in the previous message,
> I believe the question is: Is the float data type so complex and
> incomprehensible to the designer that all manipulations of that data
> type should be the exclusive domain of the developer?  I submit that it
> is not.  

And I agree with you in principle, but that does not negate the value of not
having business logic in your view.

> A float is no more complex than, say, a string.  It's a basic data type
> - there is no reason why designers shouldn't be able to inspect and use
> floats.  There is no logic to a float - it is simply a data type.
> Please tell me where logic of any kind - much less the business logic
> that defines an application - comes into play here.

This isn't a semantic argument. I never said that floats have intrinsic
logic of their own. Don't misquote me.

> I believe there is no legitimate connection between the prohibition on
> floats and the separation of view and business logic.  If anything,

Woah, nelly. To be perfectly clear: There is absolutely a legitimate
connection, but not in a direct way. The connection involves the use of
floats in the view that typically involves calculations that have nothing to
do with visualization or navigation.

The only halfway decent example for the use of fp's was in drawing a graph
on a page. And the complexity of that indicates that a context tool would be
a better use of ones time than to extend the Velocity language ;) Keeps the
page size down, too.

> forcing a designer to have knowledge of utility objects placed in the
> context in order to deal with a fundametal data type like a float
> threatens this view/logic separation more.

Disagree with you about the context tools. A context tool becomes the
"contract" between the designer and the engineer: the "C" in the MVC paradigm.

-- 
Nick Bauman
3600 N. Dupont
Minneapolis, MN 55412
Mobile: (612) 232-7120
SMS: 6122327120@voicestream.net
Home: (612) 522-0165

Re: Yes, but what is business logic? (was: Business Logic in View a bad thing (was floating point types))

["Geir Magnusson Jr." <ge...@optonline.net>]

On 8/28/01 4:06 AM, "Lloyd Llewellyn" <su...@twilight-systems.com>
wrote:

> 
>> Think about it: "if the user's score is this..." this is BUSINESS LOGIC. You
>> should never have this kind of code in your view.
> 
> This is not necessarily business logic - where the boundary lies between
> business logic and the view depends on the application design.  The
> requirements of an application's view may simply be "display the results
> to the user".  The business logic doesn't care how that is done as long
> as the results are clear.
> 
> If you get too pedantic about separation of view and content, you end up
> with a situation where deciding whether a pixel on a monitor should be
> on or off becomes a "business logic" decision.  Not all logic is
> business logic.  Some logic is required to render the view.

I agree in principle, that it's hard for 'us' to say what is business logic
and what isn't, especially when Velocity isn't a niche tool, but more
general purpose.
 
> Rather than focusing on the example presented in the previous message, I
> believe the question is: Is the float data type so complex and
> incomprehensible to the designer that all manipulations of that data
> type should be the exclusive domain of the developer?  I submit that it
> is not.  
> 
> A float is no more complex than, say, a string.  It's a basic data type
> - there is no reason why designers shouldn't be able to inspect and use
> floats.  There is no logic to a float - it is simply a data type. Please
> tell me where logic of any kind - much less the business logic that
> defines an application - comes into play here.
> 
> I believe there is no legitimate connection between the prohibition on
> floats and the separation of view and business logic.  If anything,
> forcing a designer to have knowledge of utility objects placed in the
> context in order to deal with a fundametal data type like a float
> threatens this view/logic separation more.

I think it is a bit extreme to deny any connection.  I think that there is a
connection - what that connection is remains the question. This still comes
down to how substantial we believe the connection to be.  One of our driving
philosophies has always been to keep it simple, clean, and support the MVC
contract.  I think that recognizing that has served us very well and there
are quite a few examples of where we do diverge from that path for
convenience, for example the quiet reference, $!.

 
geir