By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,723 Members | 1,665 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,723 IT Pros & Developers. It's quick & easy.

duplicate select controls

P: n/a
I need a form control for the user to enter currency symbol.
A select control seems to be fit for that purpose;
but the problem is that the control must appear on the page several times
so the formula for page size gets bounded from below by number of controls times number of currencies.
Which means that
1) the page must be produced on the fly in order to be consistent,
2) the data to be transmitted can grow excessively because the page will contain much redundant information
3) it creates unnecessary strain upon the browser to maintain all these select elements.
Upon taking this into account, I decided I would stay with a text control to be validated afterwards.
Are those considerations correct? I feel that HTML lacks some important abstraction here.
Chris
Feb 23 '07 #1
Share this Question
Share on Google+
16 Replies


P: n/a
Gazing into my crystal ball I observed Křiątof ®elechovski
<gi******@stegny.2a.plwriting in
news:er***********@news2.ipartners.pl:
I need a form control for the user to enter currency symbol.
A select control seems to be fit for that purpose;
but the problem is that the control must appear on the page several
times so the formula for page size gets bounded from below by number
of controls times number of currencies. Which means that
1) the page must be produced on the fly in order to be consistent,
2) the data to be transmitted can grow excessively because the page
will contain much redundant information 3) it creates unnecessary
strain upon the browser to maintain all these select elements. Upon
taking this into account, I decided I would stay with a text control
to be validated afterwards. Are those considerations correct? I feel
that HTML lacks some important abstraction here. Chris
How about at the top of the page something like:
<label for="currency">Your currency? </label>
<select name="currency" id="currency">
<option value="1">Dollars</option>
<option value="2">Euros</option>
<option value="3">Yen</option>
<option value="4">Darsek</option>
</select>
....the rest of the form

--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

Feb 23 '07 #2

P: n/a

Użytkownik "Adrienne Boswell" <ar****@yahoo.comnapisał w wiadomo¶ci news:Xn****************************@69.28.186.121. ..
Gazing into my crystal ball I observed Křiątof ®elechovski
<gi******@stegny.2a.plwriting in
news:er***********@news2.ipartners.pl:
>I need a form control for the user to enter currency symbol.
A select control seems to be fit for that purpose;
but the problem is that the control must appear on the page several
times so the formula for page size gets bounded from below by number
of controls times number of currencies. Which means that
1) the page must be produced on the fly in order to be consistent,
2) the data to be transmitted can grow excessively because the page
will contain much redundant information 3) it creates unnecessary
strain upon the browser to maintain all these select elements. Upon
taking this into account, I decided I would stay with a text control
to be validated afterwards. Are those considerations correct? I feel
that HTML lacks some important abstraction here. Chris
How about at the top of the page something like:
<label for="currency">Your currency? </label>
<select name="currency" id="currency">
<option value="1">Dollars</option>
<option value="2">Euros</option>
<option value="3">Yen</option>
<option value="4">Darsek</option>
</select>
...the rest of the form
The problem is the same code must be repeated each time a currency control is presented on the page,
and it can be presented several times.
This causes a minor maintenance problem (the options must be the same for each occurrence)
and a major performance problem (potential code bloat on client side if many currencies are allowed).

Chris
Feb 23 '07 #3

P: n/a
Scripsit Křiątof ®elechovski:
I need a form control for the user to enter currency symbol.
What makes you think so? It sounds like something that does not make sense
in most contexts, except when the purpose of the form relates to currency
symbols (not currencies or money or trade but currency symbols as symbols).
A select control seems to be fit for that purpose;
Then what you actually need is a form control for specifying currency. The
rest depends on the amount of currencies that can be used. For example, if
any currency is to be allowed, then it is clearly best to have a
three-letter input field and a link to a table of international currency
codes. If there are just two or three currencies accepted, use radio
buttons. A select element with a suitable size="..." attribute could be used
too, but it's somewhat clumsier to use.
but the problem is that the control must appear on the page several
times
Why? If there is a good reason (which I doubt), then a select element with
size="1" (the default) might be defendable.
so the formula for page size gets bounded from below by number of
controls times number of currencies.
That's irrelevant for all practical purposes. What makes you think it would
be a significant problem.
Which means that
1) the page must be produced on the fly in order to be consistent,
What? Why?
2) the data to be transmitted can grow excessively because the page
will contain much redundant information
If that's a problem, then the form itself is overgrown and a nightmare to
the user.
3) it creates unnecessary strain upon the browser to maintain all
these select elements.
There might be some truth in that. Browsers may have problems with pages
contain a huge number of form controls; at least some old browsers did. But
then the solution would be to split the form into smaller parts and chain
them dynamically - or maybe just simplify the form.
Upon taking this into account, I decided I would stay with a text
control to be validated afterwards.
I hope you didn't think about using a select element _without_ server-side
checking. Never trust a smiling cat, or a form on a web page; expect to get
junk, deal with it, separating real submissions from spamming and other
attacks.
I feel that HTML lacks some
important abstraction here.
The HTML form model is a simplistic idea formulated and implemented in a
confusing way. The only reason for using HTML forms is that they are the
only reliable user interface for most interactions on the web.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Feb 23 '07 #4

