I am evaluating options for adding a browser front end to a MV database. I
was wanting to make sure I was considering all of the options out there. At
present our code is pretty generic and we could switch MV databases pretty
easy, but it would be a major chore to leave MV behind, so I am open to
options using any MV database on the back end. The options I know of are:

Flash Connect from Raining Data
using JD3 (open source package) for the plumbing and writing your own front
end
Nucleus from Binary Star
Visage(?) from Ross Ferris' company in Australia (sorry Ross - don't
remember the name)
DesignBais
U2Logic has a package - don't remember the package name
MV-Internet from (?) - remember seeing something about this package but
haven't been able to find anything recently
Open Insight from Revelation (can this do browser?)

I'm sure there are some I have missed. What other tools have people used
and are there any opinions on how easy/effective these are?

Thanks . . . Matt

On Tue, 19 Apr 2005 23:52:36 GMT, "Matthew Harting"
<hartingm (AT) hotmail (DOT) com> wrote:

If you want to play with a HTTP interface, download OpenQM and MVWWW.
I'm still working on the install docs, but there's enough info to get
it running. You can always e-mail me if you have a problem getting it
working.
It would be pretty simple to modularize your code to work with any
API. You should also consider PHP development in conjunction with a
local MV interface. I'm in the final development process of a joint
browsing application using PHP and Javascript, mixed with
FlashCONNECT. Unfortunately, none of that code will be released as
open source but I'd be happy to discuss the architecture with anyone
interested. PHP is a powerful and portable web deployment language if
you mix it with a DB backend like MV.

Glen
http://mvdevcentral.com

Matthew Harting wrote:
Open Insight does have the ability to work via the browser. You can
create Forms in the Form Designer and save as HTML. They usually need a
little tweaking to get them looking real good. The resulting code uses
a CGI interface to talk with the DB. You can also make CGI calls to do
reporting. We were able to some very cool stuff very quickly and cheaply.

-Irwin

If your running UniData or UniVerse with Microsoft Internet Explorer, then
download the current release of JScript for U2.
http://mvdevcentral.com/projects/js4u2/ The price is right since it's free.

Access url: http://js4u2.mvdevcentral.com/index.html to view all information
and documentation concerning JScript for U2.

Regards, Ian Renfrew


"Matthew Harting" <hartingm (AT) hotmail (DOT) com> wrote

Matthew Harting wrote:
Matt,

Also add to your list - PixieWeb. You can build batch, or
field-by-field interactive interfaces.

For a quick overview please look here:
http://www.pixieware.com/howitworks.htm

Thanks.

Dave Johnstone. (Ph: 519-893-3984 - Canada)
PixieWare and HTML - the GUI for TEXT systems
http://www.pixieware.com mailto:dave.at.pixieware.com

Matthew,

You can also take a look at RealWeb from Northgate in association with
Reality.
Check it out at www.northgate-is.com/reality. Reality also gives you lots of
other options, such as JAVA, SQL via ODBC or JDBC together with a Web
Services interface which will be available shortly.

Mark Fuller

"Matthew Harting" <hartingm (AT) hotmail (DOT) com> wrote

Hi Matt. Be careful about mixing apples and oranges. There are a few
classes of product/packages out there. Your options depend on what
you're willing and capable of doing internally. By making some
decisions up front you can eliminate products from the running without
getting into the details of feature comparison.

1) A "data pipe" will move raw data. It's up to you to create the
browser front-end. All for-fee pipes have some sort of BASIC API that
make HTML generation easier. Some have way more callable functions
than are necessary but some people consider that "value-add".
Advantages and disadvantages include:
-- You are free to use any front-end you want. Examples include Java,
ASP.NET, Flash5 (was Macromedia, now Adobe), VB/VB.NET, C#/Mono, Perl,
PHP, Python, etc.
-- Take advantage of non-MV technologies indicated above.
-- Easy to find people to maintain UI.
-- Easy to change the UI altogether or provide multiple UI's with the
same back-end.
-- You need to do extra coding that a "RAD" tool might do for you.

Products that serve as pipes include FlashCONNECT, jD3, mvInternet,
Web Wizard, Red Back, Coyote.

2) A UI development tool will allow clicking in a GUI, maybe drag and
drop, to help create the front-end. All of these products have a
back-end API to tie into your apps. Questions here involve:
-- How free are you to create the UI that you want?
-- How much does the product tie you in, precluding migration?
-- Is the cost worth the pain the product saves you?
-- If you need to know some new language, does the product really
provide value, or are you better just writing your own code in a new
language?

