Sorry for the delayed response. I've cut my CDP time so more
considered responses to threads like this only get done as time
permits.

"Chandru Murthi" wrote:

A document that tells developers how to upload files was written by
Symeon Breen and it's available to all DesignBais developers. I agree
that you may want other functions that are usually implemented with
scripts, or even by embedding Java, ActiveX, etc.. But taking a
position that's been held by many people here, I'd maintain that more
complex functions shouldn't be written by individuals but provided as
part of the product. To balance between both arguments, I've written
a couple blog articles about adding custom code into the DesignBais
UI, and I offer services for those who aren't familiar with non-MV
technologies

BTW, my latest blog entry is the first in a series on hacking
DesignBais. Check it out:
http:// removethisofcourseNebula-RnD.com/blog

For what I call "business-professional" web applications there is
almost never a business 'need' to use scripts given the features
available in this software. 'Want' and 'need' are different. People
have been writing DesignBais apps for a few years now, apps that are
now in production with absolutely no additional scripting. While some
of us talk about a 'need' for scripting or other technology, others
have adopted DesignBais and are now out there selling apps to happy
end-users without ever needing to write a script. It's tough to argue
in favor of a need for something when it's been proven by people who
actually use the software that there is no such need.


I mumbled:
That's not exactly what I was talking about (ack to your 'yes and no')
but you've described exactly what Ajax does for us. DesignBais has
been using this technique of page generation since way before it
became fashionable, and here in CDP we've discussed doing this with
hidden frames and other techniques.

The question is whether such minimal (perhaps script-only) pages are
actually cached by the server or the client. They might be, I dunno.
These days the benefits of server-side page caching are almost
negligible just because we are tending toward such heavily dynamic
content. The many payloads delivered to a "static"/cached page are
completely dynamic and can't be cached. Whether or not the initial
page was cached seems to be a trivial point.

For the record, there is only one primary script-only user page that
gets rendered in DesignBais. Maybe that page _is_ cached somewhere,
again I dunno. That one page processes all payloads to render the UI
and data. Let's assume all of the pages that render data are loaded
at once. That's just a couple hundred kb, smaller than most images
these days - whether or not these are cached seems irrelevant.

When discussing products like DesignBais and Visage, people are more
inclined to focus on whether form definitions are cached in the DBMS
at development time, or whether they are regenerated as required at
run-time. These definitions are XML or other formatted data that are
presented as instructions for client-side script to interpret into the
desired UI controls and related data. I believe Visage does cache
page definitions in the DBMS or elsewhere, while DesignBais reads the
definitions from the DBMS and generates the XML at run-time. This is
a blade that is being honed way beyond "sharp enough". If Visage
generates metadata that gets cached then it loses the ability to
behave dynamically. Because definitions are read at run-time,
DesignBais pages are completely dynamic, and without any perceptible
performance hit in exchange.

When pages render at speeds expected of the medium, then it doesn't
matter if you can shave off a few milliseconds. With regard to page
rendering it's probably fair to say DesignBais and Visage are
completely equal. I don't do benchmarks and it's silly to go on about
such things - let's assume they're both 'fast enough'. I have
absolutely never heard of a sale lost by anyone in this market because
their web pages don't render like a thick client, but we constant hear
about sales lost because an app has no GUI. The problem we have in
this market is that people sit on the fence, missing sales
opportunities, reading arguments about caching and other things that
usually never even come up during development. People would do best
to go through product presentations, get some hands-on experience with
all of these products, and come to their own conclusions about which
option(s) will best suit their business goals.


TG@ removethispartNebula-RnD.com
(Taking requests for online demos and trial evaluations.)

Tony Gravagno wrote:
Visage does keep copies of the base XML, and generated HTML within the
database, but the base page HTML is published as static HTML pages.
These pages are (typically) cached on the client (can be disabled by
browser setting), and possibly intermediate proxy servers.

My understanding (a few years since we abandoned our ASPirations now
[about 18 months before Microsoft rethought the whole ASP "thing"] but
probably still accurate) is that ASP pages can not be cached, as they
are always generated on the fly, therefore will always have a newer
date/time stamp than the version that is cached by proxies and/or
browser

