Post by Patrick PayneDoug's coyote product is more than just a web server. He also has his
own App development tools. What this means is you can write a web
page in the editor and include pick code directly in your html page
the same way you would include code in a PHP, perl, asp page.
The coyote web server then on the fly has to somehow pull this code
out, compile it, run it, and return the result in the page.
I admit I'd forgotten this detail.
Post by Patrick PayneNow, in my web server I did not allow actual code, but I did create
insert points that would be actual pick statements.
Example
<html>
<body>
|INREC<1,1>| * pick variable
|OCONV(INREC<2,1>,'MD2-')| * pick variable run thru oconv
|TIMEDATE()| * pick function
|INREC<10,2> + INREC<11,1>| * two pick variables with math
</body>
</html>
I've done similar things, using custom tags parsed by a Java servlet.
Post by Patrick PayneNow, I could have TRIED to write my own interperter and try to
evaluate what the user was trying to do. Or I could write a pre
routine that would grab each of the insert points and create a
subroutine as such
* SOME SET OF CODE HAS GOTTEN ME
PRE.HTML= *HTML UP TO THE INSERT POINT
AFT.HTML= *HTML AFTER THE INSERT POINT
INSERT.CODE= * MY INSERT CODE PARSED OUT, I.E.
INSERT.CODE="INREC<1,1>"
ROUTINE<-1>='SUBROUTINE GET.INFO(RETURN.DATA)'
ROUTINE<-1>='RETURN.DATA = ':INSERT.CODE
ROUTINE<-1>='RETURN'
WRITE ROUTINE TO BP.FILE, 'GET.INFO'
EXECUTE 'COMPILE BP GET.INFO' CAPTURING RESULT
* EVALUATE RESULT FOR ERRORS
EXECUTE 'CATALOG BP GET.INFO'
CALL GET.INFO(RETURN.DATA)
HTML=PRE.HTML:RETURN.DATA:AFT.HTML
..
..
Now this is overly simplistic of what I am actually doing, and in
reality I only have to do this compile once for a page, that is until
changes are made. But how else is microsoft/php etc doing this? It
seems to me that ASP is pulling code out from the .asmx page and
running it thru its vb compiler. I have seen the compile errors when
you do things wrong.
Certainly. I suspected from what you were saying that you were
generating code on a per-request basis, which I'd have said was a
distinct problem.
BTW, "old" ASP didn't compile - it was strictly interpreted (yuck). And
I think PHP and Perl are always interpreted as well. JSP pages are
compiled into Java servlets.
Post by Patrick PayneThe bottom line is a VM environment like d3 does this very well and
very fast. This makes D3 a pretty decent web development environment.
Jbase on the other hand is more c++ compiler specific and you run
into all sorts of issues.
Issues, certainly, but surely not insurmountable ones? It seems to me
that you've written code which depends upon very specific types of
behaviour as defined by D3, and now you're complaining that jBASE
doesn't have the same peculiarities as D3.
Let's look at what you expect of the environment here...
1. The ability to compile code even if it's in use.
2. The ability to recognise and load new versions on the fly.
I'm willing to bet that point 2 falls down on systems other than jBASE.
In fact, if you weren't using call by value (CALL @), it would fall down
on D3. You'd have to restart the web server for each change to a
scripted page.
In any case, it's probably a simple thing to get around. Keep a version
number for each page on a file and increment it for each compilation.
You could cache the version numbers to save on file reads, if that
really matters (and it probabyl doesn't).
Post by Patrick Payne#1: The cataloging Dll's - Both a sharing issue (two programs cannot
compile into the same dll at the same time) or (you cannot compile
into a DLL group while a routine is being execute by somebody else)
#2: Compile times are much longer
#1 is surmountable. Simply set up your environment variables so as to
compile one s/r to a library.
#2 really shouldn't be an issue if compilation is really only taking
place when a page is changed. Hell, if you needed to, you could take the
generation/compilation logic out of the web server and require the pages
to be compiled by the web programmer. Problem solved.
Post by Patrick PayneThe bottom line is Jbase really does not lend itself to this type of
work. The vme environment works much better, and I am assuming the
PHP, asp, asp.net, etc all implement a VME style environment for
running web junk and allowing the on the fly interpertation of code.
I think you're being a trifle unfair here. I could show you tricks that
jBASE can play that make it a far more flexible player in the web world,
but you're focussing on your own problems and ignoring the wider picture.
The bottom line for me is that, if jBASE were to precisely mimic D3 or
any other MV flavour, there would be no good reason for its existence. I
like it *because* it's different, and I think it's mostly different in
just the right ways. Obviously you and I are different as well, so we'll
probably just have to agree to differ. <g>
Luke