Creating a fixed, repeatable table with content-editable cells
Permalink
Currently I'm using a layout to create a pseudo-table that I'd like to put in a reusable HTML table. Here is what I'm working with:
http://advising.terry.uga.edu/index.php?cID=132...
I want to replicate this table on each page seen in the autonav at the top. But I want advisors to be able to login and edit their own specific office hours.
The layout isn't really working out since I need to replicate it and I realize after reading some other forum threads that I'm gonna need to probably do some work in the PHP files.
I have these pages assigned to their own page type.
As I am typing this out, I'm even confusing myself with exactly what I'm asking. If I need to do a better job explaining please let me know. In summary:
1. Can I convert this layout to a simplified table? Other threads say that as the template designer, I don't need to use a layout.
2. The table needs to have cell-specific user permissions.
3. I would like to easily replicate the table (and its permissions) on a particular page type.
http://advising.terry.uga.edu/index.php?cID=132...
I want to replicate this table on each page seen in the autonav at the top. But I want advisors to be able to login and edit their own specific office hours.
The layout isn't really working out since I need to replicate it and I realize after reading some other forum threads that I'm gonna need to probably do some work in the PHP files.
I have these pages assigned to their own page type.
As I am typing this out, I'm even confusing myself with exactly what I'm asking. If I need to do a better job explaining please let me know. In summary:
1. Can I convert this layout to a simplified table? Other threads say that as the template designer, I don't need to use a layout.
2. The table needs to have cell-specific user permissions.
3. I would like to easily replicate the table (and its permissions) on a particular page type.
I will definitely check out the designer content add-on.
You mentioned using page attributes as an alternative. Admittedly, this was how I wanted to do it from the beginning. Then I realized I didn't know how to get a page attribute to actually show up on the page. Oops.
You mentioned using page attributes as an alternative. Admittedly, this was how I wanted to do it from the beginning. Then I realized I didn't know how to get a page attribute to actually show up on the page. Oops.
If I was doing this from scratch, I would have a just one page attribute that contained a user ID.
Then in the block I would get that attribute, use it to get the user, then display user attributes in the table. That way my users would only have to edit attributes in their profiles. Pages would update to show info for whatever user was noted in the page attribute.
There are some user info blocks in the marketplace that could serve as a starting point for something like this.
Then in the block I would get that attribute, use it to get the user, then display user attributes in the table. That way my users would only have to edit attributes in their profiles. Pages would update to show info for whatever user was noted in the page attribute.
There are some user info blocks in the marketplace that could serve as a starting point for something like this.
Thanks John.
As I've been trudging through it the past week, I definitely want to set it up this way (with the page attribute deciding which user's custom attributes are showing). This is going to be the best solution because SO MUCH of the information on the page is defined by the affiliation with the user.
So... I can get the page attribute to show up, but I'm struggling to connect it to a user. Heck, I can't even get a user attribute of any kind to show up and I think that is an obvious step one.
I wish this was covered in the documentation but alas... I guess PHP developers (which I am not) probably have no trouble with this sort of thing. I'm a total HTML/CSS/JS guy.
As I've been trudging through it the past week, I definitely want to set it up this way (with the page attribute deciding which user's custom attributes are showing). This is going to be the best solution because SO MUCH of the information on the page is defined by the affiliation with the user.
So... I can get the page attribute to show up, but I'm struggling to connect it to a user. Heck, I can't even get a user attribute of any kind to show up and I think that is an obvious step one.
I wish this was covered in the documentation but alas... I guess PHP developers (which I am not) probably have no trouble with this sort of thing. I'm a total HTML/CSS/JS guy.
The trouble with php is that it is a mass of bundled libraries rather than a clean language. It started life as kludge and anything remotely structured has been botched on afterwards. That sort of organisation tends to spill onto anything implemented in php.
I answered your user attribute question in
http://www.concrete5.org/community/forums/customizing_c5/how-to-dis...
I have an addon WIP that can intercept block data and manipulate it. Amongst other things it can be used as a template/token engine on steroids and can be used to insert things like 'get a user from a page attribute and then get that user's XXX attribute'.
I answered your user attribute question in
http://www.concrete5.org/community/forums/customizing_c5/how-to-dis...
I have an addon WIP that can intercept block data and manipulate it. Amongst other things it can be used as a template/token engine on steroids and can be used to insert things like 'get a user from a page attribute and then get that user's XXX attribute'.
Then add the block to each page (but not in a global area as you will want multiple instances of it). So if you want it in a header, add a regular area to the header and use page defaults to have the block alredy there.
Another option would be to have the block display page attributes or a page attribute pointing to user attributes. Then you can let your users edit the attributes and have just one instance of the block.