OT: PHP/filePro Tools

[Jose Lerebours]

You are so predictable it is not even funny!

I cannot and so you cannot ... lol

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!).


I'll put it together and replace your OG for free just to mess with 
you.  ;-)


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!

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.

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!

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.

Be well Mark!




On 01/30/2016 02:17 PM, Fairlight via Filepro-list wrote:
> On Sat, Jan 30, 2016 at 01:51:59PM -0500, Jose Lerebours via Filepro-list thus spoke:
>> I have written a couple of scripts and I am putting together a small
>> application combining these scripts to turn them into a "must have"
>> for those of you that want to have web access without the web
>> development.
> There is no such creature.  You cannot create custom web applications
> without doing the web development.  You can make it -easier-, but you still
> have some development curve and time investment, no matter what middleware
> you use.
>
>> How many of you out there could use something like this?
>>
>> What say you!?!
> I say it's not even remotely possible to do it in an absolutely generic
> sense which will work in more than maybe 50% of use cases, let alone
> for anything complex.
>
> If you can do it, more power to you - but I don't believe for a second you
> can do it.  If it were -actually- possible, it would already have been
> written by me, and rolled into OneGate.  What, you think I wrote OG, got so
> far, and said, "Ah, good enough...let them eat the rest of the development
> time."  Or perhaps, "You know, I really hate doing this web development
> myself, but I'd rather do it once for each function per client than develop
> a write-once/use-everywhere solution.  I'm a glutton for punishment, after
> all."
>
> Seriously?
>
> No.  I'm not an idiot.  I've also got a lot more (and longer-standing)
> web development experience than you do.  I'd have written it, and then
> charged a mint for it, because it would have been worth it - both to me,
> and to people with more cash than time.  Too bad it's a unicorn made of
> pure unobtanium.
>
> filePro web access without web development time/cost is as big a myth as
> perpetual motion.  It can be accelerated, it can be made secure, it can be
> many things.  What it -can't- be is a mystical black box which actually
> cuts out the development cycle.  Not unless someone obtained filePro source
> code rights with the requisite accompanying embedding and derivative works
> rights.  Your own blurb indicates this, as you don't specify, "No code
> rewrites necessary."  The second you run into an @event trigger in standard
> filePro code and try to convert it to web-based access, you incur new
> development, and the associated time and cost, full stop.
>
> In my opinion, anyone who actually buys into what is being peddled in this
> thread probably deserves exactly what will likely befall them. :/ Even
> STN's best solution sitting on top of my own product has its limitations.
>
> Beware garden paths...
>
> mark->