Form of...HTML!

If each user-defined setting has to be linked to an action, I don't see how you can avoid hardcoding. You could probably take advantage of the code that is already written though. That's how FamiliarFeeder ended up the mess it is now =)
 
slyz said:
If each user-defined setting has to be linked to an action, I don't see how you can avoid hardcoding.
Click to expand...

Perhaps hardcoding means the opposite of what I think it does? ;) I found a way around the problem, actually... my "list deeds" page is working, though it needs more features. :P I'm hoping to have a beta of the script up by the end of the weekend for testing by the braver souls out there.

The funny thing is, I've put a lot of work into what APPEARS to be very little in the way of changes, beyond the buttons. But technically, I've got enough separation of code & data going on that I could make the actual deed actions an include file, and never require the script itself to be changed. No point really in actually doing THAT, but it sure will make modifying the code later on a much less painful experience.
 
slyz said:
I meant having a long list of all the possible user settings and their associated actions, either directly in the script or in a data file.
Click to expand...
To veer, when I use "hardcoding" I am usually referring to the difficulty of changing something and the skills and tools required. Thus in The Good Old Days, if something had to be changed in the source code and the code had to be compiled and linked before it would function then that was "hardcoded". The alternative was to stick something in a data file that would be read. The code would not have to change and an end user could usually edit the datafile. Fast forward. Since editing scripts is much simpler than compiling code, the term has morphed into something that is more based upon the question of where something is changed. If I want to do something to a list of items and each item is called out in the script, then I call that hardcoded. If I read that list from a datafile then it is not.
 
I generally agree with fronobulax's definition, at least the way I think of it. If a script or program can perform brand new actions that I wasn't aware of while coding based on what the user enters & gets saved in a datafile, then I don't think of the actions as hardcoded (this is what I'm going for on this script). If, however, the part of my script that handles user action would need to be updated whenever new actions were going to be used, I'd think of it as not being hardcoded. It gets fuzzier when I talk about script actions that are custom-built; I'm currently thinking of them as not being "hardcoded" because the part of the script that calls & reports on the actions is agnostic toward these actions. They're defined in a standardized way, and could easily be part of an included file.
 
Jason, thank you for this script! I just started poking around a bit and it is awesome. :D

I have a question? How can one go about reloading/restarting the script from within the script?

I currently have a reset button that resets the form values to their initial values when clicked:

Code: 
writeln("<input class='button' type='button' name='reset' value='Reset' onclick='document.relayform.reset();'>");
The issue I'm having is after a failed submit, when an invalid input has been entered, a simple form reset is not sufficient to get things back to normal. Essentially, I want to make a button that reruns the script as if someone had just clicked on it's name from the drop-down menu.

What would be the best way to do this?
 
Doing a clear(fields) early enough in the processing of the page should make it behave just like the initial load, if I'm understanding you correctly.

A simple link to the page itself (rather than any sort of form submission) should also work, something like:
"<a href='" + __FILE__ + "'>Reset everything!</a>"
 
If I'm not mistaken, __FILE__ will return the filename, that is, ending with .ash. Is this a bug or intentional feature?

EDIT: As such, you'll probably want something "__FILE__.replace_string(".ash",".php")".
 
Last edited:
Erm, okay, it apparently works with relay UI scripts, but not with relay override scripts (the ones that override actual KoL pages). Interesting.
 
If a script is overriding an actual KoL page, then it pretty much as to have a specific name - there's no advantage in making it adapt to a name change by the user, because the script would no longer be usable in the first place.
 
Gah! I've got a weird issue, but I'm probably just being dumb...

I'm using write_textarea() to create a field that users can paste info in to be parsed by my script. However, a lot of the lines of text include addition, and I can't for the life of me figure out how to escape the plus signs before they're submitted with the form... anyone have any pointers?

Edit to add:
It's worth noting that I don't think a validator can work, since by that point mafia has already turned the plus signs into spaces... Is the only solution here a javascript on_click() event for the submit button that first escapes plus signs in the field?
 
Last edited:
As far as I can tell, no, because in submitting the form, mafia automatically turns the plus signs into spaces (which decodes as a space).
 
Theraze said:
Does %2B work to encode it?
Click to expand...

When do I encode it? Are you saying that I should tell my users that the textarea they're typing into should be pre-encoded to use %2B instead of plus signs? As far as I'm aware, short of using javascript or the like, there's no way for me to act on the contents of a textarea (or text input) until it's already made one trip through via the form submit, at which time all of the plus signs have turned into spaces.

Unless I'm getting the wrong impression somewhere, I think mafia should be handling the contents of a textarea or text input differently than it does with the rest of text passed along as a parameter, and escaping the plus signs first.

But if I'm wrong, and just don't understand how this is supposed to be handled, please tell me.
 
StDoodle said:
Unless I'm getting the wrong impression somewhere, I think mafia should be handling the contents of a textarea or text input differently than it does with the rest of text passed along as a parameter, and escaping the plus signs first.
Click to expand...
KoLmafia acts on URLs that it receives from the browser. How can it tell that the parameter the browser submitted came from a textarea?

I don't really understand your issue. You are presenting a textarea to be displayed & processed by the browser, and you prefill it with ... something ... and the browser submits a form with whatever is in the textarea - either your prefilled text or what the user typed.

Presumably, the browser URLencodes the contents before submitting it. And a recent change that I submitted should make KoLmafia NOT URLencode browser-submitted URLs again.

So, you need to make sure that what you prefill the text area with looks just like what the user types, insofar as the browser processess them both identically before submitting the URL to KoLmafia.

Or am I misunderstanding something here? Help me understand, please.
 
I dunno... it's a bit confusing, since you can't meaningfully test some of the encoding functions on the cli (it appears to interpret entities before running the ash function, at least based on what's shown... but since the gCLI is html-like it's really hard to tell).

All I know for sure is that if I put a plus sign in a textarea, it turns into a space before I can do anything about it. If this is a Firefox issue, I don't know what to do... but apparently KoL has a workaround, as kmails containing a plus sign are roundtripped just fine. But I suppose it's possible they use javascript to check the user agent & perform the same switcheroo that I'm doing now.

For reference, here's a summary of what I do:
PHP: 
import "htmlform.ash";

void main() {

    write_header();
    finish_header();
    
    attr("id=\"copypasta\"");
    write_textarea(fields["copypasta"],"copypasta","",100,30);
    write_button("parseHistory","Load");

    string h = fields["copypasta"];
    for x from 0 to length(h)-1 {
        print(char_at(h,x),"purple");
    }

    finish_page();
}
if the text I type into the textarea is:
Code: 
1 + 2 = 3
I can't seem to find a way to NOT end up with:
Code: 
1   2 = 3
Unless I make use of javascript.

Edit to add; tested in Firefox 3.6.13 & Internet Explorer 8
 
Last edited:
form_fields() currently assumes that all fields are double-URLencoded; that being no longer true would certainly explain the problem. I'll look into it...

Also, a htmlform usage note: passing fields["copypasta"] as the initial value parameter to write_textarea() is pointless, that parameter is only used on the first pageload of your script, at which time there are no fields.
 
You must log in or register to reply here.
Back
Top