Parsing form arrays In Go - go

I need to be able to to something like this in my HTML forms:
<form method="POST">
<input type="text" name="cart[items][1][qty]" value="3"/>
<input type="text" name="cart[items][2][qty]" value="7"/>
<input type="submit" value="Update cart"/>
</form>
Problem is, if I print out r.Form (after r.ParseForm() of course!), it is revealed that Go parses it as separate strings - not the nested hierarchy I'm after.
I was able to find an alternative in http://www.gorillatoolkit.org/pkg/schema , however I'd be very interested in finding out if there's a native/vanilla solution, since I usually tend to try an limit external packages, if I don't need them.
To be more specific, in the above example I'd expect to get the entire nested slice/map, when I do r.Form["cart"], but that's obviously not how it works. The value I get is [].
Is using schema the best solution for this, or is it possible to achieve exactly what I'm after? If then, how would you do it? :-)

This syntax is actually is not standard de jure. It is used sometimes when the site backend is powered by PHP, but not very frequently.
I think that there is no reason for the standard Go library to support it.
Native solution exists in a sense that you have all the tools to implement it: string manipulations, etc. However, nowadays there is no point to implement it as you always can send task-specific JSON.
And even you insist on creating it, it will be not as simple as it is in PHP because Go is typed language and PHP is not. And accessing such structure will be not easy as you will have to implement it as map[string]interface{}, which is not the proper Go way (the Go way, BTW, is to typed data structures).

Related

Laravel 7 Sanitizing Form Data

I'm new to Laravel 7 and wondering if there's an out-of-the-box, elegant solution to sanitizing HTML form inputs? Or maybe a trusted third-party package I can download that you recommend? This is for data I will store in a database. Thanks for any help.
One recommended out-of-the-box way of sanitizing data is using the filter_var function that comes with PHP in conjunction with the different sanitize filters. By the way, this is also a cool way to validate input, take a look at the types of filters to find out more.
When working in Laravel projects, I like to use voku/portable-ascii library, because it's already a framework dependency. It is a nice assortment of functions to clean input, remove non-printable characters, and to generally transform any input into ASCII, complete with transliteration and whatnot. It's not always perfect, but usually good enough and gets the job done.
It always depends on what you want to sanitize, how, and why. In many situations you do not need to sanitize the input at all if you stick to the best practices. When working with Eloquent or the Query Builder, your data is automatically escaped and on retrieval, when you output it e.g. via {{ $data }}, they will be properly escaped too.
There are some situations where you should be more cautious, especially if you are handling the raw user input yourself and probably passing it to the system in command line parameters, filenames or such. In those cases it is usually a good idea to be as restrictive as possible and as permissive as necessary. Sometimes a good old preg_replace('/[^0-9A-Z_-]/i', '', $subject) is just the right choice. If you want to be as permissive as possible, give the suggestions above a try.

How to create a search bar with 2 inputs

I'm still kind of new to this and although I've searched the web (a lot) I can't seem to find any info on how to code a double input search bar.
My example being; one search bar for 'location' and the second for the 'product' they are looking for displayed inline with a single button to search.
Something like this:
https://www.gumtree.com/
If anyone could point me in the right direction or supply any information I would be very grateful,
Thank you
It seems you're learning the bases of interactions with users.
Basically, you need two things:
a form in your HTML page: <form method="GET|POST" action="YOUR_URL">, including text input fields: <input type="text" name="YOUR_NAME"> and a submit button: <input type="submit">
a script server-side, at URL "YOUR_URL", which will be called when a user submits the form. This is where you define appropriate actions to be taken with user entered data.
Assuming you'll be scripting in PHP (but there are other languages available, see what's installed on your server), your script has access to the returned form fields values in following arrays:
. $_POST (if sent from a method="POST"form),
. $_GET (if method="GET") and
. $_REQUEST (forget it for now).
For example, if your form method is POST, you'll get the value of <input type="test" name="email"> in your PHP script like this: $userMail = $_POST['email'];
It wouldn't make much sense to give further explanation here, there are plenty of tutorials and documentation on the web, now that you know what you're looking for ;-)
For example:
http://php.net/manual/en/tutorial.forms.php (official php doc, short but efficient)
http://www.w3schools.com/php/php_forms.asp and following chapters (easy start point).
Once you've got it working, pay special attention to unawaited characters that user could type and that could interfere in your code (especially quotes and special characters like "<>&"...).
Keywords: escape string, addslashes, htmlspecialchars, mysql_real_escape_string, etc... depending of what you then do with this data.
And if you're data is used in database queries, you should also check for keywords: sql injection, prepared statements.

Where to find documentation for form field types?