Now that is a mischevious statement, as I'm sure you ARE familiar with
DHTML. - there are books I could recommend :-)

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

provided as part of the product" but the expanding needs (not wants) of even
relatively unsophistacated web applications means that it's not possible to
incorporate it all. I wouldn't want to, either, given the infinite
possibilities of activeX or other screwy add-ons.

As you've said on many many occasions, use the right tool for the job and
use off-the-shelf components. So you should be on the side of the angels
(developers) on this one when they want to use software from GodKnowsWho.com
which solves their problem perfectly (according to them) and letting them
use javascript to achieve that end is available.

I do not see the reasoning behind this if I am reading this correctly. A
script-only page? That would imply that the entire html generation is via
script? The dreaded javascript? All I can say is that, apropos of your
comments about rendering speed, once again we have quite different
experiences. Just using one of our main design screens which is about 350k,
rendering that via script has got to take considerably longer than
pre-generated html. I note that just "paging" the data in a mv-table with
(say) 15 fields and 15 rows takes over a second using quite optimized code.
Perhaps you are using php/perl and perhaps they are much faster.

Regarding caching, again, different experiences. Server side caching reduces
the html generation (which is server cpu time) by about 1-3 seconds, which
you may say is not significant given browser latency, but it has been
perceived as such. Client caching reduces network traffic significantly.
Again, your comments seem to imply a considerable "payload" in DesignBais
(more than the initial load.) If so, then your point is valid. In my
experience, the "payload" on server calls other than the initial one is
minimal, so caching the initial html makes a noticeable difference. Loading
the data from an initial read is the main payload, and that's data, not
DHTML.

Chandru

Disagree, but I think this is a syntactical problem. Depends on what
"caching the metadata" means exactly, since you can change the cached html
in many ways after load, and if the change is, say, 10% of the original
html, then you're ahead.

Chandru Murthi

"Chandru Murthi" wrote:
For the record, I'm on that side of the argument for some things, not
all. It depends on the topic. When the task is so tiny that anyone
can do it on their own, or I don't think the vendor can create a
one-size for all solution, then I prefer a DIY approach, though many
here disagree with that. I tend to advocate DIY more (based on the
things people here ask for) while our colleagues prefer more to come
from the vendors.


If any of our colleagues ask me what technology to use for a GUI, they
will find me listening to their needs more than pitching technology.
You're right, right tool for the job, and only after we find out what
the job is. A critical factor in defining the job is the skillset of
the developers. The traditional "one man shop" Pick application
developer knows his business but doesn't know most of these other
tools. He has chosen Pick because he can maintain the complete
environment on his own without a college education, a team of DBA's,
or having the mainstream market pull the technology out from under him
every couple years. It's very difficult for me to recommend
JavaScript, VB, anything with a ".NET" in it, or anything else outside
of this Pick developer's scope because when I go out of town he won't
be able to maintain his own code. When this Pick developer hires a
contractor or employee, he's going to need someone with Pick skills.
It complicates the matter to ensure he has someone with Pick _plus_
whatever it is that he is using for web technology. He might find
someone with JavaScript skills but if he finds his future growth
points toward VB/ActiveX, oops, great new employee still needs
training. With DesignBais, all you need are the Pick skills you
already have, and you don't have to worry about geeks like me
installing technology that you can't maintain later. I will certainly
recommend the right tools for the job, and for years everyone here
knows that I am happy to discuss lots of different tools. But for the
shop that doesn't need tools, they just want a GUI for their Pick
application, I'm even more happy that I can offer DesignBais. It's
the right tool for _this_ job.

DesignBais creates a really nice GUI and it simply doesn't need
JavaScript. You assume that you will want to do something "more" but
the tool is quite capable of satisfying the needs of all who use it.
As the product develops over time, perhaps it will get extensions for
plug-in scripting, but for now, people who use the software aren't
asking for that, and extensions are being built-in without people
having to learn scripting.

