Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > building a web interface

Reply
Thread Tools

building a web interface

 
 
Shel
Guest
Posts: n/a
 
      11-21-2010
No worries at all about repeating things. I wasn't clear, and I
appreciate your going to the trouble of teaching me just about
anything. Even things I think I know, I might not really know

Let's see... am okay with the relational design stuff. Thanks for the
"EXPLAIN" verb.

I am confused about multiple simultaneous users, which I would like to
be able to accommodate. On the db side, I have a structure to store
data for each user, and know a bit about selectively locking data,
although I have not implemented that yet, so will see what happens.

I don't really get how multiple users work in terms of pretty much
everything else, like if the Python code is running on the server,
then... well, I just don't know. Maybe I should try to get it running
for multiple discrete users first, and then think about simultaneous
users, or is that a bad way to go about things? Or maybe it will
start to make more sense when I get into building the interface? Any
info/suggestions are very welcome.

Thanks again!

Shel

On Nov 21, 4:51*am, Martin Gregorie <(E-Mail Removed)>
wrote:
> On Sat, 20 Nov 2010 17:20:53 -0800, Shel wrote:
> > Sorry I wasn't clear about the db part. *Most of the data has already
> > been written and/or generated and tested with the code. *I do plan to
> > finish all the database stuff before going to the front end, but am just
> > thinking ahead about how to do the interface.

>
> That sounds good. Sorry if I was repeating stuff you already know, but it
> wasn't obvious what you knew about care & feeding of an RDBMS. I'll just
> add two comments on databases:
> - Decompose the database design to 3NF form and make sure all prime
> * and foreign keys have indexes. This is stuff that previous experience
> * shows self-taught Access users don't do. Not doing it will bite you
> * hard on performance as soon as the tables exceed a few rows in size.
> * Fixing it later can force major changes to the programs as well.
>
> - If you haven't looked at it yet, find out about the EXPLAIN verb
> * and what its output means. Use it on all queries that your online
> * program issues and take notice of how rearranging the query and/or
> * adding/changing indexes affects the cost of the query. Lower cost
> * queries mean higher performance and hence faster response times.
>
> What I meant to add last night is that, if your application is to be used
> by more than a single user at a time a prime consideration is how you
> will recognise input received from each user and how you'll store their
> context between interactions with them in the same session and keep each
> session's context separate. The web server doesn't do this, so this
> managing session context is the application's responsibility. Common
> methods are to use a session cookie and/or to store session context in
> the database.
>
> --
> martin@ * | Martin Gregorie
> gregorie. | Essex, UK
> org * * * |


 
Reply With Quote
 
 
 
 
Shel
Guest
Posts: n/a
 
      11-21-2010
Just want to say thanks again to everyone who responded to this post.
You have all been really helpful.
 
Reply With Quote
 
 
 
 
Martin Gregorie
Guest
Posts: n/a
 
      11-22-2010
On Sun, 21 Nov 2010 15:40:10 -0800, Shel wrote:

> I am confused about multiple simultaneous users, which I would like to
> be able to accommodate. On the db side, I have a structure to store
> data for each user, and know a bit about selectively locking data,
> although I have not implemented that yet, so will see what happens.
>

I realise what I wrote last night wasn't all that clear. Terms:
'transaction' and 'session'.

A web server 'transaction' consists of a request from a user that results
in a page being sent to the user. That's it. It is an isolated action
that does not depend in the web server knowing anything about the user
because all the information it needs to decide which page to send was
supplied when the user sent in the URL of the page. Now if the user
clicks on a link on that page, his browser sends the URL in the link to
the server, which in turn fishes out another page and sends it back to
the user. As far as the server is concerned, there is no connection
whatever between the two requests: either or both URLs could have been
copied from a piece of paper for all it knows or cares. There is no
concept of context or a session involved.

A 'session' involves context. Think of what happens when you login to a
computer. That starts a login session that has context: the computer now
knows who you are and provides context by connecting you to your login
directory and opening some work space which is used to remember which
directory you're in, what commands you issued (so you can look at the
history), etc. The session and its context persists until you log out.

In what you're intending to do, a user will start a session by starting
to use your program and that session will last until the user disconnects
from the session. All the web server knows is that instead of finding a
page on disk some place it passes your user's request to your program and
sends its output, in the form of a web page, back to the user. It does
this each time it receives a request from the user because all the user's
requests contain the same URL - that of your program. The server does
this without knowing there is such a thing as a session or that there is
any context belonging to the user.

