RPTools.net

It would be useful if there was another input function that took fields as parameters or took a json object or array of objects.
Having an input like this will allow to use special characters that will mess with the parsing of the string to get the input properties.

There could even be a short hand version just using an array where the properties are determined by position.
Although, you could probably do detection based the data to determine the method I suggest a whole new function like "json.input".

I support this. The input function is valuable and may get a facelift with JavaFX. The current input works well but the string manipulation is sometimes pretty onerous.

aliasmask wrote:

Code: Select all

input(prop,value,prompt,type,options)
input(json.set("{}","prop","varName","value",0,"prompt","Enter Value","type","text","options","value=string"))
input(json.append("",
   json.set("{}","prop","varName","value",0,"prompt","Enter Value","type","text","options","value=string"),
   json.set("{}","prop","varName","value",0,"prompt","Enter Value","type","text","options","value=string"))
) 

Given the option with just using the array method, I would probably never use the input with 5 parameters or the json object method. So, if it makes someone's life easier just doing the below method is all I'm looking for.
Also, for the LIST type, accepting another json array would be ideal as well. I would like for PROPS to accept a json object. It would also be nice if it can return it as json object. Perhaps by adding it to the PROPS options or just make a new type for JSON. PROPS has a set field width and it would be nice if that can be adjusted in the options as it is done with the TEXT option. The TEXT option when blank should display and return an empty string rather than 0 (really big pet peeve).

I really don't like the way images are handled with Input(). I say just let the HTML handle it rather than plucking it from the string. We wouldn't need the size option either. When an image is in the value position, you can't have any alt text on the image because the prompt field suppresses it, even if you don't use the span option.

As it turns out, there is already code that does some of this including some extra stuff: http://forums.rptools.net/viewtopic.php?f=60&t=22577

Any chance of implementing this?

The code is MIA, unless Az has an archived copy. In any case, it's probably vapor-ware.

JamzTheMan wrote:The code is MIA, unless Az has an archived copy. In any case, it's probably vapor-ware.

Well, Lee is the lead programmer for the MOTE team and they have input() working with jsons. Looks like their revving up for the final 1.6 release once they figure out an issue with OS X. Hopefully, they'll share their code at that point.

Don't hold your breath (we're not).

I saw Az asked for it last month per GPL and they claim Apache 2.0 license and will release it when MOTE is "established". They want to make sure that we just don't integrate all their "cool stuff" and people just move back to MapTool or some other build I guess.


Aside from that, unless it's a quick hit, we have a few other things we're trying to get out the door first. And FX is one of those which may open a lot more doors with better HTML integration...

JamzTheMan wrote:I saw Az asked for it last month per GPL and they claim Apache 2.0 license and will release it when MOTE is "established". They want to make sure that we just don't integrate all their "cool stuff" and people just move back to MapTool or some other build I guess.

I'm sure this is in the back of their mind since they failed to significantly migrate users from Maptool to Mote, but it seems like their answer to that was to re-position Mote as a gateway to their commercial VTT ("Sift") via their "Sandstorm VTT Cloud Services"... and hope that Mote users would, eventually, choose to migrate to Sift.

What they *should* do is release the source for Mote (as they said they would) and encourage a merging of Maptool and Mote with ONE expectation: Continued Sandstorm support/integration.

If Sandstorm support could be integrated in a non-invasive and optional way (i.e. it's not skimming user data and has no dependencies or security risks when not being used) I don't see why the MT community would fight the option. There are users that would like to have cloud service support... and if the integration was somewhat policed by MT developers and its open-source bloodline then I think there would be little resistance. This would free the Mote guys up to focus their efforts on Sandstorm, Sift, and maintaining the Sandstorm bridge to MT.

Otherwise, Mote on it's own will remain a fringe, poorly adopted VTT, despite having some desirable features.

Walling off Mote from the MT community and failing to open-source it (as promised) has only alienated much of the MT user base. But I don't think it has to be an unsalvageable position.

I agree with most of that, but in reality it's not even worth discussing. There is 0 interest from the MOTE team to work with the MapTool team in any capacity.

It's two completely different mindsets obviously. Theirs is to own IP and protect it and make money, ours is open source for community use for anyone to contribute to.

Back on topic. A stronger input() macro function would be nice and we'll keep an eye on it, but we may have other/better alternatives in the coming future.