go RE: OT: PHP/filePro Tools

[Mike Dawson]

A couple of comments:

1.  PHP is an ever evolving challenge to keep secure.  There is no argument
you can present to discredit this fact.
	PERL is a far more secure interface IMHO.
2.  For the filePro users who believe that the business rules or business
logic should be extended in fP, your system is useless.
	You are describing a server side PHP application that achieves
business logic via PHP, not fP.
3.  A more intelligent approach to your system, in my opinion, is to write
an fP application that educates an external SQL db on the fly.
	Been there, done that, and it works nicely when you want to port to
another container and insulate your fP data real time.
4.  Your approach sounds to be more of a read only method.  Should you
attempt to implement a full R/W solution utilizing fP's index system,
	I fail to see how the lockfile issues can be avoided.

My two cents.

<MD>


--------------------------------------------------

-----Original Message-----
From: Filepro-list
[mailto:filepro-list-bounces+mikedawson=bellsouth.net at lists.celestial.com]
On Behalf Of Jose Lerebours via Filepro-list
Sent: Saturday, January 30, 2016 3:15 PM
To: filepro-list at lists.celestial.com
Subject: Re: OT: PHP/filePro Tools

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->

_______________________________________________
Filepro-list mailing list
Filepro-list at lists.celestial.com
Subscribe/Unsubscribe/Subscription Changes
http://mailman.celestial.com/mailman/listinfo/filepro-list