Programatically adding "select" type page attributes
Permalink
Hi all,
I've been creating a base package for myself that installs the standard page attributes I use (redirect_to_first_in_nav etc). To this point I've been adding text and checkbox attributes using the following:
But now I'm wanting to include a `select` type attribute but immediately see a programatic way to adding the attribute values. Searching for uses of atSelectOptions table it seems to only be in concrete/models/attribute/types/select/controller.php but that seems heavily bound to the form used in the UI (and modifies the DB directly rather than using a more generalised Model object(s)).
Should I be using this or is there an easier/better way?
Thanks in advance
Andrew
I've been creating a base package for myself that installs the standard page attributes I use (redirect_to_first_in_nav etc). To this point I've been adding text and checkbox attributes using the following:
// note: this method isn't static method so I get warnings in my IDE too... CollectionAttributeKey::add($type, array('akIsAutoCreated' => 0, 'akHandle' => $handle, 'akName' => $name), $pkg);
But now I'm wanting to include a `select` type attribute but immediately see a programatic way to adding the attribute values. Searching for uses of atSelectOptions table it seems to only be in concrete/models/attribute/types/select/controller.php but that seems heavily bound to the form used in the UI (and modifies the DB directly rather than using a more generalised Model object(s)).
Should I be using this or is there an easier/better way?
Thanks in advance
Andrew
[removed by author]
You can do it this way:
While not the easiest component of concrete5 to understand, the entire select attribute class should be pretty object oriented, and it should provide methods for doing most anything you want to do.
Unless I'm mistaken, Jordan's only real problem with the select attribute was the way that it indexes its stored data with newlines separating each one, requiring you to wrap newlines around your values when you search against the indexed table. Not ideal, obviously, and something we'll likely address in a change to the filter by functionality.
$type = AttributeType::getByHandle('select'); $cab = CollectionAttributeKey::add($type, array('akHandle' => 'attribute_key_handle', 'akName' => 'Attribute Name', 'akIsSearchable' => true), $pkg); SelectAttributeTypeOption::add($cab, 'Option 1'); SelectAttributeTypeOption::add($cab, 'Option 2');
While not the easiest component of concrete5 to understand, the entire select attribute class should be pretty object oriented, and it should provide methods for doing most anything you want to do.
Unless I'm mistaken, Jordan's only real problem with the select attribute was the way that it indexes its stored data with newlines separating each one, requiring you to wrap newlines around your values when you search against the indexed table. Not ideal, obviously, and something we'll likely address in a change to the filter by functionality.
I stand corrected. And I'm sorry about the "hacked together" comment :)
It was one of those "I need to get this project out the door and nothing is going smoothly" situations -- in hindsight I am of course grateful that the select attribute is even there and I didn't have to create my own type.
It was one of those "I need to get this project out the door and nothing is going smoothly" situations -- in hindsight I am of course grateful that the select attribute is even there and I didn't have to create my own type.
No problem :) I didn't mean to come off as snippy, either. Probably shouldn't do all of my forum catch-up post-vacation at once. ;-)
Thanks guys, when I saw the DB access in the controller I too thought "ahh crap!" but it's great to see there's a model wrapping it. Thanks for pointing it out.
As I've been going through the code I'm noticing quite a few things like that (e.g. controllers crafting sql, or duplicated code that would be better in a model etc) , is it worth raising issues/bugs for this kind of thing or is it something that's already being handled?
Thanks & cheers
Andrew
As I've been going through the code I'm noticing quite a few things like that (e.g. controllers crafting sql, or duplicated code that would be better in a model etc) , is it worth raising issues/bugs for this kind of thing or is it something that's already being handled?
Thanks & cheers
Andrew
And also, is there any documentation on the various tables/columns available, e.g. what is the reason for akIsAutoCreated and the concequences of specifying true or false etc.
Cheers
Cheers
We are always willing to look into refactoring (although such changes will have to keep the API consistent). You might try forking our official github repository and submitting a pull request with your changes if you think that they would be useful for the rest of the community. We would definitely look into accepting them
https://github.com/concrete5/concrete5/...
https://github.com/concrete5/concrete5/...
Andrew, how can you add options to a single users select attribute?
Like above you added the available options to a select attribute.
I want to take it a step further and programatically add options from the attribute to be "selected" by that user
Do you understand my question?
Like above you added the available options to a select attribute.
I want to take it a step further and programatically add options from the attribute to be "selected" by that user
Do you understand my question?
