Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #74735 > unrolled thread

Re: Two more newbie questions

Started byShieldfire <shieldfire@gmail.com>
First post2014-07-18 11:08 +0200
Last post2014-07-18 11:08 +0200
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Two more newbie questions Shieldfire <shieldfire@gmail.com> - 2014-07-18 11:08 +0200

#74735 — Re: Two more newbie questions

FromShieldfire <shieldfire@gmail.com>
Date2014-07-18 11:08 +0200
SubjectRe: Two more newbie questions
Message-ID<mailman.11992.1405674494.18130.python-list@python.org>
On fre, 2014-07-18 at 18:23 +1000, Ben Finney wrote:
> Martin S <shieldfire@gmail.com> writes:
> 
> > a/ What is the "easiest" way of putting a web interface on this CLI
> > application. I've been looking at various web frameworks but that
> > seems pretty much targeted more towards larger projects. Not "slapping
> > a gui" on a cli application.
> > Any pointers and suggestions appreciated.
> 
> My suggestion: Have a firmer idea of what you want the UI to do.

> 
> So, if by “slap a GUI onto” you mean something that is a no-frills
> plain-HTML form, with essentially no assistance for the user and no
> error handling, this will be a lot simpler to implement than something
> easier for the human to use.

Pretty much this. Because anyone using the tool would understand what to
enter. There are things like opponent, result, tournament and rating
without which there wouldn't be a need to use the tool in the first
place. 
The only fancy thing I've done in the cli version is for it to remember
some options the users has made previously (like Tournament defaults to
previous post when entering several games)
> 
> > b/ Catching user input errors. What is generally the best way of
> > catching those and doing something sane with it. Entering "asdf"
> > instead of a rating (like 2014) pretty much kills the little tool
> > horribly.
> 
> Right. Handling errors is very much a matter of UX policy for the
> application, and can easily consume far more of the programming effort
> than merely getting the back-end processing done.
> 
> So again, the work to be done here is less Python-specific and much more
> about being tediously precise about how you want the user experience to
> work. 

Basically afaics at this time it is to ensure someone doesn't enter an
incorrect value by mistake (like '' for result, or rating without it
being an integer) and then letting the user correct the entries before
committed.

/Martin S

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web