What else does py4web need?

[Massimo]

What else does py4web need?

How can we make it better?

How can we make it simpler and more use friendly?

What is poorly documented?

[Nico Zanferrari]

Hi,

I think that the Dashboard should be improved, It's the first and main user interface to the framework, but IMHO it lacks a good visual appeal. The feeling I always got is to use a non-professional product ;-( 

Also, it should support multi-users authentications and roles (which is mandatory in the Enterprises). Possibly also add the ability to start/stop single apps and to check/manage scheduled tasks (new).

Nico

--
You received this message because you are subscribed to the Google Groups "py4web" group.
To unsubscribe from this group and stop receiving emails from it, send an email to py4web+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/py4web/69ccb18b-17f9-4f17-b312-0b49e4d0c3d7n%40googlegroups.com.

[Nazywam się Witek]

(for me)
utils/grid.py - no callbacks when creating a grid.
I can use workarounds (~monkey pathing), but this is a maintenance problem.

The migrated application (web2py) is very large (~200 tables) and has very compressed views (100-300-500 rows, +pagination), with various html tricks.

e.g. (a light, imprecise proposition)

utils/grid.py

def _make_table_body(self)

...

  row_callback = self.formatters.get(key+"__callback")

  if callable(row_callback):
      tr = grid_row_callback(self,row,tr)  # f(grid,row,TR)
      if not tr:
              continue

or

  row_extra = self.formatters.get(key+"__extra")  # => tablename__row__extra  <= dict(callback:...., row_id_name="mycustomtable", row_class="selected" [ops ;)],  [eg. other] th_class="right", td_class="right" (for TD with number)

  if row_extra.get('callback'):

     ...

def row_tr_callback(grid,row,tr):

    # for javascript helpers

    tr['_id'] = row_extra.get("row_id_name", grid.tablename) + "_row_" + str(row['"id"])

    tr['_onclick'] = "javascript: window.un_select_and_remember_for_return()

    return tr

 

Same for TBODY, TD (!), DIV/grid_wrapper (?),...

utils/form.py

Is it possible to control the order of fields in the form (like the order in grid?). I have one model and I want to display it in a different order sometimes.

Thanks

[icodk]

+1

[Ali]

I have two comments about forms:

1- RadioWidget: The items in the RadioWidget appear horizontally, by default. In most real-world scenarios, they should appear vertically.

2- When it comes to advanced topics, I think Custom Forms (where fields can be dealt with independently) is the most useful feature and thus should appear as the first advanced topic presented in the documentation. Currently, the Custom Widget section is the first presented topic which, in my opinion, is a little scary (given the amount of code the user needs to write on their own) and most readers would not go past that.

Of course, these are my personal opinions and any decision should be made based on the collective feedback received.

- ali

[icodk]

I could use a call to a user defined functions from the auth system just before both  a successful log in was completed or failed(ex. on_login() and on_login_failed() ).

The successful login function, if defined by the user  will return True   for completing the login  process or False to abort the login process.

The on_failed will return None.

[André Kablukow]

In fact, I believe that two things that existed in web2py and are not the same in py4web make the process much more tiring and needs a lot more coding.

1) The "fields" property inside the Form
2) The possibility of changing form.vars within "form.validate"

Nowadays, most of the things we do with forms recording in databases, there are always details, flags, calculations to do together. I understood that it was done in a very simple way, and I understood that if you change dbio=False we can deal with it in the accept function, but for me the Form function was made to make forms writing to db easier, and the way it was done, the write to the database automatically was not easy or good to use, in most of time If I made a single line of code in validate function, it would improve my code and make it much more simple.

Other thing I want to say is that the db admin in the web2py was very much better to read, understand and use.

But this is just my opinion. I am not here to complain about anything, I just have to thank you because I've been using the tools since web2py, building ERP systems and a lot of web tools, and I'm very grateful for py4web too now that I am starting to use it. So thank you guys!

[Hadi Zarkoob]

Here is a minor suggestion regarding the dashboard: One of the main use cases is to review recently submitted items. To achieve this, we need to do two things:

1- Reverse the order of the 'id' column.
2- Refresh the page whenever a new row is submitted to the table under review.

However, refreshing the page always resets the column ordering because there is no reference to the sorting in the URL. I think it would be helpful to maintain the column sorting when a page is refreshed, which probably means the column by which the table is sorted should appear in the URL. To completely reset, the user can always return to the main dashboard page and reopen the table, or they can manually sort the 'id' column, which is the default sorting column for the table.

