Scripts with user interfaces
- Thread starter jasonharper
- Start date
coderanger
Member
For those who might not have thought of doing so, you can write a css section onto the page to save some effort on styling everything.
And for JH, it would be awesome if functions to write specific html tags included optional class / id input.
Yep, and you can also pull in the KoL CSS (what little there is) and use their styles.
jasonharper
Developer
I'm not planning on automatically loading KoL's stylesheet, as I don't think it's necessarily a benefit to have scripts that look exactly like the game. There have already been cases of people posting things on the KoL Wiki that are actually KoLmafia behavior, let's not make things any worse...
It's not practical to have optional parameters for every possible HTML attribute that is meaningful for a particular tag; some of the tag writers are going to have a dozen overrides already, just to handle all the datatypes you might want to use them with. My plan is to have a generic attr(string) function; the string(s) you provide will be inserted at the appropriate point by the next tag writer you call.
It's not practical to have optional parameters for every possible HTML attribute that is meaningful for a particular tag; some of the tag writers are going to have a dozen overrides already, just to handle all the datatypes you might want to use them with. My plan is to have a generic attr(string) function; the string(s) you provide will be inserted at the appropriate point by the next tag writer you call.
StDoodle
Minion
I also wouldn't auto-load KoL's stylesheet; it's not that difficult to add it in yourself if you want to use it. But if you really want to style with CSS, you're probably better off working from scratch anyway.
That's a good point about parameters, especially when it comes to weird stuff (src in images, misc. legacy table junk that's still required 90% of the time). As long as I can specify both the attribute and its value, that will make me plenty happy to have a function (or two) dedicated to doing so.
Really, I'm highly anticipating the rollout of additional RB funcitons; I wanna play!
That's a good point about parameters, especially when it comes to weird stuff (src in images, misc. legacy table junk that's still required 90% of the time). As long as I can specify both the attribute and its value, that will make me plenty happy to have a function (or two) dedicated to doing so.
Really, I'm highly anticipating the rollout of additional RB funcitons; I wanna play!
bumcheekcity
Active member
I'm having a play with this right now. Is there a reference list of the new relay functions up anywhere?
Also, for people writing relay scripts, remember it's not necessary to type, for example:
It's easier on the eye and more readable to write:
In other words, using double quotes for strings in ASH, and single quotes to indicate arguments in HTML.
Also, for people writing relay scripts, remember it's not necessary to type, for example:
Code:
writeln("<input type=\"hidden\" name=\""+name+"\" value=\""+value+"\" />");It's easier on the eye and more readable to write:
Code:
writeln("<input type='hidden' name='"+name+"' value='"+value+"' />");In other words, using double quotes for strings in ASH, and single quotes to indicate arguments in HTML.
jasonharper
Developer
The new functions (all three of them) are described in the r8318 changenotes.
Sorry folks, my htmlform library has run into a few snags along the way...
* I added the __FILE__ constant specifically so that a library could write the form tag without having to know the name of your script - but in a library, __FILE__ obviously and unavoidably refers to the imported file, not the main script. D'oh! It looks like <form action=""> works to submit a form to the same URL it came from, although there's some controversy over whether that's an acceptable practice.
* I've found several cases where ASH data types can't be converted to a string and back, either due to lack of a to_TYPE(string) function, or bugs in parsing specific values. The goal is that if you can enumerate a set of values in a plural typed constant, you can make a <select> out of it with one line of code.
* There's a HotStuff puzzle in progress. Nobody told me there was going to be a HotStuff puzzle!
Sorry folks, my htmlform library has run into a few snags along the way...
* I added the __FILE__ constant specifically so that a library could write the form tag without having to know the name of your script - but in a library, __FILE__ obviously and unavoidably refers to the imported file, not the main script. D'oh! It looks like <form action=""> works to submit a form to the same URL it came from, although there's some controversy over whether that's an acceptable practice.
* I've found several cases where ASH data types can't be converted to a string and back, either due to lack of a to_TYPE(string) function, or bugs in parsing specific values. The goal is that if you can enumerate a set of values in a plural typed constant, you can make a <select> out of it with one line of code.
* There's a HotStuff puzzle in progress. Nobody told me there was going to be a HotStuff puzzle!
bumcheekcity
Active member
Thanks, Jason. With respect to <form action="">, the HTML specification is that behaviour is undefined if action is not a URL, but all browsers have sent the form back to the same page, so for practical terms, it's fine to use it.
Hotstuff?
Hotstuff?