P: n/a
Křiątof ®elechovski wrote:
I need a form control for the user to enter currency symbol.
A select control seems to be fit for that purpose;
but the problem is that the control must appear on the page several times
so the formula for page size gets bounded from below by number of controls times number of currencies.
Which means that
1) the page must be produced on the fly in order to be consistent,
I don't understand what you mean here.
2) the data to be transmitted can grow excessively because the page will contain much redundant information
3) it creates unnecessary strain upon the browser to maintain all these select elements.
Multiple (okay, 2) duplicate lists seem to be what they use here:
http://www.oanda.com/convert/classic. I don't detect much "browser
strain" from it, though.

HTH.
--
John
Feb 23 '07 #5

P: n/a

Użytkownik "Jukka K. Korpela" <jk******@cs.tut.finapisał w wiadomo¶ci news:4E***************@reader1.news.saunalahti.fi. ..
Scripsit Křiątof ®elechovski:
>I need a form control for the user to enter currency symbol.
What makes you think so? It sounds like something that does not make sense
in most contexts, except when the purpose of the form relates to currency
symbols (not currencies or money or trade but currency symbols as symbols).
A three-letter code like USD is a currency symbol to me.
It seems I am wrong and only those fancy curly hooked stroked letters are currency symbols.
Sorry for the misunderstanding.
>A select control seems to be fit for that purpose;
Then what you actually need is a form control for specifying currency. The
rest depends on the amount of currencies that can be used. For example, if
any currency is to be allowed, then it is clearly best to have a
three-letter input field and a link to a table of international currency
codes. If there are just two or three currencies accepted, use radio
buttons. A select element with a suitable size="..." attribute could be used
too, but it's somewhat clumsier to use.
>but the problem is that the control must appear on the page several
times
Why? If there is a good reason (which I doubt), then a select element with
Because the form has to do with transactions in various currencies.
size="1" (the default) might be defendable.
That was my original idea.
>so the formula for page size gets bounded from below by number of
controls times number of currencies.
That's irrelevant for all practical purposes. What makes you think it would
be a significant problem.
>Which means that
1) the page must be produced on the fly in order to be consistent,
What? Why?
Because changing the set of allowed currencies should require a change in just one place,
otherwise Murphy's law applies.
>2) the data to be transmitted can grow excessively because the page
will contain much redundant information
If that's a problem, then the form itself is overgrown and a nightmare to
the user.
It is, but it is beyond my authority to change it.
>3) it creates unnecessary strain upon the browser to maintain all
these select elements.
There might be some truth in that. Browsers may have problems with pages
contain a huge number of form controls; at least some old browsers did. But
then the solution would be to split the form into smaller parts and chain
them dynamically - or maybe just simplify the form.
>Upon taking this into account, I decided I would stay with a text
control to be validated afterwards.
I hope you didn't think about using a select element _without_ server-side
checking. Never trust a smiling cat, or a form on a web page; expect to get
junk, deal with it, separating real submissions from spamming and other
attacks.
I thought about using a select statement to help a legitimate user enter a correct value,
not to ban a deliberate impostor.
>I feel that HTML lacks some
important abstraction here.
The HTML form model is a simplistic idea formulated and implemented in a
confusing way. The only reason for using HTML forms is that they are the
only reliable user interface for most interactions on the web.
I see.
I would use a single pop-up menu attached to all currency controls on the page
if I could use the client-side GUI directly.
It seems it is impossible with HTML because the select element cannot use an external set of options.
I am surprised that the designers never imagined a need for such a feature. It seems so obvious to me.

Chris
Feb 23 '07 #6

P: n/a
On Fri, 23 Feb 2007, Křiątof ®elechovski wrote:
A three-letter code like USD is a currency symbol to me.
It seems I am wrong and only those fancy curly hooked stroked
letters are currency symbols. Sorry for the misunderstanding.
A U+2133, a U+00A5, a U+0024, or a U+00A3
is all that makes the world go around.
Feb 23 '07 #7

P: n/a
In comp.infosystems.www.authoring.html message <er**********@news2.ipart
ners.pl>, Fri, 23 Feb 2007 11:56:41, =?iso-8859-2?Q?K=F8i=B9tof_=AEelech
ovski?= <gi******@stegny.2a.plposted:
>
The problem is the same code must be repeated each time a currency control is presented on the page,
and it can be presented several times.
If you can assume that javascript is available, you can write code to
generate repeated controls with identical or systematic or parameterised
identities. That code can of course be in an include file.