The upshot is that your program has to keep track of all the active
sessions and maintain context for each active session. It also needs a
way to recognise and get rid of dead sessions because sessions don't
always end cleanly: the line may go down or the user may forget he was
using your program and turn his PC off. For instance, if the session
context has a timestamp, you might delete it after, say, 20 hours of
inactivity, or when the user logs on again. If the data is sensitive, you
might also force a new logon after 10 minutes of inactivity.

The database is as good a place as any for keeping session and context
data - if its well structured the context may well form a single (large)
row on one table, but you do need a unique key for it. That could even be
the login name provided you're able to include it in every page you send
to the user and can guarantee that the browser will send it back as part
of the next request. A hidden field on the page will do this
automatically.

The basic program cycle will be:

- receive a request
- read the context for the session
- use data in the request to carry out the requested action
- write the updated context back to the database
- create the output page and send it to the user

though of course you need additional dialogue to deal with both valid and
invalid logons and logoffs.

> I don't really get how multiple users work in terms of pretty much
> everything else, like if the Python code is running on the server,
> then... well, I just don't know.
>

Hopefully the above made it a bit clearer.

> Maybe I should try to get it running
> for multiple discrete users first, and then think about simultaneous
> users, or is that a bad way to go about things? Or maybe it will start
> to make more sense when I get into building the interface? Any
> info/suggestions are very welcome.
>

For bare desktop development I would split the program into three parts:

1) the program itself, written to run a single transaction each time its
called. Inputs would be the bits of the users message it needs to act on
and the current session context record.

2) a testing harness that accepts user input from the console, sends
output back to the console and maintains a single session context record
in memory: IOW it runs your program in single user mode.

3)the web server interface which retrieves the session context record,
passes it and the input to your program and, after that has run, saves
the session context record and passes the output to the web server for
delivery to the user.

This way both 2 and 3 can be developed against a really simple 'do almost
nothing' version of 1 while that in turn can be developed and tested on
your desktop using 2 and later be dropped into the web server with 3 as
its interface.

I have an in-house copy of Apache that I'd use to develop your type of
program. Its used for all my website development so that nothing gets
loaded onto my public sites until its been properly checked out here.
You can do the same if you can find and install a really simple web
server that would run on your PC together with a local copy of MySQL - of
course! Given this setup you can use your usual web browser to talk to
the local web server. If you can run all that you won't need 2 because
you can have your simple web server and program running in a console
window on your desktop PC while you hammer it from your web browser.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
Jean-Michel Pichavant
Guest
Posts: n/a
 
      11-22-2010
