heADs up (was: RE: The filePro Group - A second attempt)

[Bruce Easton]

Mark Luljak wrote Wednesday, July 25, 2007 5:45 PM:

[..]
>
> I do, but it still involves development and design time no matter what
> tools you use.  OG takes the hard parts out of the integration and
> implements major security,

and helps you organize your web applications

> but you still have to design and code.
> Well, you do if you do it directly it does.

a lot for truely robust dynamic apps - and if your project is not
very similar to something you've done before, then that a lot of
custom work.

>
> STN is working on a product that's -really- good RAD for fP on
> the web, and
> sits on top of OneGate. *waits for Bruce to chirp up*  It'd be
> faster to do
> it from that higher level, definitely.
>

I was worried during the first year or so of writing database-driven
web apps that filePro's report and clerk would not be fast enough to
server well as a cgi runtime for among other things, interfacing
directly with filepro files.   I was concerned that I was trying
to work at something already at too high a level.  Well, much to my
surprise, they did nicely.  And they did nicely enough that I
realized I could take things to another level and develop, using
only OG and filePro, a complete runtime and development environment
specifically for filepro files.   Well, several years have gone by
now since these concerns.  For this product that Mark mentions
we are working on, some of the major goals have been:

- rapid development capability with robust web-driven tools,
- easy to apply robust and dynamic functionality (I am now empowering
the developer with easy to apply AJAX library toolset/easy to apply
AJAX custom functions),
- easy application of existing/new filepro transactional processing
at various key points in record life cycle
- consistent default, but easily flexible user interface (for the
default, filepro is a good example of this - how much easier can it
be to get a file built and working right out of the box)
- well-defined communication methodology between runtime program
and developer-defined processing

Oddly, the approach has been fairly object-oriented in nature.
But I would have to say what has been important in general is
that we've worked hard to make it easy to both have a nice stock
way of applying something, but also an easy, standardized
method for attaching custom work.

Don't know when this monster might be available, but I can say we
already have several apps in the field where all or major portions
were developed (on a services basis) using whatevericalleditlast.

Bruce

Bruce Easton
STN, Inc.

ampersandnonbreakingspaceampersandnonbreakingspaceampersandnonbreakingspacea
mpersandnonbreakingspaceampersandnonbreakingspaceampersandnonbreakingspace:)