Feeling a bit nostalgic, I tried my hand at PHP once again. Looks like I may have new forum script out using old code I’ve had lying around with excerpts I’ve found on tutorials. Expect the alpha to be out sometime over the weekend (assuming work doesn’t get in the way).
It will be using MySQL and have a total of six tables (some will not see action until the beta). The templating system is very basic and I’m going for bare minimum in features. A lot of it is inspired by the *chan imageboards, minus the sparsity of the UI and image uploading capabilities. More than likely, the core code would probably be on only one file.
I’ll be substituting “good” programming practices with “reasonable” ones instead. ;)
Update *cough* Monday 25th
OK, so the weekend was a bit over enthusiastic. Work did get in the way so I’ll have to push this back a bit.
Very informative PHP.
Speaking of which, I’m looking to go into the design phase today for my CMS. I’ve been trying to figure out how to pose the question – I figure I’ll just make a post on my blog that is open to all for suggestions, along with my own thoughts. But if you have any specific input for the CMS design, I’d love to hear it.
I think CMS design should be structure and output driven.
Structure (parent child etc..) for all content. Output formatted depending on the type of content. I had a reply with more detail on this including a demo db schema on that JavaScript loader post’s comments.
I would think a templating system would give you enough breathing room to concentrate on the core functionality. This way, you can use any ye olde HTML during the build phase to quickly find rendering quirks or add/remove aditional output to the browser.
Smarty maybe?
I came across an article by Brian Lozier. Don’t know if you’ve already come across this one; It’s a few years old. But I think it has some good ideas on how to render output via templates. Would come in handy if you’ll go with your own template engine rather than a third party option.
Yep, I have both your previous article and the Smarty website linked on my CMS wiki page, as I intend to use both as I go.
I also very much agree with a structure/output approach to architecture. Ideally, I was thinking almost of a node-based CMS, where each bit of functionality is essentially an independent and interlocking servlet that performs its core duty, but can access information held by other nodes, or servlets. The only consideration I’m having a difficult time with is how exactly to represent dependencies between nodes.
For example (a bit extreme, but illustrates the idea) : suppose I created a node responsible for translating all the content from one language to another (or perhaps from english to binary…that’s always fun as a prank :P ). It would either have to be expressed as a dependency for every single other node, or it could operate independently in between all the other nodes and the output. While the latter would be much preferred, I’m not exactly sure how to structure the program so a single node could intercept all the output from all the other nodes, if each node is an independent entity.
Are we picturing the same thing when we say “node”? :P
And then you need to consider how complex do you really need it?
It is a CMS and though diving into this is a lot of fun, will you be able to complete it in a meaningful timeframe?
In the end, you’ll need to map out what the software you’re writing is meant to do and won’t do and how it will handle both situations.
Your description reminds me of a Property Bag.
Arbitrary number of properties and arbritary number functions depending on need.
Good thing is that there is inifinite flexibility.
Bad thing is that there is infinite flexibility.
I think there needs to be some sort of lockdown on node behavior to make sense of this. You may need to introduce node types (I.E. it’s a specific type based on which function nodes are assigned to handle it’s content). Dependency does seem like the practical approach in this case. Too much interdependency will make storage an issue (unless you’re going for an object database).
You could work this out with some sort of inheritance with node primitives.
Say, “translate” module node inheritance signals this content node is text and should be treated as such (I.E. enable WYSIWYG editing, activate the “Title” and “Description” fields etc…). And now the content will have related versions(EN, BIN etc…)
The “file” module node inheritance means the original content node is a blob or at least holds the upload path. Inheriting the “file” node will also identify what the child node is (image, archive, document etc…) and activate appropriate properties for editing.
Inheriting both “translate” and “file” nodes means this content is now available as a download and online text.
Hope that makes sense.
I’ve read this three times and have to confess I have no idea what any of it means. It sounds very informative.
:)
Haha! Thanks, Alan. I assure you it’s all a heap of fun!
Please rejoice on my behalf ;)
Pingback: It’s design time « Theatre of Consciousness
Pingback: It’s design time » lolcat.us
Pingback: Update on the new (old) PHP forum « This page intentionally left ugly
Pingback: New (old) PHP forum SQL tables « This page intentionally left ugly
Pingback: Forum Core.class.php progress update « This page intentionally left ugly
Pingback: PHP Plugin/Module system « This page intentionally left ugly
Pingback: Forum core source dump (as of July 31) « This page intentionally left ugly
Pingback: What’s with the holdup? « This page intentionally left ugly
Pingback: PHP Plugin/Module system | Текстиль & Ко