DesignBAIS/Dave Bryant

#41

Symeon wrote:

Quote:

As Tony says you can also "debug" your code in the DB app (browser
window) using debug variables which are displayed etc. So we can do it
both ways, tho only native in a session.

This approach is OK in a development environment, and we have all used
PRINT statements to achieve the same result. If your QA is 100% then
you will never have a (critical) issue in the field - if you DO have an
issue with a deployed app that comes from left field, then being able
to access the native debugging tools can be useful

Quote:

I think the advantage Ross is saying about his stuff is that you get a
dialog window in the browser to enter native debug commands into the
debugger.... Surely if you are developing the system you have some
form of tcl access and are able to enter the native debugger anyway. I
entered the native debugger in the browser window in about 1998 when
wintegrate was released as an activex component, not the same thing i
admit, but shows it is nothing new.

And before wintegrate and accuterm you had access to the basic debugger
from a trusty Wyse terminal (and just to show there is nothing new
under the sun, I note Pete @ AccuSoft has just added Prism P30
emulation. Personally I think it is FANTASTIC that there has been a
request for this [I assume he didn't do the work "for fun", and yet :-]

I think the thing that Chandru (& Frosty?) "gets" is the fact that
there ISN'T an activeX terminal emulator running a telnet session in
the equation! Your experience is obviously different, so you see no
advantage - that is fine, and more power to you!

Quote:

Ross - on your point about entering the debugger via a live site,
without establishing a vpn to get shell acces, i presume this was just
an example of what you can do, but i have to say, if my customers knew
i could enter the debugger on their public internet site they would
through a fit !!

Many of them dont even allow shell access at all
to the live system, only dev and test.

Not all Visage applications are deployed to Public internet sites.
Indeed the majority of developments are for mission critical systems
deployed WITHIN the organization, or specific trading circles, rather
than being open to the public - this slightly different emphasis may
give a better understanding of where/how the feature might be used.

You are, of course, correct that it probably (definately) would be
"foolish" to enable this capability on a public web site. That is why
you can selectively enable the option (like all of the "extra baggage"
features that Tony refers to) - if you don't want it, don't use it, but
the facility is there if you ever find you have such a need in the
future (like all of the other features that Tony dismisses as "too
much":-)

Quote:

I am sure Ross's debugging functionality is great, and another way of
doing things, but I feel strongly it is not proof of visage being a
better product than designbais. I have never seen visage so can not
honestly compare, but most of the arguments I have heard against DB
are, for most people i know, completely irrelevant.

My comment was meant not to prove that Visage is "better" than DB (or
any other product for that matter), but was rather a response to Tony's
request for something "new".

Compared to the "debug dumps" I see from Public websites developed with
..NET and ASP when scripts or components fail (I saw a classic "server
too busy" error this week with just 150 threads!), I thought this
qualified, and that he would have appreciated the technology & concept
.... apparently I was mistaken (yet again).

Ross Ferris
Stamina Software
Visage > Better by Design!

#42

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

Quote:

Please feel free to pick nits where nits exist (there are some good
ones) - this aint the right place.

Am I the only one riled by this sort of statement? Who decides the right
place (don't answer that)? Should I feel grateful for the encouragement?

Fwiw, some actual responses embedded:

Quote:

"Chandru Murthi" wrote:
What's with all the ~_ ? I'm always amazed that designers ignore the
simplicity of the am/vm/svm delimiter set and invent their own
(Tony-please
note unnecessary reinvention of wheel), resulting in the unneeded
SWAP/CHANGE code.

One of the ways DesignBais communicates from server back to client is
by wrapping instructions generated from code in XML and then passing
that text up to the client. The am/vm/svm delimiters can corrupt the
XML packets in either direction, so another neutral delimiter was
chosen. You can easily use another delimiter of your choice during
development and replace that prior to transmission back to the client.

Precisely the problem. "You", if meaning the developer, should not have to
worry about this. If am/vm/svm can corrupt anything, the drivers should
escape them. Incidentally, I use them and they don't corrupt anything, but
it may depend on your apache/iis settings.

Quote:

This is picayune stuff - all software does this whether using
asterisks or periods or hyphens or other characters for delimiters.

No it's NOT picayune stuff, it's the essence of GOOD design. One may think
it's easy to remember yet another delimited syntax, but to most people it's
another pita they don't need, especially since it's NOT necessary. This
attitude is precisely what I am against, all too prevalent in systems
designers. Like architects who never consider how their buildings are USED,
software designers don't consider how their software flies in the real
world.

Quote:

For that matter, if you're going to pseudo-emulate css
syntax, why not MAKE it CSS syntax?
The principle I use is to copy existing syntax if well known, even if I
don't like it.
Well, it _is_ CSS, that's what Ross was complaining about - as we see
so far there are only two opinions expressed on this and there's
already disagreement.

Eh? this is CSS? Which reference?: 'border-style

utset~|border-width:1~|
......

Quote:

We just don't need to hardcode all of the
syntax that's required in an HTML page, we can be more "spartan" about
it. This is why DesignBais doesn't build an API around CSS, but it
does allow us to pass CSS syntax directly up to the browser. It's a
good compromise that avoids the need to create a proprietary solution
that no one would like.

Rubbish-If "doesn't build an API around CSS" means not being given a simple
interface to insulate the developer from weird syntax (I can never tell from
your description). That's exactly what one should do.

Most Web development tools (mantra-use the right tools etc) fall over
themselves to isolate the user from details and let them set up things in a
wysiwig way. What else is this but a "proprietary" solution?

Quote:

Good: VAR= 'border-style

utset;border-width:1;background-color:RED;' .
Better: LEAVE the delimiters as they came from on file and let the lower
level code deal with it.
Best: How about something simple like:
CALL CellProperties(row,col, 'red':@am:'white:@am:'outset'...)

Better yet is replacing "row" with the field name so you don't have to
futz
with changing it when, inevitably, you delete or add a column. The
principle
should be to NEVER use a numeric reference when a name is available.

You can use the Good syntax you describe, if you want, but it must be
converted later for internal purposes with a single Swap statement.

Once again, I mean the underlying (hidden to user, unseen, lower-level, not
cared about, let-someone-else-worry-about-it) code could and should do this,
not "you" if "you" means "me the application developer".

Quote:

don't know why a semicolon wasn't used in DB itself but it does make
sense.

I agree with what you're saying in principle but for your CALL
statement someone could just as easily complain about the requirement
for everything to be in a fixed position, and how that might be
unreadable, or why not have a separate argument or whole subroutine
just for specific visual attributes... This sort of thing can go on
forever.
Again the important thing is that we have the opportunity to
do all of the things discussed here, and the product does not limit us
to someone else's notion of accomplishing these functions.

There's a fine line between being wishy-washy and developing incorrectly.
Since all products have limitations, the designer must attend to how the
product is used. It's actually pretty easy to design flexible interfaces if
you put yourself in the user's shoes. A trivial example is the ability to
enter, say, dates in different formats. Many apps force a specific format
when it's clear (see Pick) you can use multiple. A worse example is apps
(particularly web apps) that force you to enter, say phone numbers, with
dashes or alternatively won't accept dashes. Since there's some code that
validates the entry in the first place, how difficult is it to allow both?
But too may systems "designers" are too self-absorbed to consider making
things easy for the user.

Quote:

There is no winner to this sort of thing. I write API's all the time,
there are always compromises. If you hardcode a solution some
percentage of the people won't like the way you did it. If you leave
the solution versatile as DBI has done, your going to get some
opposite proportion of people who insist the product should define
such things, and of this group there will certainly be those who will
find fault with the way it was implemented anyway.

Of course you could, if you were really trying, do both. You might, for
example, allow the CALL argument to have @AMs and a fixed data
structure --good if reading a table from a file, AND also allow script-like
x=y formats, thereby pleasing everyone.Too complex? Too much work?

#43

"Ross Ferris" wrote:

Quote:

Compared to the "debug dumps" I see from Public websites developed with
.NET and ASP when scripts or components fail

This sort of reporting is also an development-mode option which
can/should be turned off during deployment. Too many developers miss
this. .NET 2.0 has many built-in ways to provide reporting back to
the admin without bothering the end-user with technobabble. It's just
up to the developers to use the tools.

Quote:

(I saw a classic "server
too busy" error this week with just 150 threads!), I thought this
qualified, and that he would have appreciated the technology & concept
... apparently I was mistaken (yet again).

I sincerely appreciate the coolness factor of the accomplishment and
I've given some thought to how I would write a middle layer between
client and server that extracted debug data and allowed interaction
with the debugger during a live session from any external interface.
(Emulation is flattery?) I'm sure our solutions would be very
different. If I hear enough people say this is a desirable feature I
might write up a proposal to suggest how and why products like
DesignBais might support it. In the big picture, and I could be very
wrong, considering the debugging techniques we all already have
available to us I don't see this as being a "gotta have it"
enhancement. I haven't heard anyone complaining about the way we do
debugging. To me it's the sort of solution that requires one to
explain exactly what the problem was that we were trying to avoid, and
my answer is - oh, that's not a problem... so why do I want this?

From a technical standpoint, and I have no idea how you implemented
this, but (just to use the name Visage once more in a thread about
DesignBais I'm sure you'll tell us) I wince at the idea of trying to
get the disconnected/async web browser to hold a persistent connection
to a back end for debugging purposes - that's just wrong. I trust
you're not doing it like that.

T

#44

Chandru Murthi wrote:

Quote:

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote in message
news:lg8fg2pv3q9jt6llrcc5nfuchtn5qdou3i (AT) 4ax (DOT) com...
Please feel free to pick nits where nits exist (there are some good
ones) - this aint the right place.

Am I the only one riled by this sort of statement? Who decides the right
place (don't answer that)? Should I feel grateful for the encouragement?

I read that line and thought "I bet Chandru won't like that chiding"
and then read this, so I'm laughing. Just figure it is Tony's opinion
and giving opinions is certainly acceptable on NGs.

Quote:

Fwiw, some actual responses embedded:

"Chandru Murthi" wrote:
What's with all the ~_ ? I'm always amazed that designers ignore the
simplicity of the am/vm/svm delimiter set and invent their own
(Tony-please
note unnecessary reinvention of wheel), resulting in the unneeded
SWAP/CHANGE code.

One of the ways DesignBais communicates from server back to client is
by wrapping instructions generated from code in XML and then passing
that text up to the client. The am/vm/svm delimiters can corrupt the
XML packets in either direction, so another neutral delimiter was
chosen. You can easily use another delimiter of your choice during
development and replace that prior to transmission back to the client.

Precisely the problem. "You", if meaning the developer, should not have to
worry about this. If am/vm/svm can corrupt anything, the drivers should
escape them.

That makes sense, if feasible, but there could be multiple uses of the
XML so that is it not always invisible (at least debugging). As with
any such design decisions, there are tradeoffs. From a design
standpoint, I would want to have very good rationale for switching
delimiters from one place to another as you know it will cause some
problems. It would have to solve more than it causes to be a good
idea.

Quote:

Incidentally, I use them and they don't corrupt anything, but
it may depend on your apache/iis settings.

This is picayune stuff - all software does this whether using
asterisks or periods or hyphens or other characters for delimiters.

No it's NOT picayune stuff, it's the essence of GOOD design.

I agree that it is not picayune.

Quote:

One may think
it's easy to remember yet another delimited syntax, but to most people it's
another pita they don't need, especially since it's NOT necessary. This
attitude is precisely what I am against, all too prevalent in systems
designers. Like architects who never consider how their buildings are USED,
software designers don't consider how their software flies in the real
world.

I think many architects do consider these things, but I suspect there
often is not good QA regarding such designs. One person might judge
pros and cons (as they are able to identify them), and make a poor
choice. Then once it is done, it's done.

Quote:

For that matter, if you're going to pseudo-emulate css
syntax, why not MAKE it CSS syntax?
The principle I use is to copy existing syntax if well known, even if I
don't like it.
Well, it _is_ CSS, that's what Ross was complaining about - as we see
so far there are only two opinions expressed on this and there's
already disagreement.

Eh? this is CSS? Which reference?: 'border-style

utset~|border-width:1~|
.....

I'm not sure why CSS would need to be stored in a dbms, rather than
simply in css files. Does the application need to interact with the
CSS in some way? Why? In order to have a browser independent spec
that is gen'd for each browser (to avoid the multitude of browser
oddities)?

Quote:

We just don't need to hardcode all of the
syntax that's required in an HTML page, we can be more "spartan" about
it. This is why DesignBais doesn't build an API around CSS, but it
does allow us to pass CSS syntax directly up to the browser. It's a
good compromise that avoids the need to create a proprietary solution
that no one would like.

Rubbish-If "doesn't build an API around CSS" means not being given a simple
interface to insulate the developer from weird syntax (I can never tell from
your description). That's exactly what one should do.

Most Web development tools (mantra-use the right tools etc) fall over
themselves to isolate the user from details and let them set up things in a
wysiwig way. What else is this but a "proprietary" solution?

I ABSOLUTELY AGREE!! This is what irks me with a lot of IDEs. Tools
that facilitate development and tedious details are great, but those
that give yet another view of "metadata" that hides the standard view,
when you still having to debug the generated code (CSS in this case)
can be very costly to developers. WYSIWIG is great for round-trip
development tools (you can see the css and the picture as two different
views of the same data), but I do not like one-way code generators, in
general. Developers then often need to understand the generated code
(for debugging at least, maybe also for the resume) and additionally
need to try to figure out how to get the tool to generate what they
want generated. That is a game I hate to play.

But there is a flip side to coding directly instead of "spec'ing and
gen'ing" too. If you want to write software to be db-independent,
browser independent, language independent, etc, then you want to "own"
the specification and generate some or all of the solution with a tool.
That is how a company like Datatel can be db-independent.

Additionally, if an IDE company wants its customers to be dependent on
it, then it might make business sense to have customers write specs in
your "language" (the proprietary solution you refer to), and generate
the app from the specs. Customers of IDE's need to decide what their
risk is in using any given IDE.

Another tradeoff is that code generators do often make it easier for
someone to get off the ground with a tool, however.

So when I read the Tony and Ross back-and-forth, I make a guess that
DesignBAIS is likely easier to use coming out of the box, but that
Visage might have more varied and advanced features. It's just a
guess, however.

--dawn

<snip>

#45

dawn wrote:

Quote:

So when I read the Tony and Ross back-and-forth, I make a guess that
DesignBAIS is likely easier to use coming out of the box, but that
Visage might have more varied and advanced features. It's just a
guess, however.

--dawn

No! Despite the FUD factor that Tony spreads, I would suggest that
Visage is at least "as easy" (easier?) to use out of the box, wether
people are coming from a traditional Pick/green screen background or
with experience with ANY "mainstream" IDE.

Please ALWAYS bear in mind that, to the best of my knowledge, Tony has
never actually USED Visage (then again, I haven't used DB either - but
if you review my historical comments you will find that I tend to speak
about something that Visage CAN do, then Tony proceeds to pontificate
as to why this is irrelevant)

I would like to think that if anyone were to sit down & do a
blow-by-blow, feature by feature comparison of the products that the
balance would be tipped towards Visage - ESPECIALLY if you were to look
at the full product life cycle (including unnecessary (?) things like
application upgrade packaging & distribution, remote monitoring with
automatic alerting or [dare I say] remote debugging :-)

Dawn, if you (ANYONE else) wants to see Visage first hand to draw your
own conclusions, drop me a line & we can arrange a remote demo, eval
system etc ... but be advised we are unlikely to open source any time
soon :-)

#46

Goo'day, Ross,

On 13 Sep 2006 14:20:08 -0700, "Ross Ferris" <rossf (AT) stamina (DOT) com.au>
wrote:

<snip>

Quote:

No! Despite the FUD factor that Tony spreads, I would suggest that
Visage is at least "as easy" (easier?) to use out of the box, wether
people are coming from a traditional Pick/green screen background or
with experience with ANY "mainstream" IDE.

Wether people? Wether????

Just what do people have to give up to get onto this Visage lark???

I know you also said that "open source no time soon", but isn't
wethering people a bit too expensive... and drastic???

All with a <huge grin> of course....

Regards,

Bruce Nichol
Talon Computer Services
ALBURY NSW Australia

http://www.taloncs.com.au

If it ain't broke, fix it until it is....

#47

Ross Ferris wrote:

Quote:

dawn wrote:

So when I read the Tony and Ross back-and-forth, I make a guess that
DesignBAIS is likely easier to use coming out of the box, but that
Visage might have more varied and advanced features. It's just a
guess, however.

--dawn

No! Despite the FUD factor that Tony spreads, I would suggest that
Visage is at least "as easy" (easier?) to use out of the box, wether
people are coming from a traditional Pick/green screen background or
with experience with ANY "mainstream" IDE.

Please ALWAYS bear in mind that, to the best of my knowledge, Tony has
never actually USED Visage (then again, I haven't used DB either - but
if you review my historical comments you will find that I tend to speak
about something that Visage CAN do, then Tony proceeds to pontificate
as to why this is irrelevant)

I would like to think that if anyone were to sit down & do a
blow-by-blow, feature by feature comparison of the products that the
balance would be tipped towards Visage - ESPECIALLY if you were to look
at the full product life cycle (including unnecessary (?) things like
application upgrade packaging & distribution, remote monitoring with
automatic alerting or [dare I say] remote debugging :-)

Dawn, if you (ANYONE else) wants to see Visage first hand to draw your
own conclusions, drop me a line & we can arrange a remote demo, eval
system etc ... but be advised we are unlikely to open source any time
soon :-)

I find it interesting that most of this started with YOU looking at a
piece of the DB manual and taking the sample code out of context. The
code you refer to is NOT manditory. You only need to do this if you
want to change the attributes of a specific column heading. I think I
will take one of your lines, If you don't want to use that feature then
you don't have to. This goes back to my original point, You DON'T need
to know any of the other Technologies to develop a full Commerical
Grade Web application in DesignBais.

Rick

#48

Careful MATE!!

I might take a fence (or is that a 4 x 2?) at that (note to self: do
NOT post message whilst trying to get kids to skool)

Sorry I dropped the "a", but with all the rain we have had lately
(drought scheduled for next Tuesday) I thought I'd comment on erosion
<kwikly diving for kuva>

Bruce Nichol wrote:

Quote:

Goo'day, Ross,

On 13 Sep 2006 14:20:08 -0700, "Ross Ferris" <rossf (AT) stamina (DOT) com.au
wrote:

snip
No! Despite the FUD factor that Tony spreads, I would suggest that
Visage is at least "as easy" (easier?) to use out of the box, wether
people are coming from a traditional Pick/green screen background or
with experience with ANY "mainstream" IDE.

Wether people? Wether????

Just what do people have to give up to get onto this Visage lark???

I know you also said that "open source no time soon", but isn't
wethering people a bit too expensive... and drastic???

All with a <huge grin> of course....

Regards,

Bruce Nichol
Talon Computer Services
ALBURY NSW Australia

http://www.taloncs.com.au

If it ain't broke, fix it until it is....

#49

Ross Ferris wrote:

Quote:

dawn wrote:

So when I read the Tony and Ross back-and-forth, I make a guess that
DesignBAIS is likely easier to use coming out of the box, but that
Visage might have more varied and advanced features. It's just a
guess, however.

--dawn

No! Despite the FUD factor that Tony spreads, I would suggest that
Visage is at least "as easy" (easier?) to use out of the box, wether
people are coming from a traditional Pick/green screen background or
with experience with ANY "mainstream" IDE.

Please ALWAYS bear in mind that, to the best of my knowledge, Tony has
never actually USED Visage (then again, I haven't used DB either - but
if you review my historical comments you will find that I tend to speak
about something that Visage CAN do, then Tony proceeds to pontificate
as to why this is irrelevant)

I would like to think that if anyone were to sit down & do a
blow-by-blow, feature by feature comparison of the products that the
balance would be tipped towards Visage - ESPECIALLY if you were to look
at the full product life cycle (including unnecessary (?) things like
application upgrade packaging & distribution, remote monitoring with
automatic alerting or [dare I say] remote debugging :-)

Dawn, if you (ANYONE else) wants to see Visage first hand to draw your
own conclusions, drop me a line & we can arrange a remote demo, eval
system etc ... but be advised we are unlikely to open source any time
soon :-)

You want me to work with facts, Ross, when speculation on this matter
suits me fine right now? smiles. --dawn

#50

On 13 Sep 2006 16:18:30 -0700, "Ross Ferris" <rossf (AT) stamina (DOT) com.au>
wrote:

Quote:

Careful MATE!!

I might take a fence (or is that a 4 x 2?) at that (note to self: do
NOT post message whilst trying to get kids to skool)

Sorry I dropped the "a",

So are we... but, honestly, shouldn't that be an "h"????

P'raps yer shoulda staighed ut skool yerselph 'n' lern'd t' spel
propah......

Quote:

but with all the rain we have had lately
(drought scheduled for next Tuesday)

You can have ours... We're sick of it... Had it for 4 years or
more..... It's Melbourne where they complain of "drought!" if it
hasn't rained by Thursday... every Thursday....

Regards,

Bruce Nichol
Talon Computer Services
ALBURY NSW Australia

http://www.taloncs.com.au

If it ain't broke, fix it until it is....