Loading...
 
Skip to main content

Custom Share Module 0.1dev

Development

Development

Forum List Topic List

Forums » Development » Meta Tiki Thoughts
 
Thread actions
Print this page
  • Print all pages

    • Meta Tiki Thoughts

    Posted by Brian Merritt posts: 42 ☆ ☆ ☆ United Kingdom

    Tiki is a fantastic feature rich CMS tool

    In order to make even better uses of our development resources I was thinking what if many of the Tiki features were "rewritten" using Trackers?

    Any Tiki feature like Blogs and Articles could use Trackers to make them easier to document and easier to tweak without programming. Here is one possible way to do that:

    "Features" Tracker DB - DB of all Tiki supported Features, by Name (easy to then change Articles to Blogs and vice versa), and contains a standard structure of Feature elements

    "Articles" Tracker DB - DB containing the fields and parameters which the Articles feature needs, like "Type of Articles", "Header", "Main Article", Date to publish, a flag whether or not it is published etc.

    "Articles Code" DB - a feature element which contains only the code or parameters above standard Tracker functionality for Articles to work. you would have one section for creating new Articles, one for editing, one for listing, one for reading.

    "Articles Template" DB - a feature element which contains the template for presenting the Articles. again you would have one section for creating new Articles, one for editing, one for listing, one for reading.

    Virtually all the PHP/Smarty/Javascript would be contained in the main Tiki "Meta Tracker" code - even the Themes could be incorporated into the Meta structure.

    Specific functions for "Articles" could be migrated into the Meta Code and parameters would drive the Articles feature functionality and give Articles it's characteristics.

    But those same parameters are then available for blogs, or newsletters.

    Same for Surveys, Quizzes & Polls

    By making a proper Multilingual Meta function, each Feature becomes Multilingual without pasting lots of code.

    Want a new WYSIWYG editor? Do it once for all Features

    Finally, this provides time/code to make using Trackers easier - no need to type {trackerslist(fields="1:2:67:34:22" - you can select their real names)

    Thoughts??

    ps - apologies if this is not a new idea. It's new for me 😉

    Reads: 2050
    Posted by Xavier de Pedro posts: 1817 ☆ ☆ ☆ Catalan Countries

    Hi Brian:

    Yes, well thought!
    However, the other simpler parallel features need to exist for new users or tiki admins, needing to create or use some basic & quick & easy feature for articles, surveys, quizzes, etc., without the need to master trackers.

    Trackers are very powerful, but require a somewhat steep learning curve.

    For experienced users, trackers are amazing!

    Cheers


    Posted by Brian Merritt posts: 42 ☆ ☆ ☆ United Kingdom

    Thanks for fast reply

    Normal Admins should use existing admin menus and controls - the meta approach should have feature parameters and options stored ad trackers rather than mysql or feature specific php and tpl files.

    So minimum admin retrain / document rewrite yet easier development once initial rewrite done. Future devs are then focussed on new functionality, with trackers acting as a type of middleware.

    Worth a quick discuss in Boston, but not for 7 or maybe even 8


    Posted by Christophe posts: 31 ☆ ☆ ☆
    Brian Merritt wrote:
    What if many of the Tiki features were "rewritten" using Trackers?


    Sorry for the late reply 😉

    I'm currently struggling with Trackers, and indeed it looks like both a tremendous feature but also one incredibly difficult to master.

    Actually, this can go very very far : in your idea, you consider using Trackers for articles or blogs. These two seem very similar to me. So what if ... you consider the Wiki pages themselves ? I also see that the whole accounting extension of tiki is fully based on trackers. Not sure I understand how it works BTW, but that is a completely different story.

    Maybe I didn't understand the key concept, but my view is that you propose to replace a "text-centric" feature by a "table-centric" one, including some additional fields. Makes clearly sense to me, but the key aspect is obviously : what are those standard fields ? In the above referenced accounting for example, the table for bank accounts has a BIC of 63 CHAR while AFAIK a BIC is always 8CHAR (it comes from SWIFT).

    Or maybe I have it all wrong ? Because searching a bit in my local tiki.sql archive, I found a CREATE TABLE `tiki_articles` with a table including the fields like "publishDate", "authorName" or "Heading".

    So, could you elaborate a bit on how you see the impact of using trackers for articles and blogs ? On Wiki pages ? On Forum ? I did not see anything such as a "title" or an "author" for Trackers

    Posted by Brian Merritt posts: 42 ☆ ☆ ☆ United Kingdom
    Christophe wrote:

    Maybe I didn't understand the key concept, but my view is that you propose to replace a "text-centric" feature by a "table-centric" one, including some additional fields. Makes clearly sense to me, but the key aspect is obviously : what are those standard fields ? In the above referenced accounting for example, the table for bank accounts has a BIC of 63 CHAR while AFAIK a BIC is always 8CHAR (it comes from SWIFT).

    Or maybe I have it all wrong ? Because searching a bit in my local tiki.sql archive, I found a CREATE TABLE `tiki_articles` with a table including the fields like "publishDate", "authorName" or "Heading".

    So, could you elaborate a bit on how you see the impact of using trackers for articles and blogs ? On Wiki pages ? On Forum ? I did not see anything such as a "title" or an "author" for Trackers


    At the moment each Tiki feature has a substantial amount of code written specifically for that function. Yes, there are libraries as well, but for example multi-lingual support in Wikis (one wiki page, multiple languages, from the user point of view at least) does not work in Articles, where you need to create an Article for each language.

    There is substantial work in Tiki 7 to harmonise trackers (cut out duplicated code, build on the tracker library) and in 8 now to make trackers faster and have better facilities.

    But as you say, the data is all stored in SQL tables anyway. Meta Trackers is one way to do this, but the other may be to harmonise the code at a lower layer, e.g. combine all the distributed code that handles specific functions (forms, events, views, formatting, validation, etc) so that you no longer need list-articles.php and separate list-wikipages.php but instead list-object.php.

    Anyway, whilst I am pontificating about this the developers are doing a lot of great work in the background relating to tracker robustness, performance, reporting and functionality 😊