For example, <URL:http://www.merlyn.demon.co.uk/gravity4.htmhas two
identical buttons marked "Pop Code Up" - they pop different code. And
<URL:http://www.merlyn.demon.co.uk/holidays.htmhas several "Tabulate"
buttons which produce similar tables with different data (for the last
such, one can provide one's own data.

It's a good idea to read news:comp.lang.javascript and its FAQ. See below.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.
Feb 23 '07 #8

P: n/a
Scripsit Křiątof ®elechovski:
A three-letter code like USD is a currency symbol to me.
Well, it isn't; it is a currency code.

The point is that if you really wish to let the user specify a currency, you
should say so and not jump into conclusions on how to do that. For most
purposes, a currency should be specified by name. There are exceptions, but
there's too little information for consideration on whether they wapply.
Because the form has to do with transactions in various currencies.
Do you mean that a single submission of the form may contain transactions in
different currencies, as specified in direct user input. Possible, but rare.
>>Which means that
1) the page must be produced on the fly in order to be consistent,

What? Why?

Because changing the set of allowed currencies should require a
change in just one place,
That means that the page should be generated programmatically, not that it
should be created dynamically every time it is referenced.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Feb 23 '07 #9

P: n/a
In comp.infosystems.www.authoring.html message <4EDDh.985$Bb7.805@reader
1.news.saunalahti.fi>, Fri, 23 Feb 2007 17:21:53, Jukka K. Korpela
<jk******@cs.tut.fiposted:
>
I hope you didn't think about using a select element _without_ server-
side checking. Never trust a smiling cat, or a form on a web page;
expect to get junk, deal with it, separating real submissions from
spamming and other attacks.
You have a limited perspective.

One can code the use of select elements, etc., in perfect safety without
any server-side checking at all. For that, it is entirely sufficient to
return nothing at all to the server.

None of my pages returns anything to the server; about half of them have
input controls; and it appears that people do use them.

Though there's one (gravity4.htm) I might add checks to, since otherwise
a user could ask for a DIV 1e308 px high - or indeed infinite. But the
user's system should defend itself.

By the way, where's Alan - retired? He could have checked that page
much more fully than most people here.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Feb 24 '07 #10

P: n/a
Scripsit Dr J R Stockton:
>I hope you didn't think about using a select element _without_
server- side checking. Never trust a smiling cat, or a form on a web
page; expect to get junk, deal with it, separating real submissions
from spamming and other attacks.

You have a limited perspective.
Thank you.
None of my pages returns anything to the server; about half of them
have input controls; and it appears that people do use them.
We were not discussing anything like that but forms used to collect data
from the user and send it to some processing on some server.
By the way, where's Alan - retired? He could have checked that page
much more fully than most people here.
No idea. I tried to contact him after I noticed that his web pages are gone
(and don't exist in webarchive.org) but got no response so far. I have bad
feelings about this.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Feb 24 '07 #11

P: n/a

Użytkownik "Jukka K. Korpela" <jk******@cs.tut.finapisał w wiadomo¶ci news:YR****************@reader1.news.saunalahti.fi ...
Scripsit Křiątof ®elechovski:
>>>Which means that
1) the page must be produced on the fly in order to be consistent,

What? Why?

Because changing the set of allowed currencies should require a
change in just one place,
That means that the page should be generated programmatically, not that it
should be created dynamically every time it is referenced.
Well, I think I have come with a decent solution at last:
use <select<option>.USD.</option</selectin the XHTML source as the trigger.
Here is the XSLT code:

<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xhtml="http://www.w3.org/1999/xhtml" exclude-result-prefixes="xhtml"
<xsl:include href="x2htm.xslt" /
<xsl:template match="xhtml:option[string()=&quot;.USD.&quot;]"
<optionUSD </option<optionGBP </option<optionEUR </option
<optionJPY </option</xsl:template</xsl:stylesheet>
Mar 22 '07 #12

P: n/a
Scripsit Křiątof ®elechovski:
Użytkownik "Jukka K. Korpela" <jk******@cs.tut.finapisał w
wiadomo¶ci
Gesundheit!
Well, I think I have come with a decent solution at last:
use <select<option>.USD.</option</selectin the XHTML source as
the trigger.
It seems that you don't understand an essential problem. Currency codes are
meant for use in international banking business and comparable contexts, not
for use in normal user interfaces e.g. in the World Wide Web. People can be
expected to know the names of currencies they use, but codes are a different
issue.

It's still unclear what _is_ your problem.
Here is the XSLT code:

