OT: PHP/filePro Tools

[Jose Lerebours]

And just where and how did I say you were gonna have a web front-end on 
top of anything?

I said "web access" not "web application" ...  This is not meant to 
replace your filePro application but to add or enhance it.  I call it a 
"tool" not an API (thou it could be an API).

Is it not a good tool to have it you were able to do those things I listed?

You can have a GUI page where you can pick file, pick screen, search 
record, view record and edit record as well as delete a record. That 
very much cover IUA but it DOES NOT replace the filePro code to 
integrate between two or more tables - I never said it does.

It is not even a big deal to do - sad to hear you fell short!  lol

Nancy's code to edit color screens must be a lot more complex ... so, 
goes to show that it is not impossible, others have just not bothered to 
look for solutions.




On 01/30/2016 04:01 PM, Fairlight via Filepro-list wrote:
> On Sat, Jan 30, 2016 at 03:14:59PM -0500, Jose Lerebours via Filepro-list thus spoke:
>> You are so predictable it is not even funny!
> I am indeed predictable.  I speak the truth as I see it, don't sugar-coat
> anything, and don't pull punches.  Thus ends my predictability.
>
>> I cannot and so you cannot ... lol
> Others haven't been able to either.  And -nobody- except fP-Tech can,
> because you -must- rewrite filePro code in order to simulate @event
> triggers.  It's not possible to transparently use the same code 100% of the
> way and simply toss a web front-end on top of it.  Saying you can is either
> misleading or ignorant.
>
>> The only thing that bothers me about your answer is that you compare
>> me with you and state that I am inferior to you or at least as a
>> developer.  smh!  (I hope you know what I wish to say but wont!).
> Say whatever you like, Jose.  It's your noose; make it as tight as you
> want.  I'll give you not only enough rope, but several rope factories.
>
>> I'll put it together and replace your OG for free just to mess with
>> you.  ;-)
> Luck with that.
>
>> As of this moment, access of index files is possible and so it is
>> searching for records via index thus query of data is not limited to
>> record number and no filePro code.  I can read the entire map and
>> create a form for the entire file and push an entire record on to a
>> form, have you edit it and push it back to filePro ... Done!
> Index access means next to nothing.  You're missing the entire point.  You
> don't have the -language- parser, therefore you have -nothing- which
> -doesn't- require at least -some- re-development time to make it web-ready.
> As I said, the second you hit an @event, you're looking at development
> time.  If you'd like to dispute that plain and simple fact, you're hanging
> yourself even worse than you already have.
>
>> As of this moment, I can read a screen and create an HTML form so no
>> code required to create the form.  Working on script to obey edits
>> and use masking to enforce edit types ... easy if I choose to write
>> a couple of filePro processing table to handle this in the
>> background via ajax.
> And yet...still pointless.  You said, "[...] without the web development."
> If I give you a table full of @event triggers and ask you to make it run on
> the web identically to in dscreen -without- rewriting at least part of it,
> it won't happen.  The facilities aren't there, pure and simple.
>
>> As of this moment, I have the code that you simply need to call to
>> push your document back to PHP and it will render the page with a
>> "call" to the routine ... Done!  ( simpler than OG and fpWeb )
>>
>> As of this moment, I can capture report from filePro, parse it and
>> convert it to HTML5 <table> format and from there, export to Excel
>> and/or PDF ... Done!
> Blah, blah, blah...  And as of this moment, you don't have the filePro
> engine for parsing and executing their language, TTBOMK.  Therefore, your
> claim of no web development being necessary is necessarily patently false,
> as you need to be handle the processing tables as-written in order to
> achieve zero-rewrite status.  And even having the language only gets you so
> far, as you're comparing a persistent-state program to a series of
> stateless handshakes.
>
> In short, you sound utterly clueless on the subject.
>
> I don't give a damn which of us is better, Jose.  I care about the facts.
> The fact is, what you're saying is possible (no web development) is not
> possible for any significant and complex case.  Your statement might get
> someone access to some data here or there, but it is -not- an instant total
> conversion of anyone's project of any decent complexity without rewriting a
> significant portion of the code to accomodate the -entirely- different code
> flow.  That's a fact.
>
>> I do not do things as means to measure myself to others, it would be
>> a waste of time.  Hate to see you wasting your time agonizing over
>> what others can or cannot do.
> I don't personally care if you think you can or can't do it.  I'm saying
> it's not possible to do what your one phrase suggests without the actual
> language parser in an embedded context.  What I care about is not seeing
> others buy into the myth you're perpetuating with extremely loosely phrased
> pre-marketing, and getting sucked into a morass they'll regret if they
> chase an unattainable dream.
>
> A web conversion of filePro is -work-.  Full stop.  There are tools to ease
> the burden, but nothing worth running comes easily or inexpensively in this
> arena.  Anyone who believes otherwise is in for a rude awakening at some
> point in their adventures.
>
> Take the last volley, if you like.  I've nothing more to say on the
> subject.
>
> mark->