How to implement a dropdownlist in CherryPy where selected item is returned as argument appended to current URL?

[Jibun no Kage]

How to implement a dropdownlist in CherryPy where selected item is returned as argument appended to current URL?

For example, say I have a form select:

1-Test

2-Debug

3-Run

4-Report

Current URL is /number.

And when I select 4, URL via POST (or GET?) is now /number?select=4-Report, or something to the same effect?

Would like to keep the solution native python if possible.

[Tim Roberts]

On May 13, 2019, at 7:33 PM, Jibun no Kage <jibun...@gmail.com> wrote:
>
> How to implement a dropdownlist in CherryPy where selected item is returned as argument appended to current URL?

This is an HTML question, not a Python question.

> For example, say I have a form select:
>
> 1-Test
> 2-Debug
> 3-Run
> 4-Report
>
> Current URL is /number.
>
> And when I select 4, URL via POST (or GET?) is now /number?select=4-Report, or something to the same effect?

<form method=get action="/number>
<select name='select'>
<option value=1>1. Test</option>
<option value=2>2. Debug</option>
<option value=3>3. Run</option>
<option value=4>4. Report</option>
</select>
</form>

That's all it takes.
—
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Jibun no Kage]

No, its both.  Implementation of a dropdownlist in each respective environment is slightly different, be it PHP, Java, etc.  Given that CherryPy has a unique dispatch method, that imposes specific requirements, it is not obvious how such can be done.  If it was just a matter of cut and paste of straight HTML I would not have posed the question as I have.  Moreover, examples via Google or what have you, would be abundant, they do not seem to be so.  I am sure there is someone in the greater CherryPy world, that has implemented a dropdownlist as I outlined.  Thus, I am asking for assistance and examples of how to do so in a CherryPy acceptable manner.  Hopefully python atomic as well, if such is possible.

[Tim Roberts]

On May 13, 2019, at 10:19 PM, Jibun no Kage <jibun...@gmail.com> wrote:

No, its both.  Implementation of a dropdownlist in each respective environment is slightly different, be it PHP, Java, etc.  Given that CherryPy has a unique dispatch method, that imposes specific requirements, it is not obvious how such can be done. 

But that's just not so.  PHP and Cherrypy both produce a plain, ordinary HTML form that gets sent to the browser.  At that point, that request is finished.  The browser handles the HTML form submission by sending back a new request, which gets handled by a new handler.  Neither PHP nor CherryPy actually do anything to "handle" the dropdown list, and the server code is not active while the browser is presenting the form.

Hopefully python atomic as well, if such is possible.

I can't tell what you are imagining here, but the "atomic" concept doesn't apply.  The request that sends the HTML with the form is a completely separate request from the one that handles the returned URL.  The display of the dropdown box itself is done by the browser on a completely different computer; CherryPy is not involved in that operation in any way.

— 

[Jibun no Kage]

Thanks for the response.  I would point out that PHP, Java do much more than just generate simple HTML indirectly, the final response maybe just HTML but the API calls, methods, etc. they natively support, solve programmatic scenarios that would require extensive coding/scripting in raw HTML, they inject in the response, and thus the client side interprets resulting HTML.  Wrappers or whatever you may want to call it.  This ease of implementation is why PHP and Java are so popular.  I still am requesting someone to post an example of a dropdownlist in a CherryPy project, since I found none thus far... even if it is just a HTML response.  Might be a nice thing to add to the tutorial for CherryPy. 

The various examples I did find all use various python modules to get the job done, which is something I want to avoid if possible.  Dependence of 3rd party modules is somewhat discouraged in my environment, given the risks in using same.  The use of threading is controlled as well by our design protocol, i.e. avoid using multi threading to reduce complexity.  That is in reference to my atomic reference, I want to implement the solution avoiding 3rd party modules if possible and avoid multi thread creation if possible.

On Monday, May 13, 2019 at 7:33:05 PM UTC-7, Jibun no Kage wrote:

