#django

totte: you are passing 4 arguments to list(), but it only wants one.

totte: it's uncommon to create a list like that. do this instead: result_list = [a_count, b_count, ...]

Ohh right, thanks... Not sure where I got that from...

totte: also, context_object_name = 'list' is not such a good idea. avoid using the names of builtins as variable names.

Okey, thanks, I'm back on the track now! :)

Can somebody point me at what I need to be reading, as a brand new user of Django, to assemble a "simple" application to fit my transaction model from above?

Should the context_object_name and the value I return have the same name?

bdmc: hey, django's websyte has a comprehensive and linear tutorial for begginers

bdmc: you can get almost everything there

I have gone through the polls tutorial, but, in my case, there are some big conceptual holes.

bdmc: you need to practice, you have just scrached the surface ;)

I agree.

*scratched

(bad english here)

DebianTUX: No problem. I got it.

bdmc: what didn't you got yet?

I agree. And I like what I have seen of Django. However, I have a specific need, and want to try and address it.

The issue is that my project is a bit "unusual." Well, not really, but it is away from the basic tutorials.

a restfull api? that's not unusual at all

I have a REST API that I am trying to test. To do so, I see my projects like:

user->Django->REST API->External Service->REST API->Django->user

bdmc: you will need to beyond django, consuming a rest API in the pitonic way, i think.

More learning, I know. Where?

bdmc: do some googling so you can have more concrete questions and problems

bdmc: Just to make sure I got this right - you want to talk to a REST API from the server, not from the client?

bdmc: what's that external service? chances are that they already have a python wrapper that you can use.

totte: the name of something you return is not visible outside the function

bdmc: For talking to generic REST APIs, do look at Requests, http://docs.python-requests.org/en/latest/

So I can just name it, like, whatever? The important thing is context_object_name which is what's used in the filters, right?

and never use the standard library urllib :)

totte: yes

Sorry, guys. I was off doing some searching of my own. Yes, this is a new Python REST API, developed to talk to this external service, and I am trying to develop a way to present a user interface.

to create a test or demo application to use the API

bdmc: You are confusing me. Do you want Django to *provide* a REST API to some client, or *use* a REST API from some other provider?

(Or both :-))

to Use

bdmc: Then see the recommendation for Requests above :-)

totte: you should make a habit of using meaningful names and avoid clashes with the names of python builtins

OK, thanks. The REST API is a local library, if that makes a difference.

moldy: Yeah, this code has grown for over a year by now... Maybe I should rewrite it from scratch. There are a lot of unused imports and the like.

Thanks for the advice. :)

totte: tools like flake8 and autopep8 may be helpful

moldy: Noted.

bdmc: what do you think "REST" means?

bdmc: and what is a local library for you?

forcer: what are non-generic REST APIs?

;)

dAnjou: Specific REST APIs that already have Python wrappers

Well, there is the formal definition. But to get into it a bit more, I have a Python library that is the endpoint of a REST transaction with an external server.

forcer: that doesn't make much sense

In other words, calls to this library are then encapsulated in appropriate REST calls to the other server.

dAnjou: Why not?

bdmc: then what's the problem again?

I can call this library, passing appropriate data and ....

Now *that* is a good question :-D

The problem is that I am trying to build a Django "front-end" for this library.

forcer: so when i write a piece of code that wraps an API it suddenly becomes specific as opposed to generic?

I have wondered whether this library fits into models.py, in place of the database, or somewhere else, or if I am completely off base.

dAnjou: That's how I meant the "generic" in my statement, yes. I hope I did not confuse you too much. :-)

bdmc: Somewhere else. It's just a normal Python library, put it where you would put any Python library.

bdmc: you don't need models.py at all

OK, good. views?

I mean the calls to the library need to be exposed as views, mostly as displays, but some as input forms.

Or am I still needing to go back to school?

bdmc: Yes. You write views that call your library.

Thank you. That was sort of what I was thinking some time ago, but dragged you all off down the garden path, not understanding what I was trying to do.

Is the overall application log-in also a view? I know about the admin login, but want one for the users of the app, too.

bdmc: Every request to the HTTP server causes a view in Django to be called.

That will probably be a version 2, but --- ok, got you.

forcer: I will look at the documentation on permissions in a little bit, once I get the basic system working.

Thank you all. I am sure that I will be back for more. B-)