Hello everybody, I am exploring Django for my next project.
Most of the examples that I found is making the report in html and then exporting it to a pdf.
Having worked (and still working) with Visual Foxpro reports, all these years, I am looking out for a similar experience with Django/Python.
I tried Gaetan's Appy Framework which takes an odt document as template and merges with xml data to produce pdf via a service which has to run in the background. It is ok, but it is stuck with the old version of Python and I had great difficulty in attempting complex VFP type of reports.
Then I looked at JasperReport. I can design the report using JasperReport Studio. But still there are too many steps involved in spitting out the pdf.
Before I make the final leap to Jasper, I want to ask those who are working with Python - as to what they are using for a GUI reporting tool similar to VFP and that which does not involve a reporting service to be run in the background!
Thanks
Ajit Abraham
The bottom line is I doubt you'll find anything as simple as the Visual FoxPro report writer in the sphere in which you are working. This isn't a Django/Python/Windows/Linux thing, it's just how things are now especially in the web development world.
On Mar 7, 2018, at 4:23 AM, Ajit Abraham foxpro@ua-group.com wrote:
Before I make the final leap to Jasper, I want to ask those who are working with Python - as to what they are using for a GUI reporting tool similar to VFP and that which does not involve a reporting service to be run in the background!
While I don’t do much reporting in Python these days, I would recommend a simple templating system like Jinja or Mako to create the HTML output, and an HTML-PDF converter to create the output. I did a quick google around and found this article: http://pbpython.com/pdf-reports.html . It looks pretty straightforward.
-- Ed Leafe
Thanks Ed. I had seen that before - but as there was no GUI, I ignored it. I need the GUI for absolute positioning of objects - similar to VFP/Crystal/Jasper report builders.
Will have another look at it.
While I don’t do much reporting in Python these days, I would recommend a simple templating system like Jinja or Mako to create the HTML output, and an HTML-PDF converter to create the output. I did a quick google around and found this article: http://pbpython.com/pdf-reports.html . It looks pretty straightforward.
-- Ed Leafe
Ed, never worked with templating systems, but reading the examples I have a few doubts regarding their capabilities, maybe you know the answer to them? In the example they define <title> items, but will the template generate a new title on top of every page? Can you define page sizes, page footers, group headers and footers, group totals, running totals?
On 07/03/18 11:47, Ajit Abraham wrote:
Thanks Ed. I had seen that before - but as there was no GUI, I ignored it. I need the GUI for absolute positioning of objects - similar to VFP/Crystal/Jasper report builders.
Will have another look at it.
While I don’t do much reporting in Python these days, I would recommend a simple templating system like Jinja or Mako to create the HTML output, and an HTML-PDF converter to create the output. I did a quick google around and found this article: http://pbpython.com/pdf-reports.html . It looks pretty straightforward.
-- Ed Leafe
[excessive quoting removed by server]
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
Le 12 mars 2018 à 18:58, Ricardo Araoz ricaraoz@gmail.com a écrit :
Ed, never worked with templating systems, but reading the examples I have a few doubts regarding their capabilities, maybe you know the answer to them? In the example they define <title> items, but will the template generate a new title on top of every page? Can you define page sizes, page footers, group headers and footers, group totals, running totals?
On 07/03/18 11:47, Ajit Abraham wrote: Thanks Ed. I had seen that before - but as there was no GUI, I ignored it. I need the GUI for absolute positioning of objects - similar to VFP/Crystal/Jasper report builders.
Will have another look at it.
While I don’t do much reporting in Python these days, I would recommend a simple templating system like Jinja or Mako to create the HTML output, and an HTML-PDF converter to create the output. I did a quick google around and found this article: http://pbpython.com/pdf-reports.html . It looks pretty straightforward.
-- Ed Leafe
[excessive quoting removed by server]
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
Le 12 mars 2018 à 18:58, Ricardo Araoz ricaraoz@gmail.com a écrit :
Ed, never worked with templating systems, but reading the examples I have a few doubts regarding their capabilities, maybe you know the answer to them? In the example they define <title> items, but will the template generate a new title on top of every page? Can you define page sizes, page footers, group headers and footers, group totals, running totals?
On 07/03/18 11:47, Ajit Abraham wrote: Thanks Ed. I had seen that before - but as there was no GUI, I ignored it. I need the GUI for absolute positioning of objects - similar to VFP/Crystal/Jasper report builders.
Will have another look at it.
While I don’t do much reporting in Python these days, I would recommend a simple templating system like Jinja or Mako to create the HTML output, and an HTML-PDF converter to create the output. I did a quick google around and found this article: http://pbpython.com/pdf-reports.html . It looks pretty straightforward.
-- Ed Leafe
[excessive quoting removed by server]
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
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:
- **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.
- **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]
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:
- **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.
- **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]
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:
- **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.
- **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]
Reading Thierry Nivelet's accurate description of the problems of using a Web Application as an end-user business solution (and his advocacy for FoxInCloud), I started wondering what happened to AVFP (Active Visual Foxpro pages). I got a couple of trivial web pages working based on their examples, but after CodePlex folded AVFP seemed to disapper as well (just a downloadable on the CodePlex archive site). Anybody know what happened to it? (For those who don't know it, it enables native VFP on a web server, in a similar manner to the original ASP).
p.s. iirc there used to be a similar ASP-alike for Python as part of XAMPP, but the Python bit got deprecated. <snip>
That was ProLib wasn't it? They went bust in 2008 or something, although the great Woody has since returned to this fold.
Hi Andy,
Active FoxPro Pages (or AFP in short) was originally created by Prolib. After the insolvency in 2009 it was taken over by one of the largest user (BVL) and later on it moved to Christof Wollenhaupt's company FoxPert (who was the main product-developer at ProLib)
Thus if you look for www.Active-FoxPro-Pages.com or www.AFPages.com you'll end up at http://afpages.foxpert.net/
AFPages still works as expected on any Windows-based Webserver.
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von AndyHC Gesendet: Mittwoch, 14. März 2018 12:16 An: profox@leafe.com Betreff: AVFP - was [NF] Reporting in Python (Django)
Reading Thierry Nivelet's accurate description of the problems of using a Web Application as an end-user business solution (and his advocacy for FoxInCloud), I started wondering what happened to AVFP (Active Visual Foxpro pages). I got a couple of trivial web pages working based on their examples, but after CodePlex folded AVFP seemed to disapper as well (just a downloadable on the CodePlex archive site). Anybody know what happened to it? (For those who don't know it, it enables native VFP on a web server, in a similar manner to the original ASP).
p.s. iirc there used to be a similar ASP-alike for Python as part of XAMPP, but the Python bit got deprecated. <snip>
[excessive quoting removed by server]
Ah, hi wOOdy - thanks for the info - that explains why I was still getting /notifications/ until late 2016. I found A[V]FP fun to use, and there was some impressive technology/(e.g. "side by side" automatic COM registration )/ - I wonder why it didn't take off at least a bit more than it did - scalability? security? Windows Sockets problems? or just missed the boat? Another interesting non-starter was that Russian (?) webserver written in Foxpro.
On 14-Mar-2018 6:38 PM, Jürgen Wondzinski wrote:
Hi Andy,
Active FoxPro Pages (or AFP in short) was originally created by Prolib. After the insolvency in 2009 it was taken over by one of the largest user (BVL) and later on it moved to Christof Wollenhaupt's company FoxPert (who was the main product-developer at ProLib)
Thus if you look for www.Active-FoxPro-Pages.com or www.AFPages.com you'll end up at http://afpages.foxpert.net/
AFPages still works as expected on any Windows-based Webserver.
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von AndyHC Gesendet: Mittwoch, 14. März 2018 12:16 An: profox@leafe.com Betreff: AVFP - was [NF] Reporting in Python (Django)
Reading Thierry Nivelet's accurate description of the problems of using a Web Application as an end-user business solution (and his advocacy for FoxInCloud), I started wondering what happened to AVFP (Active Visual Foxpro pages). I got a couple of trivial web pages working based on their examples, but after CodePlex folded AVFP seemed to disapper as well (just a downloadable on the CodePlex archive site). Anybody know what happened to it? (For those who don't know it, it enables native VFP on a web server, in a similar manner to the original ASP).
p.s. iirc there used to be a similar ASP-alike for Python as part of XAMPP, but the Python bit got deprecated.
<snip>
[excessive quoting removed by server]
My first mail from yesterday stuck in the filter... Apologies if I'm double posting.
Reading Thierry Nivelet's accurate description of the problems of using a
Web Application as an end-user business solution (and his advocacy for FoxInCloud), I started wondering what happened to AVFP (Active Visual Foxpro pages). I got a couple of trivial web pages working based on their examples, but after CodePlex folded AVFP seemed to disapper as well (just a downloadable on the CodePlex archive site).
To avoid some confusion... There is ActiveVFP (AVFP) which was initially a commercial product by Claude Fox (or Fuchs) and later open sourced. There are sources on GitHub https://github.com/claudefox/ActiveVFP from 2013 and an archive on CodePlex https://archive.codeplex.com/?p=activevfp. I don't know which one is the more recent code.
Active FoxPro Pages http://www.afpages.de/ (AFP) is a product originally developed by Peter Herzog, owned by ProLib and later maintained by Jochen Kirstätter and me, mostly. AFP was bought by BvL.com who have a document management system written in AFP. It's still owned by BvL.com, but foxpert is doing support, distribution and development now. It's not open source and requires a license for non-evaluation purposes.
FoxInCloud is built around WebConnection from West Wind Technologies https://west-wind.com/. We looked at supporting AFP with FoxInCloud, but couldn't make the license model work (AFP is licensed per server, WebConnection per developer).
Le 15/03/2018 à 08:47, Wollenhaupt, Christof a écrit :
WebConnection is licensed per developer
quite… WebConnection is licensed per Max(developers, servers)
Thierry Nivelet FoxInCloud Give your VFP app a second life in the cloud http://foxincloud.com/
Reading Thierry Nivelet's accurate description of the problems of using a Web Application as an end-user business solution (and his advocacy for FoxInCloud), I started wondering what happened to AVFP (Active Visual Foxpro pages). I got a couple of trivial web pages working based on their examples, but after CodePlex folded AVFP seemed to disapper as well (just a downloadable on the CodePlex archive site).
To avoid some confusion... There is ActiveVFP (AVFP) which was initially a commercial product by Claude Fox (or Fuchs) and later open sourced. There are sources on GitHub https://github.com/claudefox/ActiveVFP from 2013 and an archive on CodePlex https://archive.codeplex.com/?p=activevfp. I don't know which one is the more recent code.
Active FoxPro Pages http://www.afpages.de (AFP) is a product originally developed by Peter Herzog, owned by ProLib and later maintained by Jochen Kirstätter and me, mostly. AFP was bought by BvL.com who have a document management system written in AFP. It's still owned by BvL.com, but foxpert is doing support, distribution and development now. It's not open source and requires a license for non-evaluation purposes.
FoxInCloud is built around WebConnection from West Wind Technologies https://west-wind.com/. We looked at supporting AFP with FoxInCloud, but couldn't make the license model work (AFP is licensed per server, WebConnection per developer).
On Mar 12, 2018, at 12:58 PM, Ricardo Araoz ricaraoz@gmail.com wrote:
Ed, never worked with templating systems, but reading the examples I have a few doubts regarding their capabilities, maybe you know the answer to them? In the example they define <title> items, but will the template generate a new title on top of every page?
These are HTML generators, so there is just one <title> per document. Not sure how you would translate that to hard copy page breaks.
Can you define page sizes, page footers, group headers and footers, group totals, running totals?
Sure, the templates support embedded code, so you would be able to do that, but it isn't baked-in as in VFP or Crystal. Remember, they are HTML templates, not reporting templates.
-- Ed Leafe
Thanks Ed, you saved me a few hours of reading.
On 12/03/18 15:13, Ed Leafe wrote:
On Mar 12, 2018, at 12:58 PM, Ricardo Araoz ricaraoz@gmail.com wrote:
Ed, never worked with templating systems, but reading the examples I have a few doubts regarding their capabilities, maybe you know the answer to them? In the example they define <title> items, but will the template generate a new title on top of every page?
These are HTML generators, so there is just one <title> per document. Not sure how you would translate that to hard copy page breaks.
Can you define page sizes, page footers, group headers and footers, group totals, running totals?
Sure, the templates support embedded code, so you would be able to do that, but it isn't baked-in as in VFP or Crystal. Remember, they are HTML templates, not reporting templates.
-- Ed Leafe
[excessive quoting removed by server]
On Mon, Mar 12, 2018 at 2:13 PM, Ed Leafe ed@leafe.com wrote:
These are HTML generators, so there is just one <title> per document. Not sure how you would translate that to hard copy page breaks.
CSS to the rescue! You can set up a block with @media print { ... } and include loads of directives to control the appearance and layout of the printed page.
I have a set of reports for one client where the printed page looks much different from the visual page, thanks to CSS.
Check out the @page directive and the :first and other pseudo-tags:
https://developer.mozilla.org/en-US/docs/Web/CSS/Paged_Media
So, you can set up entire blocks within the page"
<div class="printonly">Your Title here</div>
and the CSS:
div.printonly {display:none}
@media print { div.printout {display:inline} }
Thanks Ed. I had seen that before - but as there was no GUI, I ignored it. I need the GUI for absolute positioning of objects - similar to VFP/Crystal/Jasper report builders.
Will have another look at it.
While I don’t do much reporting in Python these days, I would recommend a simple templating system like Jinja or Mako to create the HTML output, and an HTML-PDF converter to create the output. I did a quick google around and found this article: http://pbpython.com/pdf-reports.html . It looks pretty straightforward.
-- Ed Leafe
On Mar 7, 2018, at 9:03 AM, Ajit Abraham foxpro@ua-group.com wrote:
Thanks Ed. I had seen that before - but as there was no GUI, I ignored it. I need the GUI for absolute positioning of objects - similar to VFP/Crystal/Jasper report builders.
Well, there *is* the Dabo ReportWriter, which has a GUI layout inspired by VFP. Not sure how well it runs with modern Python libraries, though, as it really hasn’t been actively updated in almost 5 years.
-- Ed Leafe
I googled a bit. The ideal thing would be something that generates RML (ReportLab Markup Language) and then use python's rml2pdf library, but I havent found any graphical RML generator. You could also check "relatorio" and "pod" if you are willing to work with open office. For a tool which uses detail bands, and total, subtotal, and group bands as well as page headers and footers you could check out PollyReports which is not a graphical tool but a python lib which depends on ReportLab, but allows good control for database reports, as for accuracy it works with points (that would be 72 points to an inch), or you could use ReportLab.lib.units which allows you to work in inches, cm, mm and pica. HTH
Thanks Ricardo,
On 08/03/2018 01:39, Ricardo Araoz wrote:
You could also check "relatorio" and "pod" if you are willing to work with open office.
Gaetan's Appy Framework does exactly that. It works with odt documents. For simple reporting, it is ok. But for complex reports(which is easy in VFP), I found that had to do too much of tinkering. Also it needs Libreoffice to run in silent mode to generate the pdf.
check out PollyReports which is not a graphical tool but a python lib ....
Simply put, I have been spoilt by VFP. Hence hunting for the GUI
Ok. Seems that I will settle in for JasperReport. These are the steps: 1. Prepare the data in XML format (Thanks to yattag library) Along with the table data, I can pass adhoc values like the report title etc 2. Design the report through the free JasperStudio (same like VFP report design tool) 3. Generate PDF through Jadson Ribeiro's pyreport which is a wrapper for JasperStarter command-line tool. This generates the PDF without any reporting service running in the background.
Ajit
I've used JasperStudio alongside Servoy (which is essentially a Java/Apache stack) to do this and it was the path of least resistance. Once it was up and going it has worked fine creating complicated invoice PDF files on demand from a database.
But as is the way with development nowadays it's adding at least one other third-party layer of dependencies into a toolkit that is already a mountain of third party dependencies, and you're multiplying the potential points of failure all the time. In this particular scenario you could update Java and the whole thing might collapse.
Happy Happy Joy Joy they say. Needing 3 server environments to dev, test as well as prod because one upgrade or update can screw things up. Been there and done that.
On Thu, Mar 8, 2018 at 10:15 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
I've used JasperStudio alongside Servoy (which is essentially a Java/Apache stack) to do this and it was the path of least resistance. Once it was up and going it has worked fine creating complicated invoice PDF files on demand from a database.
But as is the way with development nowadays it's adding at least one other third-party layer of dependencies into a toolkit that is already a mountain of third party dependencies, and you're multiplying the potential points of failure all the time. In this particular scenario you could update Java and the whole thing might collapse.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
I've checked it out, I can see your point, it's a beautiful tool, but too many dependencies and a long product chain. For simple database reports (that would be 98% of the time) I'll work with xlsxwriter and PollyReports which is close to the fox style but stays within python and keeps the design of your report and it's parameters within the language and will be easily portable. Regarding the remaining 2% if I can't dodge the bullet I'll probably end up doing what you suggest (thanks for the tips Ajit, hadn't heard about until you mentioned it)
Cheers
On 08/03/18 12:06, Ajit Abraham wrote:
Thanks Ricardo,
On 08/03/2018 01:39, Ricardo Araoz wrote:
You could also check "relatorio" and "pod" if you are willing to work with open office.
Gaetan's Appy Framework does exactly that. It works with odt documents. For simple reporting, it is ok. But for complex reports(which is easy in VFP), I found that had to do too much of tinkering. Also it needs Libreoffice to run in silent mode to generate the pdf.
check out PollyReports which is not a graphical tool but a python lib ....
Simply put, I have been spoilt by VFP. Hence hunting for the GUI
Ok. Seems that I will settle in for JasperReport. These are the steps:
- Prepare the data in XML format (Thanks to yattag library)
Along with the table data, I can pass adhoc values like the report title etc 2. Design the report through the free JasperStudio (same like VFP report design tool) 3. Generate PDF through Jadson Ribeiro's pyreport which is a wrapper for JasperStarter command-line tool. This generates the PDF without any reporting service running in the background.
Ajit
[excessive quoting removed by server]
-
Ajit Abraham -
Ajit Abraham -
Alan Bourke -
AndyHC -
Ed Leafe -
Jürgen Wondzinski -
Ricardo Araoz -
Stephen Russell -
Ted Roche -
Thierry Nivelet -
Wollenhaupt, Christof