Shel wrote:
> Hello,
>
> I am pretty new to all this. I have some coding experience, and am
> currently most comfortable with Python. I also have database design
> experience with MS Access, and have just created my first mySQL db.
>
> So right now I have a mySQL db structure and some Python code. My end
> goal is to create a browser-based interactive fiction/game thing. My
> code is currently just using dummy data rather than pulling in data
> from the db, but I think/hope it won't be too big of a deal to
> interact with the db through Python (famous last words...).
>
> My main problem right now is how to do the web interface. I don't know
> much about web architecture, unfortunately. I think I need a CGI
> script?
>
> What I would really like is to find a GUI tool to design the interface
> that would have customizable templates or drag-and-drop elements or
> something, so I wouldn't have to code much by hand. Something easy, if
> such a tool exists.
>
> Also would prefer something that I would be able to install/use
> without having much access to the server where the site will be hosted
> (on a university server that I don't have control over). I don't fully
> understand how a lot of the tools I have been looking at work, but it
> seems like they're often things where you'd have to get an
> administrator to do stuff on the server (is that right?), which I
> would prefer to avoid.
>
> It looks like Django has some sort of standalone implementation, but
> I'm not clear on how that would work or how much of a learning curve
> there would be for using it.
>
> If anyone has any thoughts or suggestions, I would really appreciate
> it.
>
> Hope my questions make sense. I don't really know what I'm doing, so
> could be they're a bit silly. I apologize if that's the case, and
> please let me know if you need any additional informmation.
>
> Thanks,
> Shel
>

Django is quite popular, they claim to be easy to learn/use. That's for
the web framework.
You could use pyjamas for the web interface, looks like it works well
with django.

Hmm, writing python code only, sounds like a dream come true

Note that I never used one of these, it just happened I had to look for
possible solutions for a web application.


JM
 
Reply With Quote
 
Shel
Guest
Posts: n/a
 
      11-25-2010
This is really great. I wish I could come up with some creative new
ways to say thank you, but... thank you
Shel

On Nov 21, 6:10*pm, Martin Gregorie <(E-Mail Removed)>
wrote:
> On Sun, 21 Nov 2010 15:40:10 -0800, Shel wrote:
> > I am confused about multiple simultaneous users, which I would like to
> > be able to accommodate. *On the db side, I have a structure to store
> > data for each user, and know a bit about selectively locking data,
> > although I have not implemented that yet, so will see what happens.

>
> I realise what I wrote last night wasn't all that clear. Terms:
> 'transaction' and 'session'.
>
> A web server 'transaction' consists of a request from a user that results
> in a page being sent to the user. That's it. It is an isolated action
> that does not depend in the web server knowing anything about the user
> because all the information it needs to decide which page to send was
> supplied when the user sent in the URL of the page. Now if the user
> clicks on a link on that page, his browser sends the URL in the link to
> the server, which in turn fishes out another page and sends it back to
> the user. As far as the server is concerned, there is no connection
> whatever between the two requests: either or both URLs could have been
> copied from a piece of paper for all it knows or cares. There is no
> concept of context or a session involved.
>
> A 'session' involves context. Think of what happens when you login to a
> computer. That starts a login session that has context: the computer now
> knows who you are and provides context by connecting you to your login
> directory and opening some work space which is used to remember which
> directory you're in, what commands you issued (so you can look at the
> history), etc. The session and its context persists until you log out.
>
> In what you're intending to do, a user will start a session by starting
> to use your program and that session will last until the user disconnects
> from the session. All the web server knows is that instead of finding a
> page on disk some place it passes your user's request to your program and
> sends its output, in the form of a web page, back to the user. It does
> this each time it receives a request from the user because all the user's
> requests contain the same URL - that of your program. The server does
> this without knowing there is such a thing as a session or that there is
> any context belonging to the user.
>
> The upshot is that your program has to keep track of all the active
> sessions and maintain context for each active session. It also needs a
> way to recognise and get rid of dead sessions because sessions don't
> always end cleanly: the line may go down or the user may forget he was
> using your program and turn his PC off. For instance, if the session
> context has a timestamp, you might delete it after, say, 20 hours of
> inactivity, or when the user logs on again. If the data is sensitive, you
> might also force a new logon after 10 minutes of inactivity.
>
> The database is as good a place as any for keeping session and context
> data - if its well structured the context may well form a single (large)
> row on one table, but you do need a unique key for it. That could even be
> the login name provided you're able to include it in every page you send
> to the user and can guarantee that the browser will send it back as part
> of the next request. A hidden field on the page will do this
> automatically.
>
> The basic program cycle will be:
>
> - receive a request
> - read the context for the session
> - use data in the request to carry out the requested action
> - write the updated context back to the database
> - create the output page and send it to the user
>
> though of course you need additional dialogue to deal with both valid and
> invalid logons and logoffs.
>
> > I don't really get how multiple users work in terms of pretty much
> > everything else, like if the Python code is running on the server,
> > then... well, I just don't know.

>
> Hopefully the above made it a bit clearer.
>
> > *Maybe I should try to get it running
> > for multiple discrete users first, and then think about simultaneous
> > users, or is that a bad way to go about things? *Or maybe it will start
> > to make more sense when I get into building the interface? *Any
> > info/suggestions are very welcome.

>
> For bare desktop development I would split the program into three parts:
>
> 1) the program itself, written to run a single transaction each time its
> called. Inputs would be the bits of the users message it needs to act on
> and the current session context record.
>
> 2) a testing harness that accepts user input from the console, sends
> output back to the console and maintains a single session context record
> in memory: IOW it runs your program in single user mode.
>
> 3)the web server interface which retrieves the session context record,
> passes it and the input to your program and, after that has run, saves
> the session context record and passes the output to the web server for
> delivery to the user.
>
> This way both 2 and 3 can be developed against a really simple 'do almost
> nothing' version of 1 while that in turn can be developed and tested on
> your desktop using 2 and later be dropped into the web server with 3 as
> its interface.
>
> I have an in-house copy of Apache that I'd use to develop your type of
> program. Its used for all my website development so that nothing gets
> loaded onto my public sites until its been properly checked out here.
> You can do the same if you can find and install a really simple web
> server that would run on your PC together with a local copy of MySQL - of
> course! Given this setup you can use your usual web browser to talk to
> the local web server. If you can run all that you won't need 2 because
> you can have your simple web server and program running in a console
> window on your desktop PC while you hammer it from your web browser.
>
> --
> martin@ * | Martin Gregorie
> gregorie. | Essex, UK
> org * * * |


 
Reply With Quote
 
