Handling choice lists

[John Moore]

There's a kind of grey area somewhere between hard-coding enums and full-blown dynamic data which I'm trying to find the most elegant solution for, and as it's a common, possibly universal, requirement, I'd be interested in hearing how others deal with it in Grails. I'm talking about choice lists - simple string lists which can be used to populate selects, etc.

In the current app I'm working on I've started with loads of little single property classes - EventType (with a single string property, 'eventType') ; Profession (with a single string property, 'profession'), etc. These tables are never going to contain more than a dozen or so rows each, and were it not for the fact that it is almost certain that new types will need to be added, these would be ideal candidates for enums.

But the lists do in fact need to be editable by a system administrator, so that new items can be added. I'm checking for their existence and creating them if necessary in Bootstrap.groovy. In some ways it would make more sense to have a single ChoiceList class, with a 'hasMany [items:String]' (rather than lots of invidual classes), but that exposes me to one of the difficulties of this grey area -  if they WERE hard-coded enums,  I could count on their being there when I required them in my code, but as I've handed over responsibility for the data to someone else, I have to constrain what that person can do with the data, and I couldn't allow them to actually create or delete ChoiceList objects themselves, only the items belonging to them. I find this area of something in data which I can depend on in code to be a messy one, which gives me an uneasy feeling, although I suppose it's inevitable. Separating the lists out into their own tables is messy in its own way but at least it helps me with this particular difficulty.

So, as I mentioned, as this is an extremely common requirement, I'm wondering how others deal with it?

[Jason Davis]

I'd probably make a class like

SimpleProperty{
 String key, val
}

and use that.

On Tue, Feb 28, 2012 at 12:05 PM, John Moore <[hidden email]> wrote:

> There's a kind of grey area somewhere between hard-coding enums and
> full-blown dynamic data which I'm trying to find the most elegant solution
> for, and as it's a common, possibly universal, requirement, I'd be
> interested in hearing how others deal with it in Grails. I'm talking about
> choice lists - simple string lists which can be used to populate selects,
> etc.
>
> In the current app I'm working on I've started with loads of little single
> property classes - EventType (with a single string property, 'eventType') ;
> Profession (with a single string property, 'profession'), etc. These tables
> are never going to contain more than a dozen or so rows each, and were it
> not for the fact that it is almost certain that new types will need to be
> added, these would be ideal candidates for enums.
>
> But the lists do in fact need to be editable by a system administrator, so
> that new items can be added. I'm checking for their existence and creating
> them if necessary in Bootstrap.groovy. In some ways it would make more sense
> to have a single ChoiceList class, with a 'hasMany [items:String]' (rather
> than lots of invidual classes), but that exposes me to one of the
> difficulties of this grey area -  if they WERE hard-coded enums,  I could
> count on their being there when I required them in my code, but as I've
> handed over responsibility for the data to someone else, I have to constrain
> what that person can do with the data, and I couldn't allow them to actually
> create or delete ChoiceList objects themselves, only the items belonging to
> them. I find this area of something in data which I can depend on in code to
> be a messy one, which gives me an uneasy feeling, although I suppose it's
> inevitable. Separating the lists out into their own tables is messy in its
> own way but at least it helps me with this particular difficulty.
>
> So, as I mentioned, as this is an extremely common requirement, I'm
> wondering how others deal with it?
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Handling-choice-lists-tp4429168p4429168.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Mick Davis]

I've found that there is almost always a need, even for these simple small code/reference tables to have the ability to make an item "disabled" or even effective dated.  What I mean by effective dated is that there are start and end dates associated with each value to define when the value is allowed to be selected.  Once you start incorporating requirements like this it has to be database/table driven.  Then about the only remaining question is whether to use a database table per table, or put all of them in one table with a "table type" field.  I usually go with the former.

I don't even attempt to hard-code enums anymore.  At the very least I've found that users want to be able to change the display value.

Mick

On Tue, Feb 28, 2012 at 2:05 PM, John Moore <[hidden email]> wrote:

There's a kind of grey area somewhere between hard-coding enums and
full-blown dynamic data which I'm trying to find the most elegant solution
for, and as it's a common, possibly universal, requirement, I'd be
interested in hearing how others deal with it in Grails. I'm talking about
choice lists - simple string lists which can be used to populate selects,
etc.

In the current app I'm working on I've started with loads of little single
property classes - EventType (with a single string property, 'eventType') ;
Profession (with a single string property, 'profession'), etc. These tables
are never going to contain more than a dozen or so rows each, and were it
not for the fact that it is almost certain that new types will need to be
added, these would be ideal candidates for enums.

