search

icook / yota

Flexible Python web forms with asynchronous validation
Other
33 stars 3 forks source link

Split Form into an abstract and specific class #75

Open icook opened 11 years ago

icook commented 11 years ago

Create a BaseForm class that provides abstract functionality, then have the more specific Form class inherit the base functionality.

prologic commented 11 years ago

Couldn't think of a better place to discuss this and didn't want to waste opening up another issue. (This issue seems close enough).

Basically I'm in a position where I want to use yota for generating and validating user input for my web application however I have the following concerns:

How to deal with data storage.

Basically It would be really nice if we could separate out the DATA from the UI (Form Generation) and Validation so that these three things are handled separately in a decoupled manner.

One thought I had was to perhaps have a way to derive form generation from JSONSchema where it can be used for both storing data and validating it.

In short I don't really want to be mixing Form code with backend Data storage code.

Then I also have situations where I can't use yota for form generation anyway (e.g: things that aren't rendered necessarily as a form or you want finer grained control over how it's rendered/displayed).

Thoughts?

icook commented 11 years ago

This is an interesting point, and definitely an oversight in original design. I'll give it some thought on a clever way to introduce this and try to get back to you. My first thought is changing the way a "Check" is resolved potentially, allowing you to swap out the data sources easily. There are a couple ways to attack this, but I'd rather not break a bunch of compatibility if possible.

Thanks for the thoughts.

prologic commented 11 years ago

My thoughts were to derive the form the attributes from a JSON Schema.

Dynamically instantiating the "Form" and "Node" instnaces.

This would not break anything IHMO.

cheers James

James Mills / prologic

E: prologic@shortcircuit.net.au W: prologic.shortcircuit.net.au

On Sat, Sep 7, 2013 at 5:32 AM, Isaac Cook notifications@github.com wrote:

This is an interesting point, and definitely an oversight in original design. I'll give it some thought on a clever way to introduce this and try to get back to you. My first thought is changing the way a "Check" is resolved potentially, allowing you to swap out the data sources easily. There are a couple ways to attack this, but I'd rather not break a bunch of compatibility if possible.

Thanks for the thoughts.

— Reply to this email directly or view it on GitHubhttps://github.com/icook/yota/issues/75#issuecomment-23963797 .

icook commented 11 years ago

I'm not sure I understand. Are you thinking to have a client side JSON schema? Certainly we could make something to dynamically create a form, but wouldn't the validators still be statically defined server side? So the schema would still have to match the validation requirements to be useful, unless I'm not understanding.

prologic commented 11 years ago

JSONSchema (and their Python and JavaScript libraries) allow for both server and client side validation. (really making large parts of yota redundant)

What I was suggesting however as an experiment was to write a function that translate a JSONSchema into yota forms.

cheers James

James Mills / prologic

E: prologic@shortcircuit.net.au W: prologic.shortcircuit.net.au

On Sun, Sep 8, 2013 at 5:50 AM, Isaac Cook notifications@github.com wrote:

I'm not sure I understand. Are you thinking to have a client side JSON schema? Certainly we could make something to dynamically create a form, but wouldn't the validators still be statically defined server side? So the schema would still have to match the validation requirements to be useful, unless I'm not understanding.

— Reply to this email directly or view it on GitHubhttps://github.com/icook/yota/issues/75#issuecomment-24008380 .

icook commented 11 years ago

Interesting, I haven't worked with that library before so I'll look into it. I created #80 for further discussion along this vein since this issue is fairly separate.

prologic commented 10 years ago

@icook Have you made any progress on this issue or thought more about it? I'm planning on using your yota library in a real production quality project and just wondering if we can get some momentum on this issue... IIRC basically my issue is trying to add functionality to yota such that the widgets are automagically created via a JSON Schema and then also validated based on that schema. (i.e: no python code to write).

icook commented 10 years ago

@therealprologic Unfortunately this project is now mostly EOL as far as my development time goes. My needs for this kind of package are mostly being fulfilled by Angular at the moment, and I've just got my hands too full at the moment. I apologize for not updating the documentation accordingly. I will try to do this later today so it is more obvious.

prologic commented 10 years ago

No problems. Shame :) I quite like what you were developing. Perhaps I'll take it on?

James Mills / prologic

E: prologic@shortcircuit.net.au W: prologic.shortcircuit.net.au

On Sat, Mar 29, 2014 at 3:30 AM, Isaac Cook notifications@github.comwrote:

@therealprologic https://github.com/therealprologic Unfortunately this project is now mostly EOL as far as my development time goes. My needs for this kind of package are mostly being fulfilled by Angular at the moment, and I've just got my hands too full at the moment. I apologize for not updating the documentation accordingly. I will try to do this later today so it is more obvious.

— Reply to this email directly or view it on GitHubhttps://github.com/icook/yota/issues/75#issuecomment-38946070 .