Form control discussion

[mikaelho]

I have been thinking about UIs for Python for a while, and one of the related topics was making data entry and validation easy by generating a form from the data definition contained in a Python class annotations. I see this idea shared in how the Grid control uses the item class's attributes.

My earlier thinking was mainly driven from the realisation that there is a lot of overlap between the validation needed and the capabilities of one of the most popular Python packages, pydantic.

Thus I created a Form control that does this, see the online demo/manual for details. It does not create a mandatory dependency with pydantic or anything else, but does know how to utilise pydantic capabilities when available.

Before I move forward from this alpha stage in terms of tests, Python versions etc., it would be nice to understand if there could or should be a deeper integration with the pglet-python package, for example in terms of aligning with the Grid control etc., or even becoming part of the package.

[FeodorFitsner]

The demo/help app looks amazing! I've forked it and looking into it right now - that's a lot of code! :) I will also make sure it works with the latest Pglet/Pglet-Python which are almost released.

[FeodorFitsner]

The update.

Your demo app works just fine with the latest Pglet 0.5.7 Python library.

The only thing I changed was the way a new instance of FormDemoApp created on session start as the state was passing around between sessions: https://replit.com/@pglet/pglet-form#main.py

To fully isolate the state between sessions:

• page is passing to FormDemoApp's constructor, main method merged with constructor.
• app is initialized as pglet.app("index", target=FormDemoApp).

The form component looks really awesome and I'm still studying Pydantic lib...

[mikaelho]

Thank you for taking a look and fixing the state management! Hopefully this is a fix for some intermittent flaky behaviour I have seen.

pydantic is very nice, but not a trivial package, so I deliberately implemented the Form control in a way that pydantic is not a fixed package requirement.

Regarding the session change and update to 0.5.7:

Adding the local=True, things work as normal in local, but on replit I just get:
Waiting for new app sessions. Press Enter to exit...

Same if I remove the local=True. Is it obvious to you if this is a pglet feature, or replit being flaky?

[FeodorFitsner]

Yep, Waiting for new app sessions. Press Enter to exit... is coming from Pglet meaning it's running and waiting for a new sessions to serve. I'm open to any suggestions here to make it more clear what's going on (different messaging, displaying page URL, displaying new session ID, etc.).

[mikaelho]

Sorry, minor miscommunication there. The text is fine, my issue was that the page itself did not load, just saying that the application was not running or similar on the page. And as this coincided with me seeing the message on the console for the first time, it looked to me like an indication of some kind of error.

But, loading the page again today it worked fine, so it might have been some kind of update/restart glitch.

Oh, and I see a new primary theme color, nice.

[FeodorFitsner]

Replit could be glitchy sometimes, indeed.

[FeodorFitsner]

I've been thinking more about "components", i.e. something language-specific and made of atomic "controls" which are part of Pglet. So, your work would be called "Form component". I started working on "PagedGrid" Python component which is a combination of Grid, Stack and Button controls and though what if start a new repo for components and join our efforts there? It could be named pglet-python-components (or anything like -extra, -extensions or -contrib - I'm open to suggestions) and contain Form and PagedGrid components for the start. This way pglet-python-components will depend on pglet-python controls which depends on pglet. What do you think?

[mikaelho]

Hey, sounds perfect! All your name options are good, but shorter is always better for me, and if I really think about it, "components" most likely still inherit from Control, so I am not 100% if it makes sense from a developer point of view to differentiate between them. "extra" seems to fit these thoughts best. So, we could have repo called pglet-python-extra, and the contents would still be called controls (if they act like Controls, sure there could be other types of extras as well), and would install in the same pip install pglet package. Or if that is not feasible, with pip install pglet[extra]. ... which leads me to think that maybe the simplest would be to have an "extra" folder in the pglet-python repo for this purpose. The controls there could be namespaced so that they can be imported just from pglet, or from pglet.extra if you want to make the distinction clear. Just random thoughts, I am up for this regardless of names of repos and pip installs! Thanks, Mikael

…

On Tue, Jan 11, 2022 at 11:20 PM Feodor Fitsner ***@***.***> wrote: I've been thinking more about "components", i.e. something language-specific and made of atomic "controls" which are part of Pglet. So, your work would be called "Form component". I started working on "PagedGrid" Python component which is a combination of Grid, Stack and Button controls and though what if start a new repo for components and join our efforts there? It could be named pglet-python-components (or anything like -extra, -extensions or -contrib - I'm open to suggestions) and contain Form and PagedGrid components for the start. This way pglet-python-components will depend on pglet-python controls which depends on pglet. What do you think? — Reply to this email directly, view it on GitHub <#49 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHQO37WBHZJZM44PMAODQDUVSNKFANCNFSM5K3VMEKQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>