-
☆ A M B ☆
- 24,524 Posts
Actually the name has already been changed once; in the database their table is still "htmlsnippets".
-
☆ A M B ☆
- 872 Posts
it goes from chunk to htmlsnippets, which is longer than the original name and not forcefully more clear than the original.
Not to mention that you call the Chunk object via ModChunk in Revolution :p
Quote from: lossendae at Aug 29, 2010, 10:48 AM
it goes from chunk to htmlsnippets, which is longer than the original name and not forcefully more clear than the original.
Not to mention that you call the Chunk object via ModChunk in Revolution :p
No, "htmlsnippets" is the *old* name. It’s gone except as the name of the column in the DB. In the DB, "htmlsnippets" is still there in Revolution.
-
☆ A M B ☆
- 2,475 Posts
Revo promises some good flexibility with problems like this though... the database has been abstracted with the xPDO layer, so the next step will be restructuring the database itself. As you’ve noticed, there are some weird table names, and the ID names are inconsistent etc. which will be addressed at some point I’ve heard.
Quote from: Everett at Aug 29, 2010, 12:38 PM
Revo promises some good flexibility with problems like this though... the database has been abstracted with the xPDO layer, so the next step will be restructuring the database itself. As you’ve noticed, there are some weird table names, and the ID names are inconsistent etc. which will be addressed at some point I’ve heard.
Good point, and a good reason for using xPDO (e.g., getObject(), getChunk(), getContent(), setContent(), etc.) instead of direct manipulation of the DB.
It’s an interesting idea and I wouldn’t be surprised to see some merging of MODx objects in future versions. The problem with your example, though, is that the Hello World object would have to have a doctype and <html><head> and <body> sections to work as a template, which would keep it from working as a chunk.
Merging templates and chunks would confuse new MODx users more than the present scheme, IMO, but I’m not sure everyone would agree with me.
-
☆ A M B ☆
- 2,475 Posts
No, that’s a really good point, Bob: somewhere you gotta store header and content-type info SOMEWHERE.
The thing that’s a bit odd about the object structure in MODx is that the template_id is stored inside the content object (in the table)... it does make lots of sense to put it there... but if the content is just content, and the web site is a VIEW of that content, then the view might best be stored elsewhere, e.g. inside a table that joined the context and the content. But that kinda hurts my head to think about joining content, context, and template.
Perhaps one of the most difficult things about Revo is that it has abstracted so many things... that’s HUGELY important architecturally because it allows for so much freedom, but with every abstraction you run the risk of alienating users. There’s a happy medium there, I’m sure... I’ve wondered if there weren’t a way to display a "simplified" MODx Revo manager to the new users, just to make it easier to use. E.g. call them Pages instead of Resources, etc.... it’s a deep topic, I know...
You can customize the heck out of the Revo Manager in terms of what the user can see and do and what things are called.
See the "Controlling What Users can Do and See in the Manager" section here:
http://bobsguides.com/revolution-permissions.html
You can also easily change the name of *anything* in the Lexicon Management grid (if you can find the right language key) and your changes will survive an upgrade.
