Doing more (or all!) coding in the HTML

Coordinator
Mar 4, 2011 at 5:09 AM

I redid the scripting example (where all coding is done right in the html as opposed to the main.prg Controller program) to include paging, sorting, saving to the session, etc.  You can see it here along with the source:

http://68.98.143.219:443/avfpdemo5/Default.aspx?action=vfpscript

You can automate main.prg to always just process these files if there is no Case statement for the action but there is an HTML file with the name of the action:

 

... end of case statement

OTHERWISE
   
    IF !ISNULL(oProp.Action) .AND. FILE(oProp.HtmlPath+oProp.Action+'.htm')
        lcHTMLout= FILETOSTR(oProp.HtmlPath+oProp.Action+'.htm')
        lcHTMLout= oHTML.mergescript(lcHTMLout)
    ELSE
        *USE mydbf  && test error
        CookieLogin()  && checks for cookie to authenticate
        lcHTMLfile = 'default.htm'
        lcHTMLout= FILETOSTR(oProp.HtmlPath+lcHTMLfile)
        lcHTMLout= oHTML.mergetext(lcHTMLout)
    ENDIF

ENDCASE
*  end mainline

This way you'd never have to touch main.prg, just code in the html files. I believe this is pretty similar to coding in PHP.
But instead of having files with .PHP extentions we use the URL's 'action' to indicate what file to process.

There are pros and cons to developing this way or using main.prg more as the Controller in an MVC type architecture. Coding in the HTML, of course, mixes up the
presentation layer with the application code, whereas using main.prg to hold more code separates these concerns pretty well. But, I don't know - it is pretty cool
just coding everything in the HTML files and it also seems really fast...

 

Mar 4, 2011 at 9:03 PM
Edited Mar 4, 2011 at 11:30 PM

Claude,

You've done it again!   Though I haven't played with this yet, it sounds like a major development.  It's great to
be able to program everything on one page.   It's much more intuitive that having the main.prg act as a middleman.   

Claude, I also like the way you documented this.  The code shows a clear separation between HTML sections, VFP code
sections, and combined VFP/HTML sections.   Very helpful.

I suppose there are situations where using main.prg is the best way to go, but I'm thinking most of the time this is the best
way to go.

Coordinator
Mar 4, 2011 at 9:38 PM

I went ahead and uploaded the new source for this:

http://download.codeplex.com/Project/Download/FileDownload.aspx?ProjectName=activevfp&DownloadId=213651

Mar 4, 2011 at 9:53 PM
Edited Mar 4, 2011 at 9:54 PM

I'm wondering if you foresee someday calling EXECSCRIPT style functions (or methods) from an HTML
page? 

But that's asking for perfection.  Right now, very appreciative of being able to script in the HTML alone.

Very cool.

Coordinator
Mar 4, 2011 at 10:09 PM
Edited Mar 4, 2011 at 10:11 PM

There's no reason why not - ExecScript is the way to do this without locking.  And it should work right now as is (do a search of 'ExecScript' in this forum for the proper format of calling ExecScript)  

You can use the DO command, set proc, createobject and all of the regular ways to call external procedures but IIS will cache those objects, thereby locking them (you can get around this a little by issuing a CLear Proc but even that doesn't work when an error occurs).  If a class or library of functions is solid enough then it's probably safe to call it the traditional way, but, for code that changes often or might change, use ExecScript.

Mar 4, 2011 at 10:33 PM

Really?   Why that's wonderful, Claude.   Looking forward to playing with all this.

Coordinator
Mar 5, 2011 at 7:06 PM
Edited Mar 5, 2011 at 7:13 PM
danbaker wrote:

Claude,

You've done it again!   Though I haven't played with this yet, it sounds like a major development.  It's great to
be able to program everything on one page.   It's much more intuitive that having the main.prg act as a middleman.   

Claude, I also like the way you documented this.  The code shows a clear separation between HTML sections, VFP code
sections, and combined VFP/HTML sections.   Very helpful.

I suppose there are situations where using main.prg is the best way to go, but I'm thinking most of the time this is the best
way to go.

Actually, if you look at all the Page Number setup code - that all needs to be centralized.  No one wants to put all that code on every page that lists a table and needs page numbers.

Solution:  Centralize it in Main.prg or its own file.

Either <%= GetPageNumbers(10,5 ) %>    **This function would be in Main.prg.  Might be easier and faster than ExecScript below?

or <%= EXECSCRIPT(FILETOSTR(oProp.AppStartPath+'\prg\GetPageNumbers.prg',10,5))) %>

or you could do a DO, CreateObject, etc. if it's solid code (doesn't need to be changed or rarely changed)

I guess the future for Main.prg is less of a big CASE statement and more of a function library...

Mar 6, 2011 at 1:13 PM

This evolution toward a function library sounds very promising.  Nice to see that ActiveVFP is still "active" from a development
point of view.  Who knows where it will eventually end up.