But the lists do in fact need to be editable by a system administrator, so
that new items can be added. I'm checking for their existence and creating
them if necessary in Bootstrap.groovy. In some ways it would make more sense
to have a single ChoiceList class, with a 'hasMany [items:String]' (rather
than lots of invidual classes), but that exposes me to one of the
difficulties of this grey area -  if they WERE hard-coded enums,  I could
count on their being there when I required them in my code, but as I've
handed over responsibility for the data to someone else, I have to constrain
what that person can do with the data, and I couldn't allow them to actually
create or delete ChoiceList objects themselves, only the items belonging to
them. I find this area of something in data which I can depend on in code to
be a messy one, which gives me an uneasy feeling, although I suppose it's
inevitable. Separating the lists out into their own tables is messy in its
own way but at least it helps me with this particular difficulty.

So, as I mentioned, as this is an extremely common requirement, I'm
wondering how others deal with it?

--
View this message in context: http://grails.1312388.n4.nabble.com/Handling-choice-lists-tp4429168p4429168.html
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Wayne Fay]

> I've found that there is almost always a need, even for these simple small
> code/reference tables to have the ability to make an item "disabled" or even
> effective dated.  What I mean by effective dated is that there are start and
> end dates associated with each value to define when the value is allowed to
> be selected.  Once you start incorporating requirements like this it has to

Agreed entirely. I haven't needed the effective dating but I do use active.

As an example, I have a STATUSES table that looks like:
id, object, name, displayName, sortOrder, active
1, ORDERS, DRAFT, In cart, 10, 0
2, ORDERS, NEW, New, 20, 1
...
8, ITEMS, ACTIVE, Active, 20, 1
9, ITEMS, INACTIVE, Inactive, 10, 1
10, ITEMS, UNAVAILABLE, No longer available, 10, 1
...
15, ORDERS, PROCESSING, Processing, 40, 1
16, ORDERS, PROCESSED, Processed, 50, 1

Note the sortOrder is not a simple 1,2,3 but I space them out. This
allows me to easily insert some rows later and not depend on the table
id for the sorting. Active is 0/1 and object corresponds to the name
of the object that I'm working with. I generally have lots of objects
that need some kind of STATUS indicator. Then I have a status property
in my various objects which associates a given STATUS with the object.

Wayne

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[John Moore]

Wayne Fay wrote

As an example, I have a STATUSES table that looks like:
id, object, name, displayName, sortOrder, active

So who is responsible for this data? You, the developer? Or a user with admin privileges? If the former, why would you not have this as an enum, say, or in some other form where you are totally in charge of structure and data? And if the latter, how do you ensure that data is added in the correct format, and that data you are counting on being there does not get deleted? This is my point about an uneasy area, where ones code depends on some values being present in data, which is normally the responsibility of users.

[Wayne Fay]

>> As an example, I have a STATUSES table that looks like:
>> id, object, name, displayName, sortOrder, active
>
> So who is responsible for this data? You, the developer? Or a user with
> admin privileges? If the former, why would you not have this as an enum,
> say, or in some other form where you are totally in charge of structure and
> data? And if the latter, how do you ensure that data is added in the correct
> format, and that data you are counting on being there does not get deleted?

The latter -- but my users do not interact with this table directly
via SQL. Instead I have built a series of screens in an Admin area
where they can adjust the displayName, sortOrder, and mark things as
Active/Inactive. For certain objects they can also add a new Status
row.

> This is my point about an uneasy area, where ones code depends on some
> values being present in data, which is normally the responsibility of users.

Just don't let the users delete from this table. If they need to
"delete" it then you just mark the row as Inactive and make sure that
all the places where this status could be set by a user checks "and
active=true" before showing it as an option.

Wayne

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[bdrhoa]

In one of my apps I have a lookup table domain that's controlled by an
admin. I do data validation via regular expressions that I have
defined and show to the user with meaningful names, (e.g. SSN).

See the lookup table controller and view for http://maflt.org/products/Ibidem.

---------------------------
www.maf.org/rhoads
www.ontherhoads.org



On Wed, Feb 29, 2012 at 2:41 AM, John Moore <[hidden email]> wrote:

>
> Wayne Fay wrote
>>
>> As an example, I have a STATUSES table that looks like:
>> id, object, name, displayName, sortOrder, active
>
> So who is responsible for this data? You, the developer? Or a user with
> admin privileges? If the former, why would you not have this as an enum,
> say, or in some other form where you are totally in charge of structure and
> data? And if the latter, how do you ensure that data is added in the correct
> format, and that data you are counting on being there does not get deleted?
> This is my point about an uneasy area, where ones code depends on some
> values being present in data, which is normally the responsibility of users.
>
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Handling-choice-lists-tp4429168p4431066.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email