[Jibun no Kage]

Below is a link that illustrates my point about how more than just straight HTML is used...
https://css-tricks.com/unobtrusive-page-changer/

No one, that I have seen so far, appears to do a drop down list with just straight HTML, that responds on selection completion of an item, which is what I was looking for.  The closest you can get is to use a drop down list and then a submit button... but that is not the requirement as noted in my topic.  Clearly, CherryPy has no native hook or method to do this, per the past discussion thus far.  This reliance on Java or PHP as the above link references, provides the event logic.  Our project design is 100% python and within the CherryPy environment.  To add just one drop down list... we have to add an additional language?  Be it Java, PHP, or whatever, It appears that is the case.

--
You received this message because you are subscribed to the Google Groups "cherrypy-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cherrypy-user...@googlegroups.com.
To post to this group, send email to cherryp...@googlegroups.com.
Visit this group at https://groups.google.com/group/cherrypy-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/cherrypy-users/3b35a36f-cbc5-40b3-b1bc-28fbfbb8aa50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michiel Overtoom]

Hi,

> On 2019-05-14, at 17:12, Jibun no Kage <jibun...@gmail.com> wrote:
>
> No one, that I have seen so far, appears to do a drop down list with just straight HTML

What do you mean by 'straight HTML'? Does that allow for JavaScript code in the 'onchange' event handler?

> The closest you can get is to use a drop down list and then a submit button... but that is not the requirement as noted in my topic.

If you want to avoid a separate submit button, you can have the 'onchange' event of the dropdown submit the form. I use this principle on a webapp I wrote, https://www.learnit.nl/inschrijving . When you select a training, the form gets submitted, and a new form is returned to the browser, with more dropdowns where you can select a date, a place etc...

I made this by adding an 'onchange' event to the dropdown, which causes the webbrowser to submit the form as soon as the user chooses an item from the dropdown: (as if the user has pressed the submit button)

<form action="/process" method="post">
<select id="food" name="food" onchange="submit();">
<option value="23">Apple</select>
<option value="62">Banana</select>
<option value="19">Bread</select>
</select>
...
</form>

> Clearly, CherryPy has no native hook or method to do this, per the past discussion thus far.

That is correct, because this has nothing to do with what framework or language you use to serve up the page. The HTML page is displayed in the webbrowser of the user. When the user interacts with the page, events are generated, and these events can execute JavaScript code in the page. This all happens on the PC of the user and the server won't see any of this. The JavaScript code could for example, redirect the browser to another URL, or if the page contains a form, submit the form to the server.

> To add just one drop down list... we have to add an additional language?

No, that is not necessary. You just have to make your HTML a bit more dynamic by providing event handlers. And these event handlers are usually written in JavaScript, because that language is built-in the webbrowser.

Greetings,


--
"You can't actually make computers run faster, you can only make them do less." - RiderOfGiraffes

[Jibun no Kage]

Thanks for the example, appreciate it.

As I am sure many have gathered, I am working under some unique
requirements.  Straight HTML would be without use of any optional
scripting language, i.e. that will likely be disabled.  Java script as
one example is restricted and even prohibited in some secured
environments.  In secured micro-controller environments for example,
there are quite a number of limits and restrictions unique to the
environment at hand.  This is also typical of Internet-of-Things
implementations for example.

So assumption that Java is available, i.e. enabled is not a given.
Moreover, the design goals I am working with is to not use additional
scripting support, and Java is explicitly prohibited. This of course
limits the flexibility of the design significantly. Fortunately, I can
use CSS so that gives me some flexibility to the interface design.  But
this project is a challenge no doubt.

I am trying a few things using the change of focus and hover events,
time to get creative.

[Tim Roberts]

Jibun no Kage wrote:
> Below is a link that illustrates my point about how more than just
> straight HTML is used...
> https://css-tricks.com/unobtrusive-page-changer/

