I could write here a lot of answers but after thinking about possibilities, features, solutions ect,
it all come to one thing which is path which must be finished first to answer these questions.
The thing is - continue to work on core, separate modules from it and expose to them easy to use,
foolproof expandable interface.
(2013-01-26, 03:04 AM)Wildcard Wrote: [ -> ]but wouldn't that make the interface a bit clunky and hard to decipher?
Just thinking out loud here . . .
<thinking out loud>
...aww, you just fall into common trap, in which every developer end up in sometime,
looking for most complex possible answer, because the simple answers are hardest for us
First - as i said, modules must be separated and have his own options. (look above)
...When its done, and modules dont add options to core options list (like they do now)
but instead have his own options pages, then you could continue reading.
(core point of view)
- core simply calls module to get his contents,
- module return 'false' instead of 'box contents' which meant 'nah, ignore me and dont display now'
- core ignores it and display only modules which returned contents.
(module point of view)
It have option in his option page (which is not even concern of core what it do)
and its simple textbox with comma separated tid's or fid's where it want to be displayed.
- module check if current tid, fid, is in his list and return contents or false.
...This not only not expose any interface on core side, but also not require any processing
from core itself.
Quote:I have never used XThreads but perhaps I am missing out ... will give it a look this weekend.
Dont do this
XThreads is powerful and addicting thing and kind of a 'development tool'.
You may fall in love and forget about your projects.