<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xhtml="http://www.w3.org/1999/xhtml"
exclude-result-prefixes="xhtml"
><xsl:include href="x2htm.xslt" />
<xsl:template match="xhtml:option[string()=&quot;.USD.&quot;]">
<optionUSD </option<optionGBP </option<optionEUR </option>
<optionJPY </option</xsl:template</xsl:stylesheet>
Well, if your server converts an <optioncontaining ".USD." (an odd
choice - "¤" would be much more natural) to a sequence of four <option>
elements, then you might have solved the otherwise presumably unamanageable
problem of changing a <selectelement in two or three places when you add a
currency. But then the original question was obscure, since you didn't
specify what server-side tools you a prepared to use.

And USD, GBP, EUR, and JPY were never meant for human consumption, just for
computers.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Mar 22 '07 #13

P: n/a

Użytkownik "Jukka K. Korpela" <jk******@cs.tut.finapisał w wiadomo¶ci news:9k******************@reader1.news.saunalahti. fi...
Well, if your server converts an <optioncontaining ".USD." (an odd
choice - "¤" would be much more natural) to a sequence of four <option
From the engineering point of view, the odder the choice, the less the odds of an unintended coincidence.
That is what all the programming languages do: they obfuscate identifiers in order that they do not clash
because the compiler/interpreter is not smart enough to detect and handle such a clash.
Things change, we have overloading, context-sensitive keywords and AppleScript dictionaries,
but these techniques are far from being clean.
It is a long way to go until computing machines will be able to resolve ambiguities in a predictable and reliable way.
Obfuscated code must not be completely obfuscated, otherwise you will not be able to remember how to write it,
but, on the other hand, it must not be natural for you to write it.
elements, then you might have solved the otherwise presumably unamanageable
problem of changing a <selectelement in two or three places when you add a
currency. But then the original question was obscure, since you didn't
specify what server-side tools you a prepared to use.
I thought XSLT is the standard way for managing XHTML code.
I got this impression from what I saw at the site of the WWW Corporation.
Besides, it is concise, convenient, declarative and ready to go.
The Microsoft environment uses it all the time, it is built into Visual Studio and Internet Explorer.
I am not a big fan of Microsoft but I have reluctantly accomodated to the environment.
Chris
Mar 22 '07 #14

P: n/a
Scripsit Křiątof ®elechovski:
I thought XSLT is the standard way for managing XHTML code.
You are trolling, right?
The Microsoft environment uses it all the time, it is built into
Visual Studio and Internet Explorer.
Mentioning IE sounds like you were thinking about leaving the operations to
the _browser_. Oh, we all know how good IE is at XHTML.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Mar 22 '07 #15

P: n/a

Użytkownik "Jukka K. Korpela" <jk******@cs.tut.finapisał w wiadomo¶ci news:Pn*******************@reader1.news.saunalahti .fi...
Scripsit Křiątof ®elechovski:
>I thought XSLT is the standard way for managing XHTML code.
You are trolling, right?
Trolling against whom?
Just exploring the possibilities.
>The Microsoft environment uses it all the time, it is built into
Visual Studio and Internet Explorer.
Mentioning IE sounds like you were thinking about leaving the operations to
the _browser_. Oh, we all know how good IE is at XHTML.
It will not understand the markup when it is presented as text/xhtml+xml
and it will not render it correctly if it is presented as text/html;
however, I can present it as text/xml with a reference to an XSLT stylesheet
that performs the transformation from xhtml to html I mentioned in the other post.
MSXML takes care of the transformation and MSHTML handles the result, which is pure HTML.
The process is rather slow and thrashy but the result is correct at the end
(all right, as correct as can be under MSHTML).
Chris

Mar 22 '07 #16

P: n/a
Update: the issue has been addressed
so I am not the only one to notice it as a lack.

WF2 says:

When a control has a list attribute, it specifies an element from which

to derive the list of author-specified autocompletion values for the

control.

The element specified is the one that would be returned when calling

getElementById() with the value of the list attribute as the argument,

if the returned value is an element node with either the local name

datalist or the local name select, and (for XHTML) with the XHTML

namespace. If the attribute is present but either specifies an ID that

is not in the document, or specifies an element that is not an (X)HTML

datalist or select, then it must be ignored.

-- http://www.whatwg.org/specs/web-form.../#the-datalist
Użytkownik "Křiątof ®elechovski" <gi******@stegny.2a.plnapisał w wiadomo¶ci news:er***********@news2.ipartners.pl...
I need a form control for the user to enter currency symbol.
A select control seems to be fit for that purpose;
but the problem is that the control must appear on the page several times
so the formula for page size gets bounded from below by number of controls times number of currencies.
Which means that
1) the page must be produced on the fly in order to be consistent,
2) the data to be transmitted can grow excessively because the page will contain much redundant information
3) it creates unnecessary strain upon the browser to maintain all these select elements.
Upon taking this into account, I decided I would stay with a text control to be validated afterwards.
Are those considerations correct? I feel that HTML lacks some important abstraction here.
Chris
Jun 13 '07 #17

This discussion thread is closed

Replies have been disabled for this discussion.