I'm getting frustrated with my own inability to find a source of information regarding what options / attributes are to be used when defining the XML file for a form in a component.
The file I'm talking about might be located in /administrator/components/com_report_wiz/models/forms, as an example. It defines the field to be used in the admin form for a component. I used a component creator to build a sample component as a learning experience. It created an xml file in that folder which has fieldset elements that then contain field elements. This us then used with the getLabel and getInput methods of JForm to generate the form shown in the admin interface. That's terrific!
But, after spending hours Googleing everything I could think of, I still can't find any reference that shows what types of fields are available, and their parameters/options. I've found lot's of tutorials and such regarding creating custom field types, and that's been interesting.
In the file I'm looking at, for example, the following creates a simple text input field in the form:
<field name="rpt_appname" type="text"
label="COM_REPORT_WIZ_FORM_LBL_REPORT_RPT_APPNAME"
description="COM_REPORT_WIZ_FORM_DESC_REPORT_RPT_APPNAME"
default="None"
maxlength="100" />
I would love to find some reference that lists the different possible values for the "type" attribute, and the parameters that can be used with each.
I'm beginning to think I'm dumber than a box of rocks since I can't figure out where to find information on some of the most basic parts of Joomla! development. The docs that are auto-generated from the code are less than helpful to me since they don't explain the parameters to functions. It's nice to know what parameters a method/function expects, but it's more helpful to understand what those parameters are and contain.
The tutorials have been helpful, but are mostly too basic to use for more advanced features, or at least as a source of information. They have been great, and I really appreciate the effort the authors have put into them, but now that I've gone through them, I find it difficult to discover the info needed to write a proper, complex component. With a system as complex and extensive as Joomla, it seems that there should be a place to find out how to use the wonderful abilities it provides without having to resort to reading the source code.
Any suggestions about where to search, search terms would be greatly appreciated!!
The first starting point would be to look at the Joomla! Documentation - I know sometimes it is frustrating to use it, but give it a change. It gets better and better as we speak.
Typing in the search box text will get you to the page Text form field type. Also in the documentation you will find a list of Standard form field types.
My favourite way of doing is directly inspecting the code in JOOMLA_ROOT/libraries/joomla/form/fields for the needed form type. You get to see there all the parameters and quicklier understand why something does not work the way you think it should work.
Since you are new to Joomla, your questions might get a better attention at the Joomla! Q&A site.
Hope this answers your question.

Is it good practice to end coldfusion self-closing tags with "/>"?

In HTML, I was always taught to close self-closing with a "/>". For example "<br />", "<input type='button' value='myButton' />", etc.
In Coldfusion, though, it seems to be standard to just never close these tags. I'm constantly seeing code like:
<cfset myVariable = someValue>
<cfset myOtherVariable = someOtherValue>
etc.
Is this bad code, or is it commonly accepted? I've seen it almost anywhere that I've seen coldfusion code. Is there any benefit to closing these tags, or is it fine to leave it as it is?
Because there's no official coding standard for CFML, it's up to you whether to use these. Same as using uppercase/lowercase tags.
Personally I love to have my code beautiful and readable, so I'm always using this syntax for single tags.
But there is at least one techincal difference: custom tags. Let me show this by example.
Consider following custom tag:
<cfif thisTag.ExecutionMode EQ "start">
started<br/>
</cfif>
running<br/>
<cfif thisTag.ExecutionMode EQ "end">
ended<br/>
</cfif>
Now these two types of invokation:
<p><cf_demo></p>
<cf_demo>
<p><cf_demo /></p>
<cf_demo />
And here's the output:
<cf_demo>
started
running
<cf_demo />
started
running
running
ended
Second syntax is equivalent of <cf_demo></cf_demo>.
Possibly there are more differences, but I can't remember any at this moment... :)
It doesnt matter, it is also not necessary in html unless it is xhtml.
I agree with the last comment.
I hate those single tag closes.
It's pointless and not a coding standard for CFML.
It started appearing when xml became popular due to it's strict tag syntax and people assuming it was correct for CFML. CFML isn't HTML. Treating it as such is really in itself lazy coding. I also think it looks more beauiful without the unnecessary closing /> :)
but that's me for you.
I also dislike {} spread on to new lines for each bracket. I guess it's just personal preference.
I never used to use the /> until i started using Dreamweaver CC and the auto close only works if you close the tags somehow

Alternative solution for <fr:currency>

We have performance issue using for controls which gets number in the format of $dollars as input. In-order to over come this performance issue we used instead of and implemented the following calculate functionality in the bind of the control.
<xforms:bind id="Amount"
nodeset="instance('sample_form')/Amounts/Amount"
calculate="if (. !=0)
then format-number(xs:double(.),'$#,##0.000')
else ."/>
But the problem with the above code is, its converting the control's value into String type which leads to error in the controls which has its value dependent on this. Kindly provide me a solution for the above problem or provide a better recommendation to handle this situation.
If you only want to show the formatted value (which I assume to be the case since you are thinking of using a calculate), then you could put that expression you have on the calculate inside an:
<xforms:output value="..."/>
If you need both input and output, and you'd like the value stored in your instance to be just the unformatted number, then I don't think there is an easy way around using <fr:currency> other than somehow reimplementing the functionality provided by <fr:currency>. If you need both input and output, then I would recommend you to investigate this further to find, and then solve, the source of the performance issue.

Resources