You are viewing limited content. For full access, please sign in.

Question

Question

javascript second to last field in table selector

asked on November 4, 2018 Show version history

I have searched all of google for a second to last table field selector, where the last table selector is used like this:

$('.tableClass').find(".inputClass:last input")

The only other methods that seem to exist are nth-last-child and nth-last-type where type is of the child. When using the word child in the statement, like the following, the entire concept breaks down and the values start getting dropped into random fields within the table.

$('.tableClass').find(".inputClass:nth-last-child(2) input")

Here is the documentation on using the :last selector. This has nothing to do with accessing children.

https://www.w3schools.com/jquery/sel_last.asp

Suddenly, all the documentation regarding second to last is forcing the use of children. Where did I drift off?

https://api.jquery.com/nth-last-child-selector/

https://api.jquery.com/nth-last-of-type-selector/

 

0 0

Answer

SELECTED ANSWER
replied on November 4, 2018

Hello,

what you need to do is find the second to last row and then work with your input, you can do it as follows :

 

 

$('.tableClass tbody').find('tr:nth-last-child(2)').find('.inputClass input')

this should work fine.

 

Regards,

Maher.

 

0 0
replied on November 5, 2018 Show version history

Edit: Nevermind that works perfectly. Forgot to add the .val back in.

I would never find that from the documentation online, javascript is such a strange language.

Thanks for the help!

0 0
replied on November 5, 2018

You should also research JQuery functions when looking for things like this; a lot of the solutions posted here, including the one above, are using the JQuery libraries so you might not find as easy of a solution with vanilla JavaScript.

0 0
replied on November 6, 2018

Will do thanks. It seems I need to understand DOM more than javascript. It's always accessing the controls within forms that seems to throw me off, never seems to match up with what others are recommending when discussing general web development.

0 0
replied on November 6, 2018 Show version history

The key difference in Forms is that the selectors we rely on tend to reference the parent containers rather than the elements themselves. In general web development threads you're typically dealing with sites that can be fully edited-customized, but in Forms we have a layer of overhead to consider.

For example, when I add a custom class to a field called "testClass" and reference that using $('.testClass') I am actually getting the div around the input (although it seems complicated, I think this is actually a good design because we can use CSS to customize labels too and not just the fields/inputs).

A good way to look might be that most examples you find online are navigating a DOM that contains a bunch of houses with their own address; they use the ID attribute or class assigned directly to an input, select, etc.

However, in Forms, it is more like navigating a neighborhood of apartment buildings; after we find the right address, we still need to provide the equivalent of a unit number to get where we want to be.

Think "123 Main Street, Apartment 101"

So, I use $('.testClass input') or $('.testClass select') instead of just the class because it gets me to the right container and grabs the desired DOM element.

1 0
replied on November 6, 2018 Show version history

Hey that's helpful. I always thought it was silly to reference the type each time you reference the variable. Coming from a C# background, I reference the type on declaration, not every time I call the thing. That explains why.

The most common javascript requests are not that complex, they just need to run some calculations or verification on some fields. Writing the code is simple, but the crazy amount of methods and ways to access the field values really slows things down.

I would like to write a library that allowed something like this. Where "$$" finds the field, gets the type, and returns/sets the value. This would make is easier to do basic functions quick and even train other semi-programmers who are not familiar with the DOM layer.

$$myTotalFieldClass = $$someFieldClass + $$someOtherFieldClass

var iNeedThisValue = $$theClassOfTheValueINeed

I did figure out how to write a really cool function that returns a table and all it's values in a single variable. This has been super helpful, no more foreach loops just to get or total values.

var myTable = GetTableValues('tableClass', 'column1Class', 'column2Class', 'etc');

After running this one line, you can access each column as an array with myTable.columnClassName

No need to specify types either.

0 0
replied on November 6, 2018 Show version history

Technically, anything using $ is already using the JQuery library, which adds a LOT of functionality to simplify/enhance JavaScript.

I think the reason it seems so limited compared to C# (also my primary) is that JavaScript is a scripting language designed to run in a browser; this means limiting overhead is crucial, and cross-browser compatibility can introduces complications.

The only challenge with something you are proposing with the $$ idea is that $ can still reference a field directly. Additionally, the $ approach in JQuery technically returns a collection, which is why you need to use .get(0), [0], or something along those lines before you can use them for some vanilla JavaScript functions.

As an example, in Forms $('#Field1') would grab the input, textarea, etc., directly without needing to specify the DOM element type; the only reason people tend not to do that here is that the custom CSS classes are easier to interpret, IDs are not as obvious, and the IDs for tables/collections cause issues.

It is all a matter of preference really. The trick for identifying the ID of the input is to look at the #q value of the container; #q1 > #Field1, and so on., or you could just inspect the page. However, this same rule doesn't apply to tables/collections, which use things like #Field1(1), #Field1(2), etc. that seem to break JQuery selectors.

0 0
replied on November 6, 2018

I have not figured out any way to assign ID's in Forms so I have been sticking to class names exclusively. I like class names over IDs though, since you can assign more than one class to a field which can be useful for clarification when one field serves multiple roles. This also allows the user to quickly change the role of fields without updating any code.

0 0
replied on November 6, 2018

Forms already assigns IDs to most elements, so there's not really any room for customization there anyway unfortunately.

I like classes for the same reason, easy to manage, grouping fields for different functions, just overall easier than keeping track of a bunch of auto-generated IDs.

0 0

Replies

You are not allowed to reply in this post.
You are not allowed to follow up in this post.

Sign in to reply to this post.