Hi.
I am attempting to make a reusable grid using a passed ri! of type Any with a cdt type being passed into it.
Optionally I am thinking about passing in a list of column names so I can specify the order the grid displays columns in.
From there I wanted to do a foreach generating the N grid columns using field names and types grabbed from the passed cdt..
1.I don't know if there is a way to get a list of all the fields a cdt type has.
2. I am unsure if there is a way to get their types.
Any tips?
Discussion posts and replies are publicly visible
roberts0186 said:I don't know if there is a way to get a list of all the fields a cdt type has.
a!keys() -->
FWIW, this sounds like a neat exercise but I don't expect that this level of "reusable grid" will be worth the effort you put into it, in a production-usable sense. The read-only grid component is already easy enough to configure that it can basically just be designed as-needed, or if you have a use case where you need a bunch of different interfaces to use a similar one, then you can set up a reusable one under that slightly-narrower scope.
There are other bits of functionality I want to add in that increase its worth if reusably programmed.
Did not include them here was I wanted to keep the question simple.
I support Mike point of view. Creating a reusable component this close to the original will probably not help much.
Over the years I developed quite a few reusable components. In case you are interested, I would be willing to support you. Which functionalities do you plan?
I was brainstorming filter designs. Most of these are oriented around uncluttering filter usage without forcing the user to drill into hidden filters. When i say a filter I imagine something in the format below.
[CreatedBy]:[____enterTextHere_________________]
1. A filter that toggles the filtered field based on a set of autogenerated buttons in a line above your column names, named after the column names. See below
[CreatedBy] [CreatedDate] [Serial]
[______Enter text here_____________]
-I wasn't a fan of how cluttered things get with a dozen _Enter text heres__ normal filters in mass.
-Even with hiding them when not in use, I feel they either take too long to drill into or too many are shown at once with larger queries.
-Buttons would reduce this space usage and allow faster filter choosing and cleaner space. This could cover about twice the number of column names in the space a normal filter uses.
- Design decision with this is only one thing is filtered on at a time.
2. Most users probably only filter on a few columns. A way to let users choose their own configuration of normal filters might be useful. Add on filters by giving them a multi selectable dropdown with column names to enable/disable.
-I would like the dropdown autogenerated.
Some features seem too complicated as I type them out like letting a user create a preset that exists each time they log in. Plus I feel they would require creating tables for the info and would definitely stop the generic-ness of the rule I has wanted.
Ex.
(Kyle sets it up so he sees ID and FinishDate filters) (Marie sets her preset to see filters for ID and CreatedBy)
Anyway I think this is all a bit beside the point. Came here looking for ways to extract column info from things like datasubsets to automate the above. Thats what I want tips on here.