Would you consider the code to “color a cell of a grid when the value in the cell exceeds a maxvalue” Business logic or UserInterface logic ?
I am not in the office until Augst 27th 2012. I will not be checking my mail and phone on a regular basis, but will reply to your mail as soon as I can.
If you need support from appSolutions, please send your mails to support@app-solutions.com.
If you need Roundtable support, please send mails to :
support-europe@roundtable-tsms.com.
Jeg er væk fra kontoret indtil den 27. august, og checker ikke mail og telefon regelmæssigt. Jeg vil dog svare på din mail så snart som muligt.
Hvis du har behov for support, kontakt venligst support@app-solutions.com, så vender vi tilbage så snart det er muligt.
Administrative henvendelser kan ske til : admin@app-solutions.com.
Med venlig hilsen / Regards
Thomas Hansen
appSolutions a/s
Would you consider the code to “color a cell of a grid when the value in the cell exceeds a maxvalue” Business logic or UserInterface logic ?
The decision (returns a logical value) is BL.
The coloring of the cell (presentation) is UI.
mmm...
Coloring: we agree
Decision: i tend to agree but: make a BL/Appserver call for each cell, isn't that a bit too much?
And what about coloring a cell depending of the value of another cell ?
Decision: i tend to agree but: make a BL/Appserver call for each cell, isn't that a bit too much?
Why don't you add logical fields to the temp-table and get all values in a single call?
You mean like fields:
- Length
- LengthExceedsMaxLength
And then check the two values in the UI ? So checking two values in a grid is not BL ?
Met vriendelijke groet,
Maurice Stassen
Software Engineer - Projectleider
E-mail mstassen@datamex.nl
Datamex Automatisering B.V. Telefoon (076) 5 730 730
Minervum 7368, 4817 ZH Breda Fax (076) 5 877 757
Postbus 5515, 4801 DT Breda Internet www.datamex.nl
And then check the two values in the UI ? So checking two values in a grid is not BL ?
I don't quite understand what you mean with two values?
The BL says, if Length exceeds max value and stores that in the temp-table.
The UI only knows about it's capabilities to visualize that (the BL shoudn't know about a grid at all!). So on the Grid you add the conditional formatting based on a Rule "LengthExceedsMaxValue = TRUE".
That just needs a single value. And I think that's acceptable for the UI. A UI completely without rules is impossible. But the rules should be as simple as Value = TRUE or Value = FALSE.
mstassen wrote:
mmm...
Coloring: we agree
Decision: i tend to agree but: make a BL/Appserver call for each cell, isn't that a bit too much?
And what about coloring a cell depending of the value of another cell ?
Hi Maurice,
I think you are confusing two issues here in that you are assuming that BL must always run on the server. That is not the case.
The goal is to code the BL only in one place, but that place does not have to be on the server as long as you don't have to duplicate it for different clients.
If the code does not require database access it does not have to run on the server (but it can).
We put code like this in a common directory because it can run both on the server and on OpenEdge clients (which I think you have).
So if you are developing a windows client you don't have to make the AppServer call, the call that determines if the value exceeds the max can be run on the client.
So this part of the BL can happily be executed both on the client and the server as long as you have an OpenEdge client.
If you have a web client you need to do a server call.
-peter
Ok, that's the best way indeed...
Met vriendelijke groet,
Maurice Stassen
Software Engineer - Projectleider
E-mail mstassen@datamex.nl
Datamex Automatisering B.V. Telefoon (076) 5 730 730
Minervum 7368, 4817 ZH Breda Fax (076) 5 877 757
Postbus 5515, 4801 DT Breda Internet www.datamex.nl
It's correct, that not every BL rule needs to be executed in every situation on the AppServer.
But it should be designed to work on the whole resultset and not row by row - a single AppServer call via WLAN may cost as much as a 1/10th of a second. You don't want that overhead per row.
The client should flag with his request, if he's actually interested in this flag or not.
mikefe wrote:
Would you consider the code to “color a cell of a grid when the value in the cell exceeds a maxvalue” Business logic or UserInterface logic ?
The decision (returns a logical value) is BL.
The coloring of the cell (presentation) is UI.
I would say that both happen in the presentation layer. If you're using a MVP pattern (or similar), the logic to decide whether a UI element needs to be flagged as a warning/error/whatever is made in the presenter logic (UI logic). The decision on how that's shown to the user is part of the view's logic (change the b/g colour of the cell or add a tag to the HTML page).
Also, as Peter van Dam says, there's nothing stopping you reusing your business logic on a client; that would fit into the Model aspect of the presentation layer. And the model certainly provides information to the presenter's UI logic. So for instance, if you have a navigation panel with first, prev, next, last elements (and these can be buttons or links or swipe touches depending on the actual UI), the Presenter asks the Model for the current record's relative position and tells the View what each of those elements' state is. The View decides how to show that to the user. So the Presenter (UI logic) does the thinking about what it means to the UI when the current rewcord is first or last or neither or there's no data.
-- peter
And what if the Maximum value we have to compare the current Length to is item group specific and you need that for a batch of 200 rows and you may have to deal with 200 different limits?
The only place where you can have this information is the Business Entity. And that's typically run on the server.
pjudge schrieb:
The decision on how that's shown to the user is part of the view's logic (change the b/g colour of the cell or add a tag to the HTML page).
I believe there are two levels of decision logic.
The presenter - or whatever model on the UI you are choosing - should make the visualization choice based on a boolean value. no more.
To determine this boolean vlaue is BL.
This whole question takes on a somewhat different complexion if one backs away from assuming that the client is an ABL Windows client. If one makes that assumption, then, to be sure, it is easy to put the test of boundaries and such on the client "for efficiency" ... but what if the client is a browser or a Java or .NET client or even something that has no UI at all? Then, one is in the position of having to duplicate that test over and over and over again in different languages.
However, I think we should also consider the nature of the test because it seems to me that there are at least two somewhat different possible purposes here. One of these is whether a field has a valid value. That is something that the business entity has to know so one wants the logic to determine IsValid there and only there. The other, however, is UI specific, e.g., indicating that a value is unusual or interesting. There, one has to decide whether the property is specific to the UI or is generally interesting. I.e., do we need to know it in any and all contexts or is the handling specific to a given UI context. An example of the latter might be wanting to color a negative credit balance red. There is nothing illegal about a negative credit balance. In fact, depending on the UI context one might want to color different values ... below 1000 because that is low relative to the probable order size, for example.
For the UI specific properties, I would suggest that we want a split. Those things that are specific to a given UI context, like coloring the credit balance in one or more colors, we would put directly in the specific UI. If the property is UI only, but interesting across most or all UIs, then it should go in the server-side UI interface. I can't, at the moment, think of any cases of this later requirement, but it seems possible that it might exist.