Tables
Permalink
I'm getting killed trying to find where the information is being pulled from; i.e., the "description" data in the document library for a particular file. Why is this so hard? Can someone advise on what is best to read with regards to understanding how to find where information is being stored - or how to dump the data to see where to find it? So many loaders and so little information as to where to find them in order to trace down the logic. Or....Am,I....A.....moron?
Thanks Benji, I did some searching and found my answers. The coding of Concrete5 is much different from stuff I've seen before. For example, I don't understand the in_array call which finds the needle but makes tracing the source extremely difficult - let alone a slowdown in performance(?). Seriously, I do not know and I am not an expert. I would find an article written by the lead programmers as to a birds-eye view of their thinking extremely helpful. My limited experience in website programming has merely taught me that there are many ways to get any one thing done. The Concrete5 programmers must have a great perspective as their end product is the best I've ever seen. But without understanding their thought process I'm left to copy/paste instead of truly understanding their intent. I'm interested in finding a programming effort to invest my time in; with Concrete5 the end result is great but the core logic seems beyond me. Why, when it seems they are building for "inclusion" of addons, would there not be more flowchart documentation? I still can't follow the logic for breaking down the attributes the way they do - why is that? Probably a quick explanation and I'd be less confused - and more motivated to play ball.
I hate when people point to an obvious place, but if you haven't already checked it out, see the section on attributes in the documentation section.
I know what you mean - its a bit intimidating at first trying to trace exactly how the C5 logic runs. I find myself using the print_r function every other second. But the reason, from what I can tell, that things are so separated and have lots of loaders and such - is to keep all the individual classes and functions loosely coupled... In other words, flexible enough to be applied to several problem solving applications without having to overwrite parts of the code. For a CMS like Concrete5, I can't think of a better approach.
With attributes - since they can apply to several object types (users, files, pages, etc), it makes sense from a design perspective how the core team set things up.
Pain in the ass to learn - yes. Worth it once you do, absolutely.
I know what you mean - its a bit intimidating at first trying to trace exactly how the C5 logic runs. I find myself using the print_r function every other second. But the reason, from what I can tell, that things are so separated and have lots of loaders and such - is to keep all the individual classes and functions loosely coupled... In other words, flexible enough to be applied to several problem solving applications without having to overwrite parts of the code. For a CMS like Concrete5, I can't think of a better approach.
With attributes - since they can apply to several object types (users, files, pages, etc), it makes sense from a design perspective how the core team set things up.
Pain in the ass to learn - yes. Worth it once you do, absolutely.
Thanks. So, "loosely" can be describe as an in_array call for the string "attribute" to find a user/file/page table which then can pull the key/value for another in_array call for the string i.e. "description"/value? If so, are they then building all required/acquired attribute values into yet another array for the purpose of cycling through it inside the template? And if this is so, is there any kind of nomenclature that is used in order to call a var_dump(?) to ascertain what's available in a particular building of a template? Or, more likely, what you're missing and where you need to bring it into in order to use it?
Does that make sense to anyone, or am I lost (again)?
Does that make sense to anyone, or am I lost (again)?
UPDATE: 2-days of lost hair, but: I now understand that much of what I was trying to do is already built into Concrete5. I was trying to hack the ability to add attributes and did not realize that Concrete5 already provides the ability to do that. I was digging too deep into the code and running into functions that were already setup to perform what I wanted to do. My biggest mistake was reading almost all of the documentation EXCEPT the attribute section. Go figure. I've gone from thinking the core C5 team needed psychological help to - *cough* - wonderful human beings dedicated to the advancement of our society.
I sure would have liked a viemo screencast showing the use of adding attributes within the Dashboard's User/Page/File section(s). That would have made the "Extended Forms" addon more understandable with regards to the key/value handle input - let alone the core package.
Thanks (and, uh, sorry).
I sure would have liked a viemo screencast showing the use of adding attributes within the Dashboard's User/Page/File section(s). That would have made the "Extended Forms" addon more understandable with regards to the key/value handle input - let alone the core package.
Thanks (and, uh, sorry).
As far as a place to go to read about the c5 database, I don't know of one other than the database and the code itself. While it may seems like a bit of a pain, usually tracing through the code for DB calls or poking around in the database gets you to the right answer and proves highly educational along the way.