Products in this category include Visage, DesignBais, mvDesigner.

3) Some products are application development environments, intended
more for writing a new app than integrating with existing apps. The
questions here are similar to the above:
-- How easy will it be to merge existing code with the new paradigm?
-- Does this product "insist" on global changes to accommodate it?

Products here include Visage, Nucleus, and maybe the HTML generator
for Open Insight screens.

You'll notice there is some cross-over between categories. I've
omitted some products through laziness, not judgement.

You know my mantra, "tools are irrelevant", and that can be applied
here by asking yourself less about tools and more about who the
end-user is: Joe Internet? B2B Extranet? Management on Intranet?
Can you dictate the browser they will use, or whether scripting or
cookies will be available?

Why are you looking for a browser anyway? Are you concerned about
deployment? Are you aware that one of the advantages of .NET is what
they call SmartClients, or Zero Deployment installs, which allows you
to safely deploy a real EXE and DLL's via the browser? That gives the
best of both worlds: no deployment issues and a rich client that can
be launched from the desktop. (I just finished writing a project like
this, lots of fun, very cool.)

Of course one of the biggest questions involves cost. There are free
components which involve more work on your part. There are
"reasonably" priced products that do "just enough" - of course those
are very subjective terms. And there are outrageously expensive
products that seem designed to satisfy the needs of people who want to
spend Oracle-style money on their MV-style IT department. I'm just
encouraging you here to investigate value for cost, and evaluate TCO
along with initial purchase value to determine the best fit for your
site.

So the question that people frequently ask "which product is good, or
hot, or right" is entirely dependent on factors that we can only guess
about.

HTH,
T

TG@ uh oh, another long Tony post fromNebula-RnD
..com


"Matthew Harting" <hartingm (AT) hotmail (DOT) com> wrote:

A few additional points, from my 2 years experience so far, in creating a
browser RAD:

1- The data-pipe approach should be a non-starter unless you're ready for
the long haul, or your application with its UI, is dead simple (read:
typical Internet shopping-cart system). The amount of work involved in even
simple validation, displaying multivalued data lines (I am using multivalue
loosely, think invoice line items), etc. is *enormous*. If you don't think
through your design parametrically, you'll wind up re-inventing the wheel
for every new screen, or you'll probably wind up creating your own RAD.
Simply not worth it

The "advantage" of using a separate front end is a double edged sword. Sure,
you can create pretty browser screens and incorporate all kind of whiz-bang
effects. Ask yourself what the problem is that you're trying to solve. If it
requires a "professional" web page look, you may be forced to go this route
(but then, the additional caveat is that only very good web designers can
create a professional page anyway). If you want a functional database
interface with a consistent look-and-feel, use a RAD. I have found that
users of database interfaces have considerably lesser expectations in the
look of their WebPages than, say, an art design firm. Consistency and
usability trump pizzazz.

Remember also that the communication between webpage designers and data-base
application designers is a pipeline (pun intended) of frustration. They
don't talk the same language, or see results in the same terms. What may be
easy for me, as a dbd, to envision on a web-page may be impossible for the
wd's and vice-versa.

And finally, I've never seen the "advantage" of being able to use many
different tools and languages. Took me a year to be familiar with
javascript. The thought of having to deal with, say java, php or perl, with
their bastardized syntax, undocumented features, hidden bugs and weird
interfaces (all of which I now know and hate in jscript) makes me ill. A
jack-of-all languages and master of none I do now want to be.

2- Using a RAD. Find out how much work is involved in creating a
*real-life* application screen, not the simplistic demos most of us can
shove off in an hour.

How do you implement business rules? How simple is the interface? Can you
write it all in mvBASIC, which I assume your programmers are most familiar
with? Is there a library of routines to do repetitive stuff that you do not
need to learn?

How often does the server get called (at the least all normal validations
should be done client-side). Are these specifications automatic (i.e.
specified as you create the page) or do you have to massage the webpage (a
nono)? How much data is sent on a submit (a big problem is the amount of
network traffic created by, say, 100 users; it looks simple to submit only
changes as opposed to the entire screen, but it's a *lot* of up-front
design).

Is a dictionary used (a big plus, but that's my personal bias. I know Visage
does use it, but mostly all RAD's are not setup to use dict words as
objects.)