Chandru, I am not pushing DesignBais, merely explaining how it works.
As you know, Nebula R&D is also a worldwide Distributor for mv.NET,
and I support other technologies as well. There have been times when,
after listening to the current and future requirements of a prospect,
that I decide to not even put DesignBais on the table because it
simply doesn't belong there. I've tried to pitch other technologies
only to have people insist on DesignBais, and I've pitched DesignBais
but realized it's not in line with site-specific needs, so I've
reversed my approach. "Right tools for the job" always applies.


Make up your mind. The only way you're going to cache a page is if
it's static. If you want a dynamic page you need to avoid cache or
you need to use client-side scripting to generate the page based on
provided parameters. Yes DesignBais uses script to accomplish it's
goals but it does not require the user to use script nor does it
expose an API for custom scripts.


I'm sorry your experience is different. I'm just describing at a high
level how DesignBais works and the expected performance. This isn't
an argument that one should have with me, there are lots of developers
and end-users out there who are using the software. Ask them if
they're happy. If they are then it makes no sense to quibble over
page size and refresh rates.


As I always say, tools are irrelevant. It is what it is.


The payload depends on the data required. As with any Ajax-based
application, there is a tiny payload associated with a simple data
entry validation, even a request for a new record to populate a page.
Heavier payloads are required when the user elects at run-time to do
something that requires a dynamic refresh of major parts of the page.
There are no absolutes. It's for this reason that DesignBais does not
pre-cache page structures or other metadata - you don't know what the
user will want to do at run-time so you don't pre-generate or
pre-transport such material.

Four blindfolded men examining an elephant will have different notions
of what the whole is given their analysis of the parts. And each one
might find it difficult to explain their perceptions to the other, or,
considering there are other parts that haven't been seen yet to
discuss in isolation why any one part of the beast may or may not be
fitting of a living being. If the goal is really to understand the
elephant rather than to play games with blindfolds, it's much better
to simply remove the impediment and have a look at the elephant.

Good exchange, thanks.
T

TG@ removethispartNebula-RnD.com
(Taking requests for online demos and trial evaluations.)

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

Yes to all. The initial page is static. Yes, it will be cached, leading to
network traffic/speed improvement. And it can and will be dynamically
modified client-side. You said a "script only page" and I tried to find some
explanation for this weird beast, since I assumed it meant "no html" (aside
from the required tags).

There was an implied question there? Just wondered if DB uses php/perl as I
understand their execution speeds are higher than javascript.

It was not clear to me that DB pages can be drastically modified. It is true
that with the web RAD I use, the format of the pages cannot be substantially
altered (for example, adding a new mv-table). Fields and columns can be made
visible or invisible, with somewhat unpredictable (at the design level, I
don't mean it changes with time) rendering.

Decisions such as when to "bind" a structure from metadata (which is a
general term where you pre-process relevant data and store it in a form more
suitable to execution (speed) than human or storage interface) are always
difficult and always lead to a Pandora's box of future problems.

It's no different than the syntax-checker and "compiler" in javascript. It
must do awful lot of binding and allocation (addresses, structures, data)
but it cannot do it all because you can, of course change the method /
property of any object dynamically (i.e. if you say
document.MYBUTTON.onclick=function{whatever}; the onclick action of MYBUTTON
has changed, so it cannot have been permanently bound at load time.)

So in what could be totally dynamic environments like a web browser, the
developer has to triage the many options. Since thankfully we are dealing
mostly with business forms, the decisions are easier because the
expectations are lower.
[aside: For a ludicrous but beautiful version of how you far you can push
DHTML, check out http://www.csszengarden.com/. The CSS required to make this
work is so way out that it's incomprehensible.]
But for my purposes, I decided to allow certain dynamic UI features:
visibility, colors, fonts, size, etc. But to not allow the total redesign of
the page on the fly. If DB/Visage do it, more power to them.

Chandru

Tony:

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote ...
I would add the "part of the product" idea should be applied to small items
too; as long as they meet the normal "it works on a one-size-fits-all
solution" criteria. A simple example is in MV, at the command line, one can
normally execute a: VERB FILENAME SELECTION-CRITERIA OUTPUT-CRITERIA where
itemIds can be referenced using single-quotes and value representations are
referenced using double-quotes. e.g.

:SELECT VOC 'LOGIN'

or

: DELETE VOC 'TEST1' 'TEST2'

or

:CATALOG BP 'MINE' 'YOURS' DIRECT FORCE

....but this isn't true in some MV flavors. Standardizing this (little
thing) syntax __SHOULD__ be the MV vendor's responsibility! The excuse that
each flavor has its own quirks that one should get used to is pathetic when
the environment (aka: query language and BASIC) isn't consistent.

[snipped]

You've come to understand the problems of solutions providers (technology
de'jour is the bane of solutions). :-)

How does one justify a rewrite of an application into technology that
requires four people to inderstand and implement; completely discounting the
fact that each of these four people have no clue what the others are doing.
This really is the "blind leading the blind"!

Even the simple third party email solution is full of hazards. It works for
awhile until one upgrades their underlying O/S. Then the new package acts
differently (hey, it's been upgraded and offers to do more that not many
really want) and the application has to be adjusted to the tool. Fine;
however, the more such tools one uses the more adjustments this introduces
more often. Eventually, it's very difficult to manage the application
within any reasonable cost structure.

Packaged solutions like DesignBais, Visage, SB+, OI, RedBack, where the
original developers, or business people, can grasp the converted solution,
seems to be the most reasonable path. The other option is to find a rocket
scientist; business-wise not the first choice. :-)

