Don't use Django.
On 13/03/18 13:58, Thierry Nivelet wrote:
Great discussion, thanks for your insights!
So you use Django without doing Web App?
"/Django makes it easier to build better Web apps more quickly and
with less code./"
Thierry Nivelet
FoxInCloud
Give your VFP app a second life in the cloud
http://foxincloud.com/
Le 13/03/2018 à 17:33, Ricardo Araoz a écrit :
Love Python. Don't do browser apps.
On 13/03/18 13:23, Thierry Nivelet wrote:
Ricardo,
Whatever the language you choose, you'll meet 2 serious obstacles
down the road to a Web Application:
1. **Write responsive HTML/CSS/JS**: if you want to somehow clone
the layout of the forms of your VFP desktop application, and render
it as responsive HTML using - eg. - the Bootstrap framework, it'll
take you up to 10 levels of nested divs to get a proper layout; no
GUI editor at the rescue for that: you'll have to hard code using a
text editor, and choose appropriate class and IDs without getting
messed up; and it soon becomes very complex and difficult to handle,
especially because CSS computes the layout for you based on the
structure and rules you define. If you want a responsive layout, you
can no longer set .left, .width, etc., you must let the browser
compute positions and dimensions. Generating HTML is the area where
your Python code will mostly be used and, strangely, this is only
the emerged part of the iceberg as point 2. below explains.
2. **Maintain user state**: in your VFP code, each time you write
'thisForm…' or 'this…' or 'alias.field', or read a public variable,
you query (without knowing or realizing it) the user state, as it
results from the succession of user actions applied to some initial
state. In VFP, as a single instance of the application serves a
single user, everything can persist in memory: easy and painless. On
the Web conversely, as the same application can serve any user in
any sequence, the user state can exist only if you somehow maintain
it (save and restore). No framework, whether it's Python-based or
C#-based, will ever do that for you. Then you have roughly 2 options
to maintain the user state: **on the client or on the server**.
Maintaining the user state on the **client** requires to:
- write a lot of JavaScript, probably with some client-side
framework such as jQuery, Angular or Ember (be aware that these
frameworks are pretty conceptual and difficult to master properly;
they at least require that you are very proficient in HTML/CSS/JS as
they add several layers above these technologies). Whatever your
choice, you write no Python here, just HTML, CSS and JS.
- use client side storage to create on the client something similar
to a view that you'll submit to the server once user decides to
save. This requires a good knowledge of web storage API, another
JavaScript-centric technology
- expose all your business and presentation layer code to the
outside world; just like you would expose all the VFP code you have
in *.scx and *.vcx, except queries. You can only obfuscate this code
(eg. minify renames variables in alpha sequence such as "a", "b",
"c", "d", etc.), concealing it is impossible as the browser must
read it.
This is the solution that most developers use nowadays; exchange
with the server are merely data conveyed in the JSON format.
Maintaining the user state on the **server** requires to:
- write double code: client side code altering the user interface is
almost the same, except it must query the user state from the server
to take proper action; the amount of code is much higher, and client
and server must somehow understand each other, this generally
requires either being a 'full stack developer' or defining tight
rules (eg. naming) between client and server.
- store user state on a server disk so that any web server can
retrieve the state for any user at any time (forget about assigning
server instances to specific users like in the desktop world, it
just does not work for high user counts; a typical web app serves
200 users and this figure can go up to several thousands)
- choose or define a format to store user state: could be a simple
JSON string that the client JavaScript provides after each action
(then you need to choose a scalable structure), or a table that you
can easily query to, eg., find differences between states before /
after user action.
FoxInCloud helps you dramatically in these 2 critical areas:
- **generate responsive HTML/CSS/JS code** from your VFP forms:
FoxInCloud understand how controls are aligned and grouped on the
page and builds the corresponding groupings (row, column, *-group)
in the Bootstrap CSS system
- **automatically maintains user state**: because FoxInCloud runs
your VFP forms on the server and these forms are object oriented,
FoxInCloud is able to detect what the user actions change on the
form and save these changes in a structured way; the same for the
dataSession (views, cursors, table states) and the general
environment (public variables, _Screen and _VFP custom properties,
aliases in the default datasession). FoxInCloud maintains the user
state on server side, in tables using a naming convention
(user\form_[ante/post].dbf). The only thing you need to do is:
declare the native properties (eg. 'visible', 'enabled') that the
user action can affect (custom properties being saved by default);
FoxInCloud compares the state before and after user action to
identify the visual changes that the browser must apply: you have
strictly nothing to code to make this happen.
As I already often wrote, FoxInCloud can be regarded either as a
final, or just an intermediary step to a Web Application; you can:
- take advantage of the generated HTML/CSS/JS to save months of
writing responsive HTML
- judge whether the user state maintenance mechanism suits you and
eventually recode a similar mechanism in Python (or other)
- mitigate between a server-side and client-side user state
maintenance to save response time while protecting the code that you
consider critical.
I would be delighted if VFP developers would consider FoxInCloud as
a community-inspired effort, and would like to cooperate towards a
future suitable migration path to the Web, rather than like a "take
or leave" product with the VFP stigmata.
FoxInCloud does incorporate thorough software engineering thinking
about running a Web Application while taking advantage of a Desktop
Application background, going far beyond and above the mere language
level which, in any case, does not and will never provide a complete
solution to building a Web Application.
Thierry Nivelet
FoxInCloud
Give your VFP app a second life in the cloud
http://foxincloud.com/
Le 12/03/2018 à 23:53, Ricardo Araoz a écrit :
Thanks Thierry, but I've gone over to Python, love the language and
libraries, gives me pleasure to write it. As for the 10x times, it
might be true if you are left to your own devices. But thankfully
it has loads of beautiful and useful libraries which allow me to
keep writing a language I've come to love.
Cheers
On 12/03/18 15:04, Thierry Nivelet wrote:
Ricardo,
Unless learning Python is for you so important and compelling that
you accept to spend 10x more time for the same result, did you
look at FoxInCloud?
Thierry Nivelet
http://foxincloud.com/
Give your VFP app a second life in the cloud
[excessive quoting removed by server]
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/3d9fc79a-9271-2c03-bc49-fb0bfcac6...@gmail.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.