Workflow for using toga-django app

[Michael Gallaspy]

Hi all,

Please forgive me if I'm not understanding something. I'm writing this email to seek clarification about how to proceed with the toga-django app[2]. FWIW I'm about to go to a football game so I'm a little rushed. I don't mean to suggest that this requires changes to toga itself, if it seems that way it's only because I don't have a firm grasp of that module yet.

I've begun to move the demo's files into this package, however some parts of it are a little unsatisfying because they're coupled to the demo. For example, the demo's template includes js/python bytecode sources directly[1]. This got me to thinking about what one would want out of such a backend at all. Seems to me that a developer would ideally want to:

1. Define a toga.App without regard to the backend.

2. Import the App for use on the desired platform -- in this case "Django" is the platform.

3. Subsequently specify any platform-specific options through inheritance or some "glue" code. For example with Django, specify the url of the app.

In the demo the Django-specific options that a user might wish to customize (like the template and url) belong to the base class of the App. Is this a deliberate choice? Or should these properties indeed be defined by the user?

Additionally I'm a little unclear as to the best way to *include* the app -- in the demo you create a template and then include the App's container object. Am I correct in thinking this is desirable? That it's good to leave some details of the site's layout up to a template file, so that the user may e.g. modify the appearance of the app's widgets with their own css?

In other words, it suggests the following workflow:

1. Define a class that extends toga.App that defines the layout abstractly, much as you've already done in the demo.

2. Create a view+template and register it to a url the usual way.

3. Provide the rendered App as a context variable so the user can appropriately place it.

Seem good? Or am I missing something?

Best,

Mike

[1] https://github.com/freakboy3742/toga_web_demo/blob/master/todo/templates/toga/window.html#L20

[2] https://github.com/pybee/toga-django

[Michael Gallaspy]

After poking around the code base a little bit more, I think I'm starting to get it. My confusion stems perhaps from a poor mental model of two of the main abstractions in toga, toga.App and toga.Window, and how they should be realized in toga-django. I may soon open a PR for the toga repo to flesh out the docs a little bit.

Secondly I propose that abstract implementations be created as a reference for the methods toga's classes need to implement. My strategy so far in trying to hack on toga-win32 has been to reference toga-cocoa, but it's inefficient since I'm unfamiliar with cocoa. Yet since "Toga attempts to abstract the broader concepts...of GUI apps" then perhaps the broader concepts should first be pinned down independent of an implementation for the most conceptually pleasing result. Is that reasonable?

With toga-django specifically I'm afraid I've only raised more questions for myself! I'm really intrigued by the possibility of creating web apps in "isomorphic Python" using Django. On the one hand toga_web_demo shows that this is possible, but on the other hand it seems to me that the example app fails to be x-platform in some ways. For example, it accesses a dom object directly, widgets are instantiated with values corresponding to the todo-list Django app, and the Toga.list.create_url method is used. This is fine of toga-django "only" aims to replace javascript in a web app. Yet I can't see how the aforementioned items could be interpreted using toga-win32 or toga-cocoa -- although it might be a failure of my imagination only! It also raises the question of how a toga.App should interact with Django's Models, if methods like "post" should not be used in an App to keep it x-platform.

So I'm wondering if it's the case that a toga.App should be able to run without modification using the various toga-<foo> backends? Or does toga (or toga-django) have a different aim (and if so what is it)?

Finally I don't want to seem like I'm only coming along with criticism! A OSX/Windows/Linux widget toolkit is really ambitious without including the web or mobile platforms. Including the latter IMO places it firmly in the "adventurous" category which is part of the appeal of hacking on this for me!

Best regards,

Mike