Thanks!

[Luca de Alfaro]

One thing that could help is layouts.html that work with google login (or delegated login in general). 

I always end up redoing them; I could "donate" one, but the question is where to put them.  A layout repository would be a good thing, separate from the core of py4web, where people could contribute layouts for various CSS frameworks, login methods, etc. 

Luca

--

[Carlos A]

+1

[Rahul Arun Dhakate]

Hello Massimo, Everyone , 

     I am a BIG fan of web2py which I have been using since last many years and I still use with python 3.12 and it works pretty good. I upgraded all my projects to support python3. But I am new to py4web and as a new user I have the following things I would be looking out for my next big project, if I do not  want to switch frameworks bandwagon i.e. 

 1- The ability to support frontend frameworks like React, Angular or Vue out of the box. Or atleast the barebone hooks provided to use them. As a matter of fact, we also have Reactpy now but in a nascent stage. These will provide professional quality Frontend UI support for people who are looking to integrate them with python. The simpler we provide the implementation the stronger the use case would be. As an example:  I could not integrate Bulma in my previous web2py project because it did not play well with the built in calendar widget ( although rest was all working good) and I had to abandon it. I know this might be a lot to ask for :( but this is what the industry demands today. Note, no other framework provides this built in support yet. Although, there are ways to support it.

2- I couldn’t find comparisons or benchmarks of this framework to other frameworks. This would definitely be helpful for someone who plans to utilize this framework professionally. Parameters I think useful could be real world use cases, speed (compared to FastAPI the leader and Django the grand daddy) , What can we build with it. APIs…Memory footprint, concurrency ? Etc I could put one on my blog here www.learnxyz.in if someone could provide these details. 

3- I am not a fan of the dashboard that we currently have it feels like Ironmans UI (pun intended) . I hope it gets a pro facelift which is more appealing to professional developers . Serious users might prefer it over the current one.

With all that said - 

Basically, we want that kick in the framework that people will always consider it while they plan to use any python framework for their next “Big” project. This post is a bit long, sorry about that. These are a few points that I have. If you think anypoint qualifies the question you put, I.ll be glad. Thanks a ton!

Cheers, 

Rahul Dhakate

[Patrick Dardar]

The official documentation could use more explanations about all the available attributes and functions of fixtures or DAL constructors. It shouldn't be necessary to parse the py4web source code to find that information.

I think the documentation also considers the user to already be knowledgable about web2py. I'm a complete newcomer to py4web and have started putting my database definitions at the start of my files. I was now searching for a way to put them into a single file that could be loaded/included in the different files when I stumbled on something called "models.py". I could not find an explanation about this file in the documentation apart from that it's possible to not use (model-less apps) but no info how it's really used. Is that file automatically loaded when it exists or do I have to mention it somewhere?

[Luca de Alfaro]

I have starting apps for vue3 and Bulma -- it would nice to have such a repository / list of starting apps.

It takes a bit of time to do an app that uses vue3, bulma, has a decent layout. 

If we had a repository of such starting apps for various CSS / JS / login frameworks, it would make app development easier. 

Luca

To view this discussion on the web visit https://groups.google.com/d/msgid/py4web/83661b77-2362-45d7-bcc1-4189fe502bb1n%40googlegroups.com.

[CarlosDB]

Thinking about migrating applications from web2py, it would be great to add the "Selectable" functionality that web2py has in SQLFORM.grid.
http://web2py.com/books/default/search/29?search=selectable

[Jim Steil]

@luca

I have a _scaffold_bulma that I was using but haven't updated it in a while. I'd need to update it to work with the latest _scaffold app. I think the only things I modified were templates/layout.html and templates/auth.html.

It would be nice to have a repo with all of these options, but we'd also then need a way to keep track of which releases of py4web these worked with. Anytime something changes in layout.html or auth.html, my _scaffold_bulma should have been updated.  Any ideas on how we could protect against this?

https://github.com/jpsteil/_scaffold_bulma

-Jim

[Hadi Zarkoob]

I agree with Rahul that benchmarking can be very helpful. Measures to assess should include simplicity, robustness, and speed.

And another independent point. The following is likely a (small) bug:

https://github.com/web2py/py4web/issues/810

[Nazywam się Witek]

+1 CarlosDB - "selectable"

  A member of my team stopped looking at the project as soon as he realized there was no "Selectable" option. (~2022/2023 y.)

2/ Too much use of _style. e.g. Form -> div(class=field) ->  span(class=control) -> LABEL (and on the right side :( ? )

 element.style {

1. display: inline !important;

[AvE]

  I was using this a lot in web2py :   "Selectable" functionality that web2py has in SQLFORM.grid 

Op dinsdag 4 juni 2024 om 23:20:04 UTC+2 schreef CarlosDB:

[Massimo DiPierro]

lots a good advice here. will try address some of them this weekend before responding in more detail.

To view this discussion on the web visit https://groups.google.com/d/msgid/py4web/1e8fcee7-b3a7-4c4b-9e56-5c6838ed3fa1n%40googlegroups.com.

[Ali]

People have talked about enhancing the documentation. I have a few specific suggestions in this regard.

General. I suggest providing a quick demo example at the very beginning, perhaps in chapter 1, highlighting how simple and to-the-point py4web is compared to other web development frameworks.

Chapter 1. 

a. It is well-written and makes a strong case for using py4web.

Chapter 2. 

a. The points regarding "debugging" may be confusing. The reader may think to themselves, I have not even started coding and they are talking about "debugging" tools.

My understanding is that the main goal of the debugging sections is not to debug any code yet. They are mostly about configuring VS Code or PyCharm to be able to start py4web with just a single click. I think the documentation should be clear about what the goal is for users who may not have a strong programming background and in particular, the use of IDEs. Of note, making web development accessible to a large audience is one of the key goals of py4web.

b. The section regarding setting up debugging for PyCharm seems incomplete.

c. The use of the adjective "daunting" in the first paragraph may not be appropriate. It may repel some users. After all, py4web does a great job of simplifying web development for a large audience.

Chapter 3. 

a. I think presenting numerous installation variants will confuse first-time users. Maybe this chapter can be broken into two sections. Quick and In-depth instructions. The quick section can be further broken down into the following subsections:

- Treating py4web like any other library installed by pip (A quick note can indicate if you use a virtual environment, do not use the --user argument). The commands in this case start with py4web (e.g., py4web set password)

- A git clone. In this approach, py4web will be treated like a piece of python code. The commands in this case start with python (e.g., python3 py4web.py set password). As with any other python programs, it is highly advisable to create and use a virtual environment. Also, needless to say in addition to cloning the py4web repo, the requirements need to be installed using python3 -m pip install  --upgrade -r requirements.txt. 

The in-depth section can include the current content of the chapter.

Thanks,

- ali

[Patrick Dardar]

I think the database editor could be enhanced. At the moment it shows you the fields and the records but it could be interesting to show a table's fields' meta data, like default values (what has been set in the table definition).

[Stéphane Krikorian]

Hi Massimo and all.

Py4web is really great. I measure the considerable amount of work it
concentrates already.

A feature I would love is the ability to auto generate Open API docs (
aka swagger formerly) and mocking features as Fastapi framework does
natively.

Regards
Stephane.

[Rahul Dhakate]

Just a simple follow-up to the question - What might be the changes we would be seeing "picked-up" from suggestions shared in  this thread 

[Massimo DiPierro]

I am considering picking up most of them but I will not have time for another week. I will respond asap

To view this discussion on the web visit https://groups.google.com/d/msgid/py4web/5c9556bd-4189-4c2b-9455-5b778512a769n%40googlegroups.com.

[Nazywam się Witek]

proposal / request

 To add ~ grid.param.defaultform=Form   (in Grid.__init__ )

and in

  grid.process()

    #self.form = Form(

    self.form = self.param.defaultform(
                table,
                record=record,
                .....

Sorry if I'm being bothersome.

I'm trying to convince team members to switch from Web2Py (2.14/py2.7! ,intranet) to Py4Web (lots of good work!).

The view ends with layout.html + {{=form}} :) - that's all - I don't count on mastering a custom form.

To do this I want to create a slightly modified Grid and Form (I'm finishing - the experimental version - ugly code ;)).

I want to stick to the code of the original Py4Web project as much as possible.

That's why I wrote about several ideas, including: callbacks, headers, "selectable"(from the box).

Several overridden (not too big) methods in Grid, Form, Form Factory, etc.

The hard-coded =Form() in Grid worries me the most - a lot of code to update (with new changes in Py4Web).

TL;DR :)

What I changed, e.g.:

class MyForm(Form):
    def _read_vars_from_record(self, table):
        row_data = { name: self.record[name] for name in table.fields .... # => FormStyleFactory=> field.represent(..,vars,)
        formatted_values = { ...table[name].formatter(self.record[name]... }
        formatted_values['__row_data'] = row_data
....
class MyGrid(Grid):
    def __init__(
        ,form_name=None,

        ,selectable=None,     (in ~Web2Py style I generate them in init (on Columns() + JS) and insert it into columns[] )

        ,helpersdict=  # { describes labels, headers, field callbacks, top/bottom footer position, many other dynamic settings for a specific controller (one model, multiple views in the application) }

     ):

     ...

     super().__init__(......)

  def post_process(self): # additional - corrects a few things after the factory .process()

  def _make_table_body(self):

  def _make_table_header(self):

  def render(self, cache=False):

....

grid = MyGrid( ,auto_process=False, )

grid.param.defaultform = MyForm
grid.process()

grid.post_process()

Thank you all

[Jim Steil]

@nazywam - I'm confused by what you're trying to accomplish / avoid here.  Do you have a small example app you could post?  To me, I can create a custom default form pretty easily with what py4web already provides.  I'm interested in seeing the challenges you're trying to overcome.

-Jim

[Nazywam się Witek]

I don't have an application to show (I'll do it when I finish) - I do everything hot - standard - I don't have time.

I'm trying to request some code changes (minor). It will be easier for me to create my own optimization.

I also changed Web2Py a bit (for the same reasons).

Please don't take this as criticism! (and these are not claims either).

I'm happy that Py4Web exists (as well as Web2Py). These are simply my problems and an example of non-standard implementation.

The application must run as fast as possible. Lots of big, dense tables and lots of extra action buttons. in table cells - large tables in titles, colored rows, colored cells, texts,...

e.g. buttons placed in the upper left corner are "faster" than the button below the rulers (I move the "footer" up).

Grid cells have large tables of data in their titles.

e.g. A table with 200 rows that needs to be processed row by row - by going into details/editing and going back to the main table - reloading - there must be a mechanism for moving the screen to the last position - instead of scrolling and looking for the next row.

I also miss marking the line with a color - e.g. we take a screenshot and send it to someone else - you have to use the image editor and mark which line you mean (time! 100x several seconds).

There are also no fixed (css glued) table headers, this exceeds expectations, but I add it right away in the controller (grid.fixed_headers="77vh") - we almost have no tables without scrolling.

And a few other changes, but maybe that's enough for today (I'm writing at 2 a.m.).

I did most of this in Web2Py, but I often had to make ugly, complicated workarounds.

Py4Web is still undergoing some changes - I'm trying to show that with a few simple changes it can be more powerful.

I've already made a few mistakes - only after analyzing the code I discovered that some things can be done without revolution.

e.g.

  Initially I didn't analyze why "=grid.render()".

  I left for later what "Columns.required_fields" does

  I didn't find the answer in the documentation.

  But who doesn't make mistakes?

[Massimo]

This was a long thread and I had a very long few weeks :-)

I have been going through the suggestions. So far I have implemented some:

[x] Grid(...., Form=CustomForm) or Grid.Form=CustomForm to replace Form with CustomForm

[x] changed the layout of RadioWidget (still horizontal) but you can do <style>form div div label { display: block}</style> for vertical

[x] form = Form(..., validation=lambda form: form.vars.update(key=value)) to change form.vars in validation

[x] Form(show_id=False) # nobody asked for this but I think this default is cleaner

Also auth already has callbacks like web2py:

auth.on_accept["login"] = lambda form, user: print("user {first_name} login".format(**user))

Grid does not have callbacks but I am not convinced this is necessary if you can customize grid.Form=CustomForm. Agree?

About the dashboard sorting. It already works so if you click on [id] it will reverse display latest first. What am I missing?

I am going to think some more about the best way to do selectable in grid. Definitively possible. I also think it needs better search options leveraging the text to query builder already used by the dashboard.

Yes. need to reverse order in docs and move complex stuff later. Lots of stuff is missing from docs. I am keeping notes and will what is missing.

Dashboard could look better but I like it minimalist. There could be more than one. Feel free to propose one. I do not think the dashboard should allow multiple users. It would created more problems than it solves. It is meant as a local developer tool and as a last resort tool when deployed. If multiple users were to use the dashboard to edit files, databases, and reload apps in production they would just step on each other and break things badly.

I think we should have a separate repository for examples apps and example FormStyles/layout.html/auth.html for different CSS frameworks (Bulma, Tailwind, Bootstrap, Material Design, Foundation). I will create the repo and move there way I have. Will need help to add content.

Missing anything major?

[Massimo]

Actually I changed the syntax of grid.Form into grid.form_maker. You can do

    def myform(*args,**kwargs):
        form = Form(*args, **kwargs)
        if form.accepted:
            print("form accepted")
        elif form.errors:
            print("form as errors")
        else:
            print("new form")
        return form

    grid = Grid(path, db.thing, form_maker = myform)

BUT 

you could already do:

    grid = Grid(path, db.thing, form_maker = myform)

    if grid.form and grid.form.accepted:

         print("record updated" if grid.form.record else "record created")

this is why I do not think you need callbacks.                

[Massimo DiPierro]

about sorting fields in forms. why is it not enough to sort them in models? what is the use case for  different forms with the same fields but in different order?

To view this discussion on the web visit https://groups.google.com/d/msgid/py4web/b41abe9c-605a-4915-8137-19d04d0d2159n%40googlegroups.com.

[Nazywam się Witek]

This is a bit of a stretch, but to simplify the situations we encounter.

When I have an image, I want it to be displayed (/detail) at the top of the screen - first, e.g., a full-screen graph.

When I edit, I fill in the description fields first, and I'm temporarily less interested in the image - I have to scroll the screen.

Such situations happen (in my case) often - it's about service time - the most important things - the first to change.

I don't want to insist on this. I'll just do it myself - I correct the team's code too often - I imagine myself in the user's shoes and I know it would irritate me.

Change is not difficult, but it destroys the concept - I guess.
Grid -> form(Table new/edition))->FormStyleFactory(/details) - for FormStyle there can be a class pretending to be a table (that's what I did).
Complexities in passing .orderby from Grid to FormStyle.

The problem I'm struggling with is not Py4Web, but the reluctance to nicely style views in the team. I'm trying to play it in controllers - where there is some focus.

Also shifting the graphical part to the user's decision - easily controlled in the controller - e.g. whether he wants to have "selectable" buttons at the top of the screen ~if auth_user.settings.footer ..

Creating a view by a programmer is always burdened with his vision of how the application should work. If the programmer does not pay attention to the fact that the added new (important) fields in the database (at the end of the table) appear in the same way in the model and the view - a bad aura begins.

There are many users and a common view. Some people are not interested in arranging the columns as they are. They monitor other parameters and are completely dissatisfied with this view.

I'm trying to give them an additional choice of which columns they want to see first.

It's hard to imagine it until we encounter an application monitoring 20-30 integrations. When you have to process 200 rows in 1 hour. It breaks my heart when women ask me to make things better and I don't have time.

Just like you - Massimo and the team, one of the best frameworks for quick programming (we can implement changes in the application not in weeks or days, but in hours!). I didn't choose Web2Py - it was forced upon me - and I became a fan.

I need to recreate Web2Py functionality in Py4Web - they were heavily used. "Selectable", Advanced_search (Jim - thank you), "LOAD()" modal windows (me), and "a lot" of JavaScript.

I wasn't going to mention it, but - in my opinion - there is a lack of explanation of the concept of action. We have an example, but we don't know how to use it. FastAPI is probably a documentary masterpiece - I think it's a documentation of "life" - writing something like this is an incredible effort.

M.

[Massimo]

I responded about selectable in a different thread since this one is getting very long. :-)

About LOAD(), in py4web we have <ajax-component ...> buried at the bottom of chapter 16. You could define 

from yatl.helpers import TAG

def LOAD(id, url): return TAG["ajax-component"]("loading..", _id=id, _url=url)

and it would work pretty much the same as the web2py one. Yet given that is a pure JS thing, you should probably be using HTMX instead which is a more feature rich implementation of the same idea.

[AvE]

what about grid.structure  ?  

is it possible to get similar .structure like Form has?

Op maandag 3 juni 2024 om 00:07:53 UTC+2 schreef Massimo:

[AvE]

To answer myself:   grid.render()  gives the searchable structure.   

so I can do:  

gridstructure =  grid.render()

gridstructure.find(".myclass")  etc, 

Op woensdag 19 juni 2024 om 15:00:33 UTC+2 schreef AvE:

[Krzysztof Socha]

Hi Massimo - a bit late to the party, but kind of got stuck with it today... 

So I am planning to use mostly Bulma for the styling, and currently while py4web supports Bulma already, there is an significant issue with generating horizontal forms. Let me explain. Currently the form generated by py4web with formstyle=FormStyleBulma looks a bit like that:

<div class="field">

<label class="label">Name</label>

<div class="control">

<input class="input" type="text" placeholder="Text input">

</div>

</div>

(not even sure if the  <div class="control"> is there)

However, many of the forms I need, should have the horizontal layout - where the labels are in fact in the same line as fields. Bulma allows that, but the structure should be different then (https://bulma.io/documentation/form/general/#:~:text=of%20buttons.-,Horizontal%20form,-%23):

<div class="field is-horizontal">

<div class="field-label is-normal">

<label class="label">Name</label>

</div>

<div class="field-body">

<div class="field">

<div class="control">

<input class="input" type="text" placeholder="Text input">

</div>

</div>

</div>

</div>

I looked at custom forms chapter, but honestly I have not figured out how to make it happen. I can probably do some magic patches using some addtional CSS, but it feels pretty ugly. It would be absolutely great, if py4web supported also Bulma horizontal forms out-of-the-box :)

[Jim Steil]

Do you have a sample of what you're trying to accomplish?

Or better yet, make a small app with a sample table and share it here or on github - we could work through it and get what you need.

I've done quite a bit with py4web and bulma, but don't think I have a horizontal form example to share yet.

-Jim

[icodk]

Just an idea:

Instead of horizontal form, you migh get a way using Bulma's columns

In any case you will need  to use : 

[[=form.custom.begin ]] [[=form.custom.submit ]] [[=form.custom.end ]](which you probably trying to avoid:-)

[Jim Steil]

I am familiar with the horizontal forms, I'm trying to get a feel for how complex you need your form layout to be.

Do you have a sample? Even a hand drawn pic of what you're trying to accomplish would help me understand better. Then we could put together a simple little app to show how to do it.

-Jim

[Jorge Salvat]

Hi, if you're using Grid, this template will render horizontal forms

you can customize style, and/or adjust for Form usage.

[[if grid.action == 'select':]]
    [[=grid.render() ]]
    <button class="button is-default" onclick="window.history.back(); return false;">Volver</button> &nbsp; [[=mi_sidecar]]
[[else:]]
    [[form = grid.render() ]]
    [[=form.custom.begin]]
    <table class="table is-bordered is-fullwidth">
        [[for field in form.custom['labels']: ]]
            <tr>
                <td>
                    <label for="[[=grid.tablename]]_[[=field]]" class="label details-label" title="[[=form.custom['comments'][field] ]]">
                        [[=form.custom['labels'][field] ]]
                    </label>
                </td>
                <td>
                    [[if form.custom.widgets[field].name == 'select': ]]
                        <div class="select">
                            [[=form.custom.widgets[field] ]]
                        </div>
                    [[else:]]
                        [[=form.custom.widgets[field] ]]
                    [[pass]]
                    [[if field in form.custom['errors']: ]]
                        <p class="py4web-validation-error">[[=form.custom['errors'][field] ]]</p>
                    [[pass]]
                </td>
            </tr>
        [[pass]]
        [[if grid.action == 'edit' and grid.is_deletable:]]
        <tr>
            <td colspan="2">
                <div class="field"><span class="control" ><input class="checkbox" name="_delete"
                    type="checkbox" value="ON" /></span>
                    <p class="help" style="display: inline"> &nbsp; marcar para suprimir</p>
                </div>
            </td>
        </tr>
        [[pass]]
    </table>
    [[=form.custom.submit]] [[=SPAN(*form.param.sidecar)]]
    [[=form.custom.end]]
[[pass]]

[Krzysztof Socha]

Thanks a lot guys! @jim - thanks for the offer - I will potentially try to find a bit of time to spell it out a bit, if needed. However, the template example provided by @jorge seems like an excellent inspiration (no - I am not using Grid at this stage - just a form) - I should be able to build something based on that. I will keep you informed, and if necessary share more details for potential future hints. Thank you guys for the support again!

[Leonardo]

Please make py4web app compilation feature. I.e generation of .pyc files.

Make them impossible to decompile. Great work buy also please design web2py to py4web migration tool. So that auto code is generate ready to deploy in this platform, it's pain in ass to convert all codes of live projects. Clients don't pay for tech migration, that will make us to loose clients in long term. That will make py4web less developers choice