I disagree violently.  The drop-down list in that example is nothing but
pure HTML.  When the submit button is clicked, it sends a URL back to
the server.  The acts on the URL just like it does for every other
request.  What do you see as special in that example?

I also have to disagree with the wording on that page.  What he calls
the "obtrusive way" is handled entirely in the browser. Everything takes
place locally, with no additional network traffic.  What he calls the
"unobtrusive way" requires an extra and totally unnecessary round-trip
back to the web server, just so it can send a header to force the
browser to do the exact same thing that one line of Javascript was doing.

> No one, that I have seen so far, appears to do a drop down list with
> just straight HTML, that responds on selection completion of an item,
> which is what I was looking for.

The straight HTML example you cited does not do that, either.  It
requires the user to click the "submit" button.  The modified version at
the bottom is using Javascipt plus jQuery plus that extra server
round-trip to accomplish what the first example did with a single line
of code.  The final product there is worse than the original example in
every conceivable way.  It requires more Javascript code on the page, it
requires you to load jQuery in the page, and it requires an extra server
round-trip.  I can't tell what they were trying to prove here, but they
failed to do so.

> Clearly, CherryPy has no native hook or method to do this, per the
> past discussion thus far.

And neither does PHP.

> This reliance on Java or PHP as the above link references, provides
> the event logic.

You do understand that Java and Javascript are not related in any way,
don't you?  The page you cited shows three lines of PHP running on the
server.  ALL of the other code there is Javascript that gets sent with
the HTML and executed in the browser, and would be present regardless of
the language used on the server. Do you understand that the chunk of
code that starts "$(function() {" is Javascript and not PHP?

If you are looking for the CherryPy equivalent to the three lines of PHP
code on that page, that's easy enough:

    @cherrypy.expose
    def number( self, nav=None ):
        if nav:
            cherrypy.response.headers['Location'] = nav

> Our project design is 100% python and within the CherryPy
> environment.  To add just one drop down list... we have to add an
> additional language?  Be it Java, PHP, or whatever, It appears that is
> the case.

No, I think you are confused about which code is running where.

--

[Tim Roberts]

Jibun no Kage wrote:
>
> As I am sure many have gathered, I am working under some unique
> requirements.  Straight HTML would be without use of any optional
> scripting language, i.e. that will likely be disabled.  Java script as
> one example is restricted and even prohibited in some secured
> environments.  In secured micro-controller environments for example,
> there are quite a number of limits and restrictions unique to the
> environment at hand.  This is also typical of Internet-of-Things
> implementations for example.

IoT devices run a web SERVER, not a web BROWSER.  A web browser is a UI
concept, and IoT devices don't have a UI.  Javascript runs in the web
browser, not on the server.


> So assumption that Java is available, i.e. enabled is not a given. ...

JavaSCRIPT.  Please, those two are very, very, very different languages
used for very different purposes.  The world was done a huge misservice
when Netscape decided to rename ECMAScript to Javascript in order to
cash in on the "cool word of the day".  You MUST get your terminology
straight, because I think that's were some of your confusion arises. 
Your IoT device can send Javascript code in the HTML pages it sends out,
knowing that it will be read and executed by a competent web browser on
a user's laptop somewhere.

> Moreover, the design goals I am working with is to not use additional
> scripting support, and Java is explicitly prohibited.

Java or Javascript?  There was a time that Java was proposed as a
browser-extension language, just like Microsoft's ActiveX controls. 
That time is gone.  I can believe that Java is prohibited.  However,
Javascript support is ubiquitous.  EVERY non-toy browser has it, and it
is secure.  I do not believe any serious web-based project today would
prohibit Javascript.  It doesn't make sense.

> This of course limits the flexibility of the design significantly.

Yes.  For example, you cannot implement an "automatic" dropdown list
without Javascript.  It is impossible.  Forms can only be submitting by
having the user click a "submit" button.

