Brady Bunch Grid Discussion

Continued from HofPattern.

Note that CGB stands for Commodity (or Common) Gui Behavior.

This example uses a hypothetical HTML-like markup language to demonstrate a grid of multiple panels that refresh independently at their own refresh rate. The example name gets its nickname from the 70's Brady Bunch show's opening sequence showing active shots of the heads of each Brady family member. Each "box" is generally independent. This demonstrates what could be a more compact version of a "frameset" or "iframe" approach that would use the "refresh" header. (A "revised" version in the links has horizontal bar charts stacked on top of each other.)

This particular example shows five 200x200 pixel boxes across for each row. Interval unit is "seconds" unless specified otherwise (default unit). A "frame div" is sort of a hybrid between an HTML "div" and a "frame" or "iframe". Each frame-div "panel" runs a php script, although it could be Javascript, etc. The point is that each panel is an independent browser "window" like HTML frames and iframes. 

 <!-- Define repeating attributes to avoid repeating. -->
 <!-- In some ways it's like a style-sheet, but using markup. -->
 <attribset name=atr>
   <attrib name=autorefresh value=yes/>
   <attrib name=width  value=200/>
   <attrib name=height value=200/>
   <attrib name=float  value=left/>
   <attrib name=autoscroll value=yes/>
   <attrib name=border value=1>
 </attribset>


 <div>  <!-- row 1 -->
   <framediv attribs=atr interval=2.5 src="panel.php?x=1&y=1"/>
   <framediv attribs=atr interval=1.0 src="panel.php?x=2&y=1"/>
   <framediv attribs=atr interval=2.0 src="panel.php?x=3&y=1"/>
   <framediv attribs=atr interval=8.5 src="panel.php?x=4&y=1"/>
   <framediv attribs=atr interval=4.0 src="panel.php?x=5&y=1"/>
 </div>
 <div>  <!-- row 2 -->
   <framediv attribs=atr interval=9.5 src="panel.php?x=1&y=2"/>
   <framediv attribs=atr interval=1.0 src="panel.php?x=2&y=2"/>
   <framediv attribs=atr interval=2.0 src="panel.php?x=3&y=2"/>
   <framediv attribs=atr interval=8.5 src="panel.php?x=4&y=2"/>
   <framediv attribs=atr interval=6.0 src="panel.php?x=5&y=2"/>
 </div>
 <div>  <!-- row 3 -->
   <framediv attribs=atr interval=6.1 src="panel.php?x=1&y=3"/>
   <framediv attribs=atr interval=2.0 src="panel.php?x=2&y=3"/>
   <framediv attribs=atr interval=2.0 src="panel.php?x=3&y=3"/>
   <framediv attribs=atr interval=4.5 src="panel.php?x=4&y=3"/>
   <framediv attribs=atr interval=3.0 src="panel.php?x=5&y=3"/>
 </div>
 <!-- Etc... -->
(It could be made even shorter using the "template" approach shown in GuiMarkupProposal.)

A better UI approach would allow the user to re-size the grid row and column dimensions, similar to how one would in a spreadsheet. HTML "framesets" sort of allow this, but only one dimension propagates the resizing.

It's my opinion that markup-based GUI's are generally easier to learn and remember for typical custom business developers, as most developers will be using a variety of different languages, and some will be doing mostly server-side UI control and some client-side. Markup allows them to develop sufficient server-side-controlled interfaces without mastering the nitty gritty of a client language, such as JavaScript + DOM. (Server-side UI control is also less likely to "break" due to client upgrades or vendor differences. Internal apps especially tend to rely on the server-centric UI control.)

--top

