Announcement of GUI for Creating Models

[Timothy Clemans]

I've developed a GUI for creating models, see  https://github.com/timothyclemans/django-admin-models-editor

Would this be helpful for developers? Would it be useful for you? Should I keep developing it? What features would you like to see added?

[Alec Taylor]

Suggestion: go visual

E.g.: fork this - http://gaesql.appspot.com/

> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/AUCo4dXzbDEJ.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.

[graeme]

On Saturday, September 8, 2012 8:16:18 AM UTC+5:30, Alec Taylor wrote:

Suggestion: go visual

E.g.: fork this - http://gaesql.appspot.com/

This already seems to do that:

http://code.google.com/p/uml-to-django/

I have not tried it: I am put off by the way it splits models.py and admin.py, which is probably a necessary evil for a graphical model editor.

A graphical tool I have found useful runs the other way: the graph command from django-extensions generates UML from Django models.

 

On Sat, Sep 8, 2012 at 12:42 PM, Timothy Clemans
<timothy...@gmail.com> wrote:
> I've developed a GUI for creating models, see
> https://github.com/timothyclemans/django-admin-models-editor
>
> Would this be helpful for developers? Would it be useful for you? Should I
> keep developing it? What features would you like to see added?

Can it edit existing models as well as create new ones? If so some integration with South would be nice. It would make it a lot more useful: I spend much more time modifying models that creating them.

Also, looking at the code, it looks to me as though:

if not app.startswith('django'):

in admin_auto_register.autoregister

ought to be:

if not app.startswith('django.'):

if the intention is to exclude modules from django. There are other apps with names starting with django such as django_extensions.

Can you extend this to cover more of the field options? Dealing with things like "choices" looks like fair amount of work, but otherwise users will constantly be switching between GUI and text editor. The big negative for me with tools like this is that unless I can do most of the work on models within it, then it will not improve productivity.

[Joni Bekenstein]

This could be very useful for generating dynamic forms. You create the model and then just have some views that generate and process a ModelForm that uses the created model with this interface.

Also having a "simple" mode for the client who will actually use this would be helpful. For example, instead of enabling blank/null checkboxes, just add one "required" checkbox.

Just some ideas

[Javier Guerra Giraldez]

personally, i much prefer the reverse approach: i write the models,
and a tool (ie. django-extensions) generates a graphical
representation.

pros:
- the final models are exactly what i want them to be. even if the
graphical tool doesn't support some obscure Django feature, i can
still use it; it's just not shown graphically.

- i don't have to learn a different (graphical) language

- i keep fluent in the real Django language, so i don't have to
relearn it when for any reason i don't have to use that tool.

cons:
- less sexy than not writing code

--
Javier

[Kurtis Mullins]

You could take it a few steps farther and reproduce some work done by a doctor(now) I used to go to school with.

http://knoesis.wright.edu/research/srl/projects/mobicloud/

--
You received this message because you are subscribed to the Google Groups "Django users" group.

[TJ Max]

Thank you for the feedback.

I implemented the simple_mode suggestion. I'll use it personally so I
don't have to click two checkboxes.

I have simple ungrouped choices almost implemented. Unfortunately I'm
getting weird undefined errors in my javascript. Most other field
options are enabled now.

Once I get choices fully implemented I'll focus on being able to edit
models. I forgot about South. Having a GUI for it will be nice because
I was constantly getting errors I didn't understand.

I found the comment about having clients use this interesting. I would
be interested in making this easy for non-developers to use.

On Sat, Sep 8, 2012 at 3:05 PM, Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:
> On Sat, 8 Sep 2012 08:00:21 -0700 (PDT), Joni Bekenstein
> <jonibek...@gmail.com> declaimed the following in
> gmane.comp.python.django.user:

>
>> Also having a "simple" mode for the client who will actually use this would
>> be helpful. For example, instead of enabling blank/null checkboxes, just
>> add one "required" checkbox.
>>

> For a string field, having Null and Not Blank can be a meaningful
> difference (or the other way around, Not Null and Blank Allowed -- since
> this means the user has to explicitly set the field to blanks rather
> than passing an undefined/null)
> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

[Alec Taylor]

Kurtis: That looks very interesting; just finished reading it.

I wouldn't recommend this for Timothy though; it looks like something
which will require a large team to develop.

Maybe submit it as a project proposal to Canonical?

Or post on Django-Dev [and here] to see if you can get a large +
skilled enough team to build such a system.

[jondykeman]

Timothy - I am implementing something similar (Model GUI.png attached) that is within a larger structure that not only generates models.py, but registers them to the admin, builds the modelforms, and generates JS logic etc.

Rather than such a thing being useful for developers I have found it great to be able to use non-programmers to basically build the first 70% of apps I work on.

Also, fyi - Mezzanine comes with something similar (also attached), but more dynamic in the sense that the models are never actually written out - they are stored in a table, the forms are rendered off the table, and the information is saved FK to the field in a separate table.

Let me know if you want to discuss what we each have done a little more to see if we can learn anything from each other's experiences.

JD

[jondykeman]

Also, I saw on your github that you are looking for choices support. 

Just to give my insight I have implemented the attached for adding choices.

It is ajax via a modal that pre-populates existing options and allows for creation and deletion of options for that field on the fly.

JD 

[jondykeman]

....with attachment.

[TJ Max]

Jondy:

Is your code online?

Attached is screenshot of adding choices. After you add a choice in
your implementation, can you change its value and label?
Do/will you support most of the field and model options?

> To view this discussion on the web visit

> https://groups.google.com/d/msg/django-users/-/B_asYx8DCAUJ.

[jondykeman]

Nothing is up yet - we have just been using internally where I work. It came up because we were getting too much work and couldn't find the programmers. A model (and other things) GUI really helped with getting other staff to be able to effectively contribute to app development, and left us to the finer details and more custom features being requested.

It is super alpha and we just needed it working before working well - there is no editing because it was just as fast to add the value/label you were going to change to and click the delete on the pre-existing one.

That being said - now planning on converting to formsets with ajax, which will allow the editing of all at once. 

Do you have a way of setting which fields will be associated with which of the models? I am moving onto this aspect next and was thinking of maybe doing draggable divs in a list to make it more interactive.

Currently the app supports: BigIntegerField, PositiveIntegerField, DecimalField, BooleanField, RadioButton, CharField, TextField, DateField, TimeField, DateTimeField, EmailField. 

We use javascript to control the display of appropriate additional information fields (eg. max_length) when creating variables in the form, which is backed up by a bunch of custom validation in the modelform.

JD

[TJ Max]

If you could open source it I would appreciate it.

> Do you have a way of setting which fields will be associated with which of
> the models? I am moving onto this aspect next and was thinking of maybe
> doing draggable divs in a list to make it more interactive.

I don't understand this. Could you give examples?

[jondykeman]

It might only come up in the context of my work, but we do a lot of data collection, and so when using the GUI all of the variables we create as destined to be part a of specific modelform. As such, we way want to end up with two forms (eg. Baseline, Purchase History) each of which will be represented in a model. We create all of the fields, and the next step is to assign which fields should go with each form ie. what models will the new fields live under, what order should they be rendered in, and what is the logic within forms. 

JD