> I am trying a few things using the change of focus and hover events,
> time to get creative.

Change of focus and hover events execute Javascript code.   If you are
allowed to handle events, then you are allowed to use Javascript.

[Walter Jaisli]

what you can do ist something like (as content of a Python Script) :

import cherrypy

class dropDown(object):
    @cherrypy.expose  
    def number(self, selected = ''):
        view = ''
        if selected  != '':
           view = 'you selected '+selected
        html = '<html><body>'
       
        html += '<form action = "/number" id="myForm">'
        html += '<select name="selected" onChange=document.getElementById("myForm").submit()>'
        html += '<option value="1-Test">1-Test</option>'
        html += '<option value="2-Debug">2-Debug</option>'
        html += '<option value="...">...</option>'
        html += '<option value="...">...</option>'
        html  += '<select>'
        html += '<form>'
        html += view
       
        html += '</body></html>'
        return html
       
cherrypy.quickstart(dropDown())       

you find your dropdown list with:  localhost:8080/number

but as Tim Roberts says:  it works only with Javascript activated.

Walter Jaisli

--
You received this message because you are subscribed to the Google Groups "cherrypy-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cherrypy-user...@googlegroups.com.
To post to this group, send email to cherryp...@googlegroups.com.
Visit this group at https://groups.google.com/group/cherrypy-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/cherrypy-users/b8b7661c-4e82-2e42-b2ea-319e3c104ad4%40probo.com.

[Jibun no Kage]

JavaScript, Java Run Time, etc. are not consistently available on the
client side.  Thus development of code, publishing, on the server side
to leverage any variant of Java becomes useless.  In my case, simply
put, if the word Java is referenced in the design of the project, it is
a non-starter, not allowed.

Moreover, IoT devices can acts as clients as well... have worked on
project where they have done duel tasking, acting as both client and
server functions, even more than just an access point.  There is even
one project I know of where the IoT devices are mesh linked, responding
and acting as publishers and subscribers to many other devices to act as
a locus of interactive nodes.  An IoT device that uses curl is not
considered a client?  Clients are not limited popular browsers competent
or otherwise, leveraging HTML.  REST APIs are just to tempting to
developers, their pros and cons, not qualified here.

As for secure or not secure... that is not for anyone to qualify but the
ultimate user, client, etc.  As note above, Java is declared, and its
variants, as insecure, requirement of design goals.  IMHO never qualify
something as secure... nothing is secure, other than a device connected
to nothing and never powered on, and even that maybe previous exploited
in some way.  There are many zero day exploits in all technologies just
waiting to be leveraged.  Ask any fortune 50 company how much vetting is
done in a lab before any technology is deployed.  The term secure is
never used as justification of any technology, rather it is when the
benefit of the technology is greater than the risk of using the
technology is the question.  But I digress.

Of course none of the above are applicable to my request to solve a
unique design goal with key restrictions.  Maybe it will address some of
your concerns as noted.

[Tim Roberts]

Jibun no Kage wrote:
>
> JavaScript, Java Run Time, etc. are not consistently available on the
> client side.  Thus development of code, publishing, on the server side
> to leverage any variant of Java becomes useless.  In my case, simply
> put, if the word Java is referenced in the design of the project, it
> is a non-starter, not allowed.

I strongly suspect you have misinterpreted the design guidelines, but
that's neither here nor there.  If you really are limited to straight
HTML, then there is no way to trigger a new request except through a
submit button or a clickable link.

And I want to re-emphasize that Javascript is NOT a variant of Java. 
There is no relationship between the two.  The languages look nothing
alike and share no philosophies or design history.


> As I noted in my previous reply, the use of client side or server side
> technologies is explicitly restricted.

CherryPy is a server-side technology.


> Thus use of any drop down list as an element of the UI does not appear
> possible.

Not so.  Drop-down lists have been part of HTML since day one. What is
not possible is to have a drop-down list that automatically triggers a
form send.