[The first problem I see here is that if the number of divisions change, or the syntax for accessing panel.php changes, or really anything changes, you're going to need to change multiple lines of markup to cope with that (you'll need at least one more <framediv> line for any extra division added, and you'll need to change every line if panel.php changes). Under the original example, changing each of those things only requires one to change a single line of JavaScript. -DavidMcLean?]

Regenerate the HTML with a button or hyperlink if it needs to change. Web pages have been doing this for almost 2 decades. A trivial fix. And of course one can change the DOM or equivalent on the client side.

[Obviously you can change that stuff. That's what I was talking about: If you need to change the number of divisions, or the access to panel.php, or anything, you need to change the stuff in the DOM. It's still more stuff being changed than under the original approach. -DavidMcLean?]

That depends on how the GUI "structure" is specified.

[Given the structure you've shown above, there are more change points than under the original approach. If you have a different structure in mind to the one you've already shown us, show that one. -DavidMcLean?]

How are you calculating that? Pick a scenario.

[Under any scenario. There's more "code" in this markup approach, therefore any change or maintenance will potentially touch a larger volume of code. For example, if you need to add more divisions, you need to add a whole markup line like the above for each new division. With the JavaScript method, you change the numberOfDivisions variable, which is exactly one line no matter how many divisions you add---heck, it's one token no matter how many you add. -DavidMcLean?]

Either it's going to write to the DOM/equiv or write markup. Either way it's going to loop for each row. Yes the main "generator" function may accept a single integer for number of rows, but something is still going to loop for each row.

[Ah, so the unspoken assumption with your above example is that the developer won't write out the markup shown, but will instead use a loop to generate it? Fair enough; that does address that particular concern.]

[However, <framediv> as shown will only address exactly one use of AJAX, that of blindly updating a page section with a given interval; AJAX happens to do other stuff too. I know the original example doesn't have them, but what about, for example, notifications? Suppose there are some cases where you'd want a "popup" notification shown at the top of the page, perhaps making sure the user can't miss a particularly important bit of monitoring information. How does your design address these? -DavidMcLean? ]

Using the MDI GUI model. Div's and Framediv's would be part of the same "window", and a different new (or "activated") window would pop up on top. That's how GUI's used to work, but the browsers bastardized that model for unknown reasons. A variation on "target=_blank" tends to be used with browsers, although the JS/Dom "window.open()" tends to give one more control.

[So, to confirm, you're suggesting opening a small popup window to display notifications? I see two issues with this. Firstly, how do you propose to trigger and open this notification popup? I don't see how your proposed methods for communicating with the server will enable this, although it's possible with AJAX. Second, is it really a good idea to open a full new browser window, with all the browser chrome (sometimes you can stop that, but at least with a title bar), for a transient notification? -DavidMcLean?]

No, we don't need a "full" browser window, but the existing HtmlStack gives us stupid alternatives. That's not my fault. And how are we defining "browser window"? When is a rectangle panel "on top" a window and not a window? The kind of features/behavior we want on a "window" can run the gamut. I'm not quite sure what kind of notifications you are envisioning. Please be more specific. There are a lot of ways to notify and I cannot read your mind.

[Popup notifications of the sort lots of major sites use, including Facebook. Here's one implementation, for jQuery, which has some examples you can play with to get the idea: http://needim.github.com/noty/ How do you propose handling these? -DavidMcLean?]

Well, that's one "type" of window. What's your point? By the way, those draw in clunky fashion, like Commodore 64 graphics. That's because people try to use JavaScript as SystemsSoftware, which is not its forte.

[With your AJAX-free model of the Web, how does the Web server deliver notification messages to the client, such that they may be displayed like in that example? Also, if you don't like how those look, there are plenty of other libs around: http://boedesign.com/demos/gritter/ and http://codeseven.github.com/toastr/ for example, both of which mostly resemble Growl for Mac OS X. -DavidMcLean?]

When a given "cell" panel with a "condition" refreshes, it can contain the code to draw the pop-up window, somewhat similar to how one may put a JS "alert()" box in a web page. Ideally the characteristics of the pop-up window would be controlled by the markup specification: resizable, closable, transparency, etc.

[Under the standard model of what frames mean, the contents of a frame can't really affect what's going on in other frames; you're free to change what frames mean, though, so that's not a good counterpoint. Aside from that, under this method the notifications must be delivered with and are therefore tied to a specific existing panel. What if there's a notification not related to an individual panel, something about the state of the system as a whole? How would that be handled? -DavidMcLean?]

I'm not sure what you mean by "tied to" here.

[First, I'll clarify that I do indeed understand what you're suggesting. Are you saying that notifications would be handled by modifying the HTML generated and sent by panel.php to a specific panel, such that it includes something like a <script> tag with code for spawning the notification? -DavidMcLean?] 

  <listener protocol=websocket>
     <window...>DANGER, WILL ROBINSON! DANGER!...</window>
  </listener>
  ..or..
  <listener protocol=websocket name=foo>  <!-- listens for "foo" only -->
     <window...>...</window>
  </listener>
  ..or..
  <listener protocol=websocket name=foo passthru=no>
     <!-- passthru=no means it doesn't allow other listener
          events to act on it. This "absorbs" it. -->
     <window...>...</window>
  </listener>



var es = new EventSource?("/sse"); // connect to SSE source
es.addEventListener("foo", function(data) { // listens for "foo" events only
doSomethingWith(data);
});



    <listener...>
      <window...>WARNING: <paramGet name="my_message"/></window>
    </listener>



        es.addEventListener("foo", data, doSomethingWith(data));  // example "foul-up-38"



<listener name="message"
<window>URGENT: <paramGet name="my_message" /></window>
/>



        myCustomblock (p1, p2, etc.) {....}



es.addEventListener("foo") {
doSomethingWith(data);
}



es.addEventListener "foo", (data) ->
doSomethingWith data



es.addEventListener("foo") {|data|
doSomethingWith(data)
}

"No loops, no recursion, and no explicit branching. Thus, there are less possibilities one has to consider when reading the code."

Unless you're talking about something like Prolog, what you describe -- no loops, no recursion, and no explicit branching -- is epically useless. Innumerable attempts to take the programming out of programming or create programming for non-programmers either results in (a) a new programming language that soon gets used only by programmers for programming -- a good example is COBOL, originally intended for non-programmers to write programs; or (b) crap.

I believe the WWW has been highly successful from a usage/popularity perspective largely because the declarative nature of HTML made "getting started and useable" relatively easy. But like any highly popular product, it starts to be used beyond its original design intent, and becomes a tweak-filled mess. We need a GUI-friendly markup to replace it. Most GUI activity is known and "package-able" into a mostly declarative attribute-driven fashion, such as markup so that GUI's are not esoteric or a pain-in-the-tush to create and change for custom and budget-conscience shops with fungible staff. The evolution of DSL over time goes toward declarative and attribute-driven, be it markup and/or RuleBuilderInterface screens.

For getting started on Web development, we have HTML. For interface programming, we have Javascript. What role is your markup intended to serve? For non-programmers, your markup appears to add complexity to what we already have. ColdFusion tried that, and you can see how popular it is now compared to the alternatives, despite being TuringComplete. You appear to want something that isn't even TuringComplete, resulting in a markup that's more difficult to learn than HTML for non-programmers, and less powerful than Javascript for programmers. In short, it appears to be the worst of both worlds. Simple declarative DSLs for rule definitions, configuration files and the like are an order of magnitude simpler than the general-purpose display functionality, and can get away with being non-TuringComplete. TuringComplete interface scripting (e.g., Javascript) is necessary for even trivial dynamic Web applications.

COBOL is not a good example because it was created around 1959 when the idea of DSL's was very new. We now have real-world test cases such as databases and HTML and email RuleBuilderInterface(s), etc. And COBOL has stood the test of time even though it uses dated language conventions. One can hardly call it a "failure".

COBOL was (and is) a success as a programming language for professional programmers. It was a failure as a language intended for non-programmers to do professional programming.

True. I don't dispute that. But it doesn't change the nature of my case for mostly markup.

There is no "case for mostly markup". As above: Your markup is more difficult to learn than HTML for non-programmers, and less powerful than Javascript for programmers. In short, it appears to be the worst of both worlds. Another ColdFusion the world does not need.

Strawman arguments. Non-programmers are not the target audience. And CF is not "it" for reasons already given. CF added IF's, loops, etc. to HTML, but did very little to address lack of CGB. That's not what I have in mind. CF added TuringComplete, not CGB, which is "fixing" the wrong thing.

[If non-programmers aren't the target audience, why would you expect actual programmers to use this markup language, when they'll almost always prefer to use the more expressive and powerful JavaScript? -DavidMcLean?]

How do you conclude that? For one, it's not just programmers who decide what's used. The organization also has a say. And again, the flexibility camp lost in the GreatLispWar. Semi-domain-specific languages seem to be what the industry wants. We've been over this already. Also, for smaller or decentralized shops, the IT person may do multiple tasks and programming may not be their strongest skill such that advanced techniques may confuse them.

How do you conclude that "what the industry wants" is a less-powerful, less expressive, more XML alternative to Javascript?

Observation. HTML was "catchy", especially in terms of "part time programmers". My brother, a non-programming graphics designer even picked up HTML. JS/DOM just turns most people grey except those who dive in and make it their specialty. You have a right to disagree, and I know you will.

[You said above that your language isn't targeted at non-programmers. Now you're saying it's desirable because it'll appeal to non-programmers. This is flawed in that your language is significantly more complex than HTML and therefore isn't going to appeal nearly as much to non-programmers; it's also flawed in that, if your language isn't targeted at non-programmers, it offers no advantage to actual programmers over JavaScript. JS is already tremendously popular for programmers, being a powerful, expressive, generally competent programming language. -DavidMcLean?]

JS is "popular" because there are no realistic alternatives for the client side of the browser. It's forced up our ass via the cruel twists of history. It's popular like QWERTY is "popular". And yes, it is more complex than HTML. However, it would be more appealing than the JS/DOM. Your comparisons are off. The important comparison is GUI-centric markup versus the HtmlStack with JS, and not HTML versus GUI markup. Most programmers I know don't have any special love for JS other than it pays the bills (and turns them grey). Granted, if the DOM/browser model was better, JS wouldn't suck as much for UI usage. But, if we had a decent GUI markup, we wouldn't need scripting very often because CGB could be handled largely via the markup (and/or server-side). Why hand-program shit that should be in attributes? It makes assembly look pleasant in comparison. If you disagree, so be it. I call it as I see it.

[I'm only comparing it with HTML because you are, equating your language with HTML in terms of its "catchy" nature. Because your language is, as you've said, more complex than HTML, it's not good for non-programmers. Why would your markup language be more appealing than JavaScript, for actual programmers, considering that it's significantly less powerful? (If you think JS is only popular because it's the only real option for client-side code, how would you explain server-side JavaScript solutions, like NodeJs?) -DavidMcLean?]

Nobody I know uses NodeJs, and it's mostly used for static pages, not dynamic ones. And "non-programmer" is not the main issue. Markup (done reasonably well) is generally easier to learn, use, and remember, at least for the short to medium term. And "more flexible" is not the primary goal for reasons I've given many times. You are a confederate state in the GreatLispWar. Give it up.

[The GreatLispWar doesn't exist. NodeJs is almost solely used for dynamic pages, and it doesn't matter whether anyone you know uses it. The very fact that not only it but several server-side JavaScript platforms exist is indicative of JavaScript being popular for reasons other than client lock-in. -DavidMcLean?]

[As for markup… why would it be easier to learn, use, and remember a reasonably complete set of XML elements for specifying GUI behaviour than a set of functions of the same size? -DavidMcLean?]

I don't know exactly why, it just is. I'll have to ponder the WetWare reasons to explain better. Part if is named parameters, which JS lacks. Part of it is simpler syntax. JS provides too many different ways to specify/emulate attributes, for example. It has square brackets, curly brackets, parenthesis, and so forth and one has to remember where to use which. (It can learn a lesson or two from EssExpressions perhaps). Markup enforces more consistency for that. Developers/designers could have used only JS to talk to the DOM or a wrapper around DOM to make pages all these years. However, they have been using mostly HTML as one can see by doing a View Source. What's your explanation of that?

[The explanation is that, as the name implies, HTML is a markup language. Its purpose is to mark up documents with semantics, and it's not too terrible at doing that, so it hasn't needed to be phased out or anything. JavaScript's a programming language. It's not designed to mark up documents, because it's a programming language. Use the right tool for the job, right? HTML is the right tool for marking up a Web document, and JavaScript is the right tool for interface scripting.]

[Your proposal is that HTML should be extended such that it handles loads of stuff JavaScript already does, but HTML is designed to mark up documents, and things like "receiving events from the server and flashing up a notification bubble accordingly" are not document-markup issues (so you'd be mixing unrelated concerns, I'm afraid). Nonetheless, you do seem to have a point in claiming that devs have mostly been using HTML to make pages rather than manipulating the DOM with JS.]

[However, people actually haven't necessarily been using mostly HTML to build Web pages, regardless of what you see in View Source. Consider the fact that http://daringfireball.net/projects/markdown/ http://docutils.sourceforge.net/rst.html http://haml.info/ and http://jade-lang.com/ exist, among many other markup and templating languages (some more popular than others). All of these generate output as standard HTML; none of them require the developer to use actual HTML directly. -DavidMcLean?] 

   <!-- change alignment of div "div123" based on URL or POST parameter -->
   <task name="ziig">
      <setAttrib namespace="foo" targname="div123" attrib="align" trim="yes">
           <paramGet name="new_align">
      </setAttrib>
   </task>
[Why would the method of binding variables within this markup language be "usage specific"? Don't we want consistency? How do URL parameters relate to this subject, incidentally? I first brought up the question of variable-referencing in terms of data sent from server to client, and URL parameters only actually apply for a request from client to server (because the server doesn't make GET requests (or any requests) to the client). -DavidMcLean?] 

<td><a href="{{project.site}}" target="_blank">{{project.name}}</a></td>
[Also, your markup language is intended to be declarative, right? How can it be when it has imperative change-state constructs like <setAttrib>? In AngularJS, a {{ }} binding will update automatically, without needing any imperative construct, whenever the thing it's bound to changes; this seems much more declarative a design, at least to me. -DavidMcLean?] 

 <input type="button" value="Do 3 things" onclick="event01">
 ...
 <task name="event01">
   <window name="w07" visible="true">  <!-- activate existing window -->
   <input name="mybox" value="New value is 83672">  <!-- change box value -->
   <sendContent document="my_doc_2" form="my_form_A">
 </task>


 <!-- Alternative for middle one -->
 <!-- Here is appending to "mybox" instead of replacing -->
 <setAttrib targname="mybox" attrib="value" trim="true">
   <getAttrib targname="mybox" attrib="value"/> Appended text 83762 here
 </setAttrib>



<listener name="new_message">
<li><paramGet name="messagecontent" /></li>
</listener>
<section name="content">
<li>message content</li>
</section>



    <a href="www.foo.com" target="_blank">Click me</a>



[1, 2, 3].forEach(function (x) {
[4, 5, 6].forEach(function (y) {
print(x+y);
});
});
. 

<!-- the existing document structure -->
<ol name="posts">
<li>a post's content here</li>
<li>and this is another post</li>
</ol>


<!-- the newly added delta is below -->
<ol name="posts">
<li>this is a post that was just made right now</li>
</ol>



     <li insertPosition="_top">My content</li>

<ol name="posts" sorttype="usa_datetime" sortdirection="descend">
<li sortvalue="12/12/2012 10:30am">a post's content here</li>
<li sortvalue="1/3/2013 5pm">and this is another post</li>
</ol>

Java Side Discussion

If you believe it so, I suggest you create [a gui markup language/demo]. Perhaps it's an opportunity.

I'd probably have to use C/C++, which I really don't find pleasant. Some day I may try a mock-up in Tk/Tcl to at least demonstrate what "could be". I tried something kind of like that with Java Swing once, but ended up pulling my hair out. It didn't like the idea of a dynamic data structure holding references to a wide variety of widgets "types".

The "idea of a dynamic data structure holding references to a wide variety of widget 'types'" is not only the very essence of JavaSwing, it's the very essence of practically every UI toolkit. Arguably, it's the technical essence of user interfaces in general. How would you avoid it?

[Top's not saying that a dynamic data structure holding references to a wide variety of widget types is a bad thing. Nor does he wish to avoid it. He's saying such a structure is good, he wanted to code that, and JavaSwing didn't support it well. I'm not really that familiar with Swing, but from my (also admittedly rudimentary) knowledge of Java in general I do see how it's kind of complicated to build a data structure holding multiple widget types, at least without just casting them all to Object or something like that. -DavidMcLean?]

I think he's saying he didn't like it. Specifically, "I didn't like the idea of a dynamic data structure holding references to a wide variety of widgets". JavaSwing supports it trivially. All Swing widgets (and user-defined derivations) are inherited from JComponent, which is trivially contained. Java supports generics, too.

[But he didn't say that, silly. He says "it didn't like the idea", presumably referring either to JavaSwing or Java itself. I think the meaning is that, using Swing merely as a base, Top tried to build a totally different GUI engine, including building his own data structure containing references to his own widget types.]

D'oh! *thump* Sure enough. (I really should up the font size from my default "I can display the entire Internet in 1920x1600".) You're right, but as a result his comment makes little sense. JavaSwing is built on precisely the idea of a "dynamic data structure holding references to a wide variety of widgets". In essence, that's what it is. I have written much using JavaSwing; whilst Swing has numerous flaws, being awkward to build "a dynamic data structure holding references to a wide variety of widgets" is not one of them. Even if Top tried to define his own GUI engine via pixel-pushing and bitmaps, at least from a containment point of view, it's trivial in Java or (probably pointlessly, but whatever) in Swing.

I created a structure that held type "object", but was having trouble getting it to "hold" or point to dynamically-created widgets for some reason. Perhaps I was missing some key knowledge, but most documentation and materials I found only had examples of statically-created widgets. I figured I was in poorly explored waters because people were all doing it the static way and that's what the Swing designers apparently intended. I don't have a lot of Java experience, so didn't want to try to be Christopher Columbus with it. I don't remember the details, it was a while ago.

Re: Make-It-Now

Top, why don't you create this CGB XML markup language, and demonstrate to us its marketability and/or capability? I doubt anyone is going to build it for you.

That's a huge programming task. Maybe when I retire. Why don't you do it, then you can put in recursion, and tell me to shove it recursively.

No. I have better things to do. A language that caters to bad programmers who are good at XML? Bad idea -- one ColdFusionLanguage was already too many.

ColdFusion does not really cover CGB, as already explained. And you still haven't explained the specifics of CF's alleged evils.

Then what does "really cover CGB"? Ideally, you need to provide more than a definition of CGB -- you need to provide a specification. One of CF's most profound evils is the abominable notion that it's reasonable to use XML tags to express imperative code.

I agree it would be helpful to have a full spec for CGB, but we don't need such for specific scenarios because we consider each scenario as it's encountered (such as asking how often we need recursion). 

      <foo dragin="yes" dragout="yes" dragsources="myclass,flig,nib"/>
As far as CF, the XML is almost whatever you want it to be. The average programmer is not going to be a very good XML language interface designer (or not care enough to think designs through). It's a lot like writing an essay: writing an essay is relatively easy. But, writing a good essay takes time (concise, clear, on-topic, etc.) If somebody/something came up with a good XML wrapper standard over CGB, then each Joe Sixpack programmer will not have to reinvent GUI XML. Let master API/XML interface designers or a good vetting process do that, not programmers who only know or care about solving specific problems for specific customers.

Sorry, I don't follow you.

CF is an XML domain language builder. If you build a bad XML domain language with it, it's not CF's fault. If you build a Lego horse and the horse has an ass that's too big, is that the fault of Lego or the horse builder? Also keep in mind that the resulting XML is often targeted at graphics designers who know HTML, not necessarily programmers.

How is CF different from PHP, ASP or JSP?

It has built-in idioms to make it easier to create markup "commands" to supplement HTML. Remember, this issue started when you stated, "One of CF's most profound evils is the abominable notion that it's reasonable to use XML tags to express imperative code." Keep in mind this is mostly a different issue than CF's built in imperative statements. One does not have to use them to devise a domain-specific or shop-specific XML DSL.

You mean CF lets the developer add custom markup tags?

Yes. It's generally used to make it simpler for web graphics designers to add prepackaged features to pages.

So how is that superior to the various HTML template systems available for PHP, ASP and JSP?

1) It's built-in so that you don't have library dependencies.

2) The designer can gradually learn the CF (built-in) imperative markup tags such as IF's and LOOP's.

Yes, you can perhaps make those others resemble some of CF with enough libraries and plug-ins, but why not get the real deal? (CF also has a JS-like/JS-lite scripting language if you don't want to use markup for IF's, loops, functions, etc.) CF doesn't have a lot of high-brow features, but it has a lot features that to assist low and mid-brow programmers, and help graphic designers write "power HTML". It also allows nested templates that can also optionally do imperative (in addition to custom tags) which is not easy to emulate. You'd have to reinvent an interpreter in Php etc. to get it comparable.

[It's common consensus that having business logic in your templates is a Bad Thing™, and indeed several "logic-less" template languages have been devised to try to ensure separation of concerns in this case. Adding imperative markup tags seems to be a step backwards, with this in mind. How will you ensure separation of business logic from presentation? -DavidMcLean?]

The SeparationOfConcerns thing is largely a fad meme. The boundary between "business logic", "presentation", etc. is fuzzy. They are intertwined, designed together and dependent on each other in terms of conventions and interaction between user and features. Plus, it often results in unnecessary maintenance jumps to separate things that have a one-to-one relationship. It's poor normalization, a MirrorModel. I do things for a describable reason, largely based on CodeChangeImpactAnalysis, and not because fad memes say so. --top

SeparationOfConcerns is not a "fad meme." In general, it's simply the term given to a self-evident good practice: the avoidance of turning programs into a BigBallOfMud by separating distinct functionality in order to manage complexity. It's only a MirrorModel or poor normalisation if done improperly. It applies equally to the Web stack, though there are some HTML tags that allude to presentation (<font>, <b>, <i>, etc.) which may suggest fuzziness but where, in fact, they're merely the result of legacy support for pre-CSS HTML. Presentation and business logic are fundamentally and inherently separate, by definition. Presentation is about how data is shown; business logic is about how new data are computed from existing data. Business logic defines how data changes, independent of whether or not the data is ever displayed. Presentation defines how data is displayed, independent of whether or not the data ever changes.

If your app or org has a general shared style, then relationship factoring alone will "agree with you" and one factors the standard style info to a style-sheet or what-not. We don't really have a dispute there. However, if it's a one-off page or screen and the maintainer of the "business logic" side will likely also be the maintainer of the style-related info, then it's generally more economical and efficient to keep it together. I'm confident a study of change probability and hand and eye movement would bear this out. If and when style info becomes shared, or the style maintainer will be diff from the app builder, then factor it out. The back-and-forth mirror-hop for 1-to-1 wastes time and screen real-estate. Plus, it bloats up the style libraries to fill them with one-off's, slowing down the finding of items being sought. Long lists are a PITA. A good portion, perhaps most, developers don't have FastEyes. The people who pay me want efficiency, not vague slogany platitudes. I balance tradeoffs for my designs, not process slogans. Slogans can be good reminders to consider factors, but not a substitute for thinking.

Another example is back-room utilities for in-house apps, such as a user account/role-manager library or screen-set. Most of the time nobody gives a shit about changing their style for internal stuff: make it a generic silver gray. If we make them depend on a shared style-sheet(s), then often one forgets when copying them over to a new app or make them fit the style folder convention of the new app. It's often more convenient if they are self-contained so that one can move and mix and match as needed without annoying oops-I-forgot ties to a css folder or related conventions. Those remind me of desktop computers with pasta-galore cords hanging off them. You think you unplugged everything to move a PC, and one straggler cord you miss knocks over the coffee and trips the boss onto her face. -t

I agree that MentalIndexability can play a role in how things are divided up, but in this case it's usually not a difference maker because one generally goes to the HTML HEAD section to find the location of the style-sheet(s). If they are in-lined (or at least the one-off parts are), you see them there anyhow.

And how did the CF sub-topic drift to style-sheets? A web/graphics/layout designer may deal with much more than style-sheets.

[Actually, you took us to style-sheets, Top. It's perhaps because of the irritating conflation of meanings for "presentation". In the context of "separating it from business logic", "presentation" refers to code that wraps up values in HTML tags: HTML templates or views, specifically. Feel free to rant about how that's dumb and confusing; I'm inclined to agree. However, the fact remains that business logic does not belong in template/view code, nor do presentational styles belong in either of those places. SeparationOfConcerns remains important. -DavidMcLean?]

I still don't see how "roll your own tags" is mostly about style-sheets. The project involvement level or number of hats other members of an organization vary widely. The segue is still fuzzy. As far as SeparationOfConcerns between semantics and presentation, OverhaulingStyleSheets already covers that battle.

[It's not mostly about style-sheets; you've merely interpreted "presentation" as meaning "style-sheets" when in this context it actually means "templates/views". Feel free to reevaluate given the understanding that our source of contention is the mixing of the concerns of business logic and template/view code and that at the moment style-sheets aren't important. -DavidMcLean?]

UI design is inherently tied to business logic. If a drop-list is limited to 7 items, let's say "order status", that likely reflects business logic. And a non-programming UI designer or domain analyst may be able to specify such in a specification and/or markup.

[A drop-list's being limited to seven items may reflect business logic, but that does not mean it is business logic; such a fact actually definitely is not business logic, simply because it's not logic. Templates/views should contain a bare minimum of code needed to render the view appropriately, preferably with as little logic of any sort (business or otherwise) possible. If we're thinking ModelViewController, we want most business logic to be in the models and only in the models. (Depending on the business, some logic may need to be handled in controllers, but none of it should end up in the views.) -DavidMcLean?]

Such a thing can be re-projected into formal logic if we wanted to, so your "is not" claim is false. As far as your "should" rule, you need to justify it better. The reader should not have to take your word for it. And MVC is vague.

Business logic defines changes to data; it has nothing to do with how the data is shown. A "drop list" is a display device, so by definition it is part of presentation, not business logic. Beware of conflating business rules -- which might well dictate that a maximum of seven items be shown -- with business logic. Business rules may govern both business logic and presentation.

MVC is not vague; it describes a clear delineation between representation of data (model), presentation of data (view), and mechanisms to manipulate the view and the model (controller).

So you say. Anyhow, I don't want to debate MVC defs today.

So pretty much everyone says.

You haven't done any fricken survey.

Read almost anything on the topic.

I can't find any usage surveys. Separation/MVC kind of has been a fad for the last decade or so. Those who propose it under most circumstances write about it and those who are more practical ignore it as another form of GoldPlating it often is. See also MvcIsNotImplementable and WhatsaControllerAnyway.

Those pages debate specific interpretations of aspects of MVC, not the overall concept. Those who are practical simply use it. Note that your TableOrientedProgramming embodies the "philosophy" of MVC: Tables are the model, views are query results, and the controller is the query language.

It can be interpreted such that just about anything fits.

No, though it is quite common. A given binary search algorithm, for example, isn't MVC -- or at least not necessarily. However, there are environments and frameworks where MVC is used pervasively, to good effect.

It's just a RDBMS-atized version of input->process->output.

It's perhaps as fundamental and significant as input->process->output, but it models ongoing interaction whereas input->process->output is effectively "batch" or non-interactive. It's controller->(model->view).

What about this for notifications: Put a single-line red banner at the top of the cell if there is an alert. Clicking on it will show more of the message, if it's longer (as indicated by ellipses or something). Reserve a thin strip at the very top for system-wide alerts.

[That's a fairly nice interface design, but it doesn't address any of my questions.]

I should point out that server-side programming is generally easier to manage and develop for, even if it is a bit slower for certain behavior. (You may not have to download JS libraries, which speeds up some situations.) Thus, I recommend that one use client-side programming for the frequently-used behavior, but server-side for the rest. -t

See also: BradyBunchHeadExample

CategoryFunctionalProgramming, CategoryWebDesign

FebruaryThirteen

EditText of this page (last edited July 1, 2013) or FindPage with title or text search