The cost structure of such a move is pretty simple...one extra sale mostly
pays the costs of the conversion! A number of enterprise MV applications
can be had for $15K - $20K while a cheap pest control billing software
product on a PC can cost $25K. So, our choices are to either drop out of
the market (many have) or to reasonably convert (many are). Now, it's up to
these solutions providers (and the MV vendors) to price themselves
reasonably where they grow with an increasing market.

Bill

"Chandru Murthi" wrote:
Sorry bout that - no PHP or Perl. To my knowledge the transport is
all server-side ASP, through XMLHTTP/Ajax via XML, then client-side
scripting. All instructions for control positioning are delivered in
a payload, as well as data which then populates the controls. Many
controls defined by the developer may be delivered to the browser but
not rendered until required. This is how fast dynamic screens are
rendered, though we can also make major page changes by passing new
sets of instructions-as-payload.

Someone who is developing with the product is completely unaware of
such mechanics, and because of this DesignBais International has
considerable freedom to change the underpinnings as required to
support new browsers and servers. The developer clicks on his browser
to create screens, he writes BASIC code to support events, and he
clicks a link to see his efforts. The developer doesn't think in
terms of scripts, transports, or payloads.


This was possible in the past but the new version makes it more of an
official feature. I have clients who want to re-purpose a form based
on data entered by the user, so we needed this ability to make drastic
changes without it looking like a complete page refresh. DesignBais
International (DBI) was responsive as usual and documented a
standardised way of doing this in the current release. With all of
these questions about what the product does now it's important to note
that a great deal of my support for a company depends on how
responsive it is to improving the product within a reasonable time
frame. DBI has proven itself extremely responsive to its channel.

Big agreement there.

And Pick BASIC tokens vs FlashBASIC.
And the .NET Common Language Runtime.
And Java.
And in other languages supporting early/late binding...


_That_ is the key point when you ask about DesignBais (or any other
product really) supporting client-side scripting. In a real business
form people do not expect glitz and dancing images, but they do expect
an elegant way to navigate and view their data. There is a limited
number of client-side validations which are required. If all of the
required behaviours are in the developer's environment, and the vendor
(DBI) is responsive to additional needs, then the developer does not
ask for the ability to add scripts.

Chandru, I think we're much closer to being on the same page here -
including agreement that scripting is helpful when one really does
want to get out of the box, and that's why I have my blog category for
DesignBais.


I wrote a very complex front-end in JavaScript/DHTML to create heavily
dynamic pages, using FlashCONNECT as the transport. The end result
was nice but doing this in JavaScript was probably the worst technical
decision I've ever made. Supporting the code was a nightmare, and
enhancing/repurposing it was time consuming and expensive. I learned
some good business lessons in that project. Sometimes what we 'can'
do is not what we 'should' do.

Regards,
T

TG@ removethispartNebula-RnD.com