Get Page ID from Attribute controller [Help needed to debug new sub-cat attribute]1 user found helpful
I am currently using $_REQUEST['cID'], but don't think thats the best way to do this. I was hoping I could hook into one of the objects that are called from within the attribute controller.
Is this possible and if so what do I need to be using?
//current implementation $page = Page::getByID($_REQUEST['cID']); $page->setAttribute($ak,$value); //within a attribute controller, //Page::getCurrentPage(); /returns blank
edit: I have attached my current attribute below (It's currently very buggy, and not to be used on a production site)
For example, the current page is not actually worked out by c5 until after the on_start event has been processed.
I am calling this within the save_form of the attribute controller, the section I am at is page > properties > Custom attributes
I have an attribute, that I have added this also pulls in a parent attribute(a select attribute) that I would also like to save when I click on "Save"
What I have currently works, (sort of) but I would like to clean some of it up if possible.
I had the same need for a file attribute. The attribute needed to do some stuff and needed to know what file it was attached to. Eventually the core team was asked on TRL how this could be done, or how it could be architected to be done. The answer was the somewhat standard, "We see no reason why that's necessary... Next."
I had to look at the $_GET variables to suss out the file id. My next step would have been to write some SQL, but that wouldn't have worked until after the first save.
I might need to go back to the drawing board for this one.
I was trying to get it so that I could add the single attribute, maybe I just need this to stay with two separate attributes and update the second according to the first choice via a selector and attempt an ajax post.
It does require another (select) attribute to exist. In my example I am using a hardcoded select attribute, "employment_category" set in the controller.
Also if you currently add a categories attribute, on the first add, the parent category can be chosen but does not update, until the next reload. (An issue with me calling a function before the page has finished loading) It does however save the parent category.
The premise for this attribute is to be able to have a Job(Parent Category) and then depending on the category chosen, have a list of sub-categories displayed.
The idea, once completed is to release it as a free atribute, there are a few other sites I would have liked an attribute like this for. Currently I use pages then sub pages for categorisation but I find that adds an extra level of complexity when you need to choose which of the 30+ pages you can publish an article under.
I would be really grateful if anyone was able to spare a little time and point out any glaring errors or any sections that you think can be improved. I'm really in over my head with the js and ajax in concrete but learning as I go.
Creating two separate attributes enabled me to work around that particular issue by ensuring I am pulling in a list of results and not dynamically altering them as and when I added a new parent.
I may be over thinking this a little, it is possible that I could just set the child attribute and then by inheritance, work out the parent category, maybe I do not need to set parent attribute at all.
What I am trying to achieve is to have the following,
//Choose Cat A Category A //Sub categories select box are filtered by Cat A Sub Category 1 Sub Category 2 Sub Category 3 // Or choose Cat B Category B //Sub categories select box are filtered by Cat B Sub Category 4 Sub Category 5 Sub Category 6 //Instead Of them being seperate //Category is chosen Category A
I have moved the setAttribute to be reliant on a request page object, otherwise it ignores that. The parent page is not to important for me as knowing the child category you can work back. (This could be an issue if you wanted to filter by the top level category as well?)
The dashboard attribute page actually appears to be loading the correct values and posting the correct content now, but needs cleaning up.
I'm using this with the Jobs Listing Package so have had to change the search page to accommodate the new attribute, so a block would need adding to actually filter the pages.
I'm going to go out on a limb an say this will not work within the dashboard page search area, using the category part of the attribute.
I'm trying to get this to a stage were I am happy placing it a clients site then will move the code to github,
Feels a lot cleaner to me, especially since I can call setAttribute almost anywhere and thus don't have $_REQUEST available
What do you guys think about that:
If I could just clarify, to check I have this right?
When you save the Attribute, you store the appropriate object along with the Attribute. In my case the cID but could be a user/file object.
That way when the attribute is loaded (as long as you know the CallingObject type?) the object can be dealt with.
Do the objects(Collection/User/File) contain their type? or is it assumed if you are referring to the Calling Object you know the object type already?.
The calling object is always an object, you can check it with something like instanceof