Alice Bevan–McGregor
Guest
Posts: n/a
 
      11-25-2010
Howdy!

I'm mildly biased, being the author of the framework, but I can highly
recommend WebCore for rapid prototyping of web applications; it has
templating via numerous template engines, excellent JSON (AJAJ)
support, and support for database back-ends via SQLAlchemy. It also
has session support baked-in via a project called Beaker.
Documentation is fairly complete, and I can be found camping in the
#webcore IRC channel on irc.freenode.net at strange hours.

If you can write a class, you can have a fully operational web
application in a single file of ~8 lines or so. (Or you can create a
complete easy-installable Python package with multiple modules.)

For information, see: http://www.web-core.org/

As an interactive-fiction example:

class RootController(web.core.Controller):
def index(self):
"""This returns a template that uses JavaScript to call execute().
The JavaScript adds the result of execute() to the display."""
session = db.Session().save()
return './templates/main.html', dict(session=session.id)

def execute(self, session, statement):
"""Load our session and pass the input off to our interactive
fiction library of choice. Return the result if all went well."""
session = db.Session.get(session)

try:
result = myiflib.execute(session, statement)

except myiflib.ParseError:
return 'json:', dict(status="failure", message="Error...")

return 'json:', dict(status="success", message=result)

— Alice.

 
Reply With Quote
 
Shel
Guest
Posts: n/a
 
      11-25-2010
Will take a look after stuffing myself with turkey today (am in the
US, where we give thanks by eating everything in sight). Thanks,
Alice.

Wait, did I just say "thanks"? Must go eat pie.

On Nov 25, 12:36*am, Alice BevanMcGregor <(E-Mail Removed)> wrote:
> Howdy!
>
> I'm mildly biased, being the author of the framework, but I can highly
> recommend WebCore for rapid prototyping of web applications; it has
> templating via numerous template engines, excellent JSON (AJAJ)
> support, and support for database back-ends via SQLAlchemy. *It also
> has session support baked-in via a project called Beaker. *
> Documentation is fairly complete, and I can be found camping in the
> #webcore IRC channel on irc.freenode.net at strange hours.
>
> If you can write a class, you can have a fully operational web
> application in a single file of ~8 lines or so. *(Or you can create a
> complete easy-installable Python package with multiple modules.)
>
> For information, see:http://www.web-core.org/
>
> As an interactive-fiction example:
>
> class RootController(web.core.Controller):
> * * def index(self):
> * * * * """This returns a template that uses JavaScript to call execute().
> * * * * The JavaScript adds the result of execute() to the display."""
> * * * * session = db.Session().save()
> * * * * return './templates/main.html', dict(session=session.id)
>
> * * def execute(self, session, statement):
> * * * * """Load our session and pass the input off to our interactive
> * * * * fiction library of choice. *Return the result if all went well."""
> * * * * session = db.Session.get(session)
>
> * * * * try:
> * * * * * * result = myiflib.execute(session, statement)
>
> * * * * except myiflib.ParseError:
> * * * * * * return 'json:', dict(status="failure", message="Error...")
>
> * * * * return 'json:', dict(status="success", message=result)
>
> * Alice.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Link Building Services| Link Building Company|Webs abrahim Java 0 12-27-2009 02:31 PM
Connecting Wireless Network from Building to Building Jim Wireless Networking 5 10-05-2007 03:54 PM
Firefighters at the site of WTC7 "Move away the building is going to blow up, get back the building is going to blow up." Midex Python 24 05-07-2007 04:23 AM
Wireless building-to-building 101 Tim Jacob Wireless Networking 2 02-17-2006 09:46 AM
Building to Building wireless Patriot Cisco 2 11-04-2003 05:07 PM



Advertisments