Locking? Pessimistic is best, believe me, unless you're lucky enough to have
spineless users who won't kick up a fuss when they're informed that all
their changes are for naught as someone has updated the record. And sure,
you could write a lot of code to get around this, but most everybody is used
to pessimistic locking and the browser's-gone-away scenario is easily
handled by any self-respecting RAD (else don't use it).

How does the RAD show a typical line-item screen, how does it scroll, how
does it insert and delete lines? These are *not* trivial questions and are
not trivial to implement correctly. (I remember being surprised at the
programming effort it took to display a grid of values on the jbase web RAD,
albeit 2 years ago). As something to judge from, the jscript involved in the
type of display on the RAD I work with has probably about 2 man-years of
effort. And it still does not use scroll bars.

How much control do you have over display, update of individual fields? Can
you disable a panel, a popup, a line-item, a field, hide it, emphasise it,
easily?

Can you automatically display images from the database and/or the client?

Find out whether the numerous keys that will screw up a database webpage are
disabled (try escape-escape on IE sometime). This also took us a while to
correctly implement, and you don't want to have to do this manually. It's
the worst of all worlds, completely different syntax for different browsers.

3- I don't know about your clients, but many do not allow downloads or
browser extensions. In my ignorance, I will assume that such will preclude
the .NET methodology Tony talked about.

4- Cross-browser requirement is a *bear*. Aside from the
pretty-well-documented differences and quirks, jscript itself may work, and
fail, differently. And it's not just implementation, the testing on
different browsers will drive up time, effort and homicidal thoughts against
the opensource community. Again, as an example, currently our RAD creates IE
5.5+ only applications, workable until now because of our clientele. We will
be required to go NS/FireFox compatibility are least. This we figure will
take about 6 man-months of effort initially, and add a consistent 10-15% in
maintenance efforts forever. Not a pretty thought.

Chandru Murthi

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

On Thu, 21 Apr 2005 15:10:37 GMT, "murthi"
<c_xyz_murthi (AT) seeing_xyz_green (DOT) net> decreased the available
storage space of our news server by typing the following:

The previous 2 paragraphs totally depend on the combined
skills and knowledge of both the DB developer and the web
developer. A well trained DB developer and a newbie web
builder are going to produce some chaotic application code.
The same applies to the reverse.

I don't really know why you separate RAD and "seperate
front end", because they end up being the same thing when
the code is compiled and launched. The main difference here
is that a RAD lays out the web design for you, while
building it yourself requires real web development
knowledge(CSS, HTML, etc).

That is only if you don't define a protocol for both sides
to design by. You should design the pipeline protocol before
any application code is written on either side.

The advantange of knowing several development languages is
the simple fact that not every screw looks like a nail when
you only have a hammer as a tool. I'd rather hire a
developer with a mid-level broad knowledge of Perl, PHP,
Ruby, and JavaScript than a single minded developer who only
wants to use Perl for everything. That developer will be
more inclined to learn other languages and also advance
their current knowledge to fulfill project needs. A
single-tool home builder is highly handicapped in the
carpentry world. The same applies here when you are dealing
with complex web applications.

The syntax for many of the server-side scripting languages
are similiar in format but they each have their own
strengths and weaknesses. Knowing that information is the
key to successful, stable, and portable web applications.
Jscript != JavaScript and that is mostly due to Microsoft
bastardizing Sun's script so that it will only work in IE
and thus to push the browser on the market even harder. If
you are knowledgable enough with the DOM, JavaScript and
JScript, then you can write cross-browser compatible code.
Once again, if you know the restrictions then you can write
successful, stable, and portable applications. What you
don't know in the web world can hurt you down the road.


I agree, these are all valid questions to ask at design
time. However; you can't always do _everything_ in MV BASIC.
You can not directly monitor browser events in MV BASIC, so
you will need client-side scripting. There's no way to avoid
that! That's just one example.

You do not _have_ to perform validation in the browser.
The validation can be initiated in the browser and then
performed on the server side, but your architecture will
need to be designed around that. The amount of coding solely
depends on the architecture of the MV components and the
browser components as a whole. There's a million ways to get
to the same result, but some means can result in 100 times
more code. Once again, lots of development knowledge is key
to a successful, stable, and portable web applications.


I don't think that dictionaries are a good tool for web
deployment. The reason being underlying server and embedded
client logic that can break if the dictionary has to be
changed for local green screen use. I feel that any data
translations should be processed in MV BASIC, if it has to
be done. To each his own, though.

I agree. Locking should be dealt with by session + item
and it should be pessismistic. The key is to lock the item
virtually by cookie or formval session key. The only time a
system lock should be used is when a session is updating a
virtual lock in the global lock file. This does break with
green screen optimistic system locking, but it's the best
method to avoid form re-do headaches. Virtual locks can be
time stamped by the app and then cleaned up by a scheduler
if the browser times out or is closed before the form is
submitted. Ideally, system and virtual locks should be
handled together on both the web and screen sides.

keydown and keyup are global window events across all
browsers. The key character property is also a global event
property across all browsers. Trapping ESC, regardless of
how many times it is hit, is really simple. I'd like to see
a snip of that key-capture script. I'm thinking it has been
overthought. :P

FireFox is not that bad. Netscape 4.x is nearly
impossible. Netscape 6+ is a totally new and unstable animal
but it is doable without too much of a headache. That is, IF
you keep your Javascript code clean. I know exactly what you
mean. Everyone does their Javascript handling just a tad bit
different. You can make it much simpler by sticking to raw
DOM objects when possible, instead of <insert language
brand> renamed objects and events. When you HAVE to have
browser ident, put the ident code at the top of the page and
use a browser ID variable throughout the rest of the code.

That's my 2 cents anyway. Comments appreciated.


Glen
http://mvdevcentral.com

Comments embedded. Chandru
"Glen B" <spamlesswebmaster (AT) nospamforALLSPEC (DOT) com> wrote

I'm using RAD as something that develops html usable from the database, not
merely a FrontPage type app that generates fancy html. There's quite a
difference in the types of html you produce when you're dealing with fields,
line-items, validations, etc than a typical "webpage", and an
application-level RAD would know this. For example, when I design a page, if
a field is "required" I simply check the box on the design panel. The RAD
then knows to build the null check into a function executed before the Save
submit.
I'm talking about jargon/communication, not the technical side of it.
Possibly a typical webpage designer does not relate well to requirements of
a database application screen. But I agree that design is the key..

Well to each his/her own. The flip side of your statement is that by knowing
too many languages, one will, indeed, use what one thinks is most
appropriate instead of working within, and through the limitations of, say,
a predetermined language. If you're the only one involved, well and good.
But if you have 10 other programmers dependent on understanding, maintaining
and extending the application, it's a burden I would not want to place on
them. Just as an example, the RAD I work with has a few custom objects
(Export and Print for example) but everything is in html and javascript. Oh,
the pipeline has a smidgen of C code. We have not found any limitations at
all so far.

The RaD I work with (and I'm sure many others) are *designed* to let you
monitor everything from a single point of view (in this case, mvBasic), and
the scripting is *done by the RAD*. In unusual circumstances you (the app
developer) may have to resort to scripting, but I'd consider my design a
failure if the app needed this on more than a occasional basis. The basic
building blocks: display, entry,. validation, tabbing, most event handlers,
are parametrized so that they are handled transparently. That's what I think
the RAD's for, to isolate you from having to script.

Well, if you have a submit cycle that's less than, say, one second on even a
gigahertz client and server, we may be able to do business. In most cases,
the submit delay is inordinate for "simple" validations eg date formats, and
while of course you need server intervention for any meaningful application,
we keep the *validation* on client side for speed. Multiple submits are also
a major headache in a database app (as you have no control over them) and
the amount of time and effort devoted to keeping them is synch is
considerable.

I'd set up Dict words for the RAD distinct from List or old app usage.

Exactly. I'd add that batch (or non-web applications which may run
concurrently should also use exactly the same lock mechanism, virtual or
otherwise.

The code is different though; I'm not even sure either of these works with
Opera eg:
function DocKeyDown(e)
{ // test for control-R, F5 etc etc ad nauseum, and Backspace keys
if ( IE )
{ e = window.event;
if (e.ctrlKey &&
(e.keyCode==69 || e.keyCode==72 || e.keyCode==73 ||
e.keyCode==78 || e.keyCode==82 ||e.keyCode==87 )
) return CancelKeyIE(e);
} else {
if ((e.modifiers & Event.CONTROL_MASK) &&
(e.which==69 || e.which==72 || e.which==73 ||
e.which==78 || e.which==82 ||e.which==87 )
) return CancelKeyMZ(e);
}
}
Thanks for the heads-up, we've actually done very little work so far on
de-IExplorizing the code, so to speak. The problem is two fold. Generally
speaking, there seems to little formal documentation on things that seem to
work. Such may break later, as in Service Pack 2, where for security
reasons, eg, many window properties were reset on an url reload that were
not before SP2. Another example is where you can assign arbitrary properties
to an object, simply by html initialization or in javascript (I forget the
terminology for this, private properties or somesuch.) But it is not at all
clear that this is "legal", and, indeed you'll find "experts" on the web who
say it should not be done. So do we use this feature or not? Etc.