Loading...
 

Tikiwiki-devel (mailman list mirror)


You are viewing a reply to New object types  

New object types

posts: 43

Sounds great, agreed!

asa

On Tue, Dec 5, 2017 at 4:22 PM, Jonny Bradley <jonny@tiki.org> wrote:
> Hi Asa (finally)
>
> I added indexing for calendar events recently so adding them as an object type sounds sensible (i missed that i guess?), same for tracker fields and trackeritemfields - these should be more connected together somehow i think, and also with categories and permissions...
>
> I like the idea of making this class based and having a class file for each object type (if i understand you correctly), and i agree it would make the code neater and avoid all those repetitive switch statements, so in principle i am +1 on this :-)
>
> However, let’s get 18.0 out of the door first, and i think this might be a good case for an experimental branch early next year to see what might break, before merging it into trunk before branching 19.x next spring. Sound reasonable?
>
> Thanks! :-)
>
> jonny
>
>
>
>
>> On 22 Nov 2017, at 12:10, Luis Henrique Fagundes <lhfagundes@gmail.com> wrote:
>>
>> Hi,
>>
>> While working on Plugin Include enhancements (https://dev.tiki.org/PluginInclude), I created three new object types. These are being used in tiki_object_relations, to track relations of type tiki.wiki.include, created when an object uses Plugin Include to include content of a wiki page.
>>
>> The new types are:
>>
>> trackerfield
>> trackeritemfield
>> calendar event
>>
>> The trackerfield type was already cited at objectlib.php -> getSelectorType. The type trackeritemfield used itemId:fieldId as key.
>>
>> Now, when a page is renamed, wiki content using Plugin Include is updated everywhere: wiki pages, forum posts, comments, articles, blog posts, tracker description, tracker field description, tracker textarea field and calendar events. This does not happen for page links, which only update comments and wiki pages.
>>
>> One thing that comes to my mind after studying objectlib is that it could be refactored to have each object type as a class in core. This way things like building urls, getting wiki parsed content, getting title, description etc would be methods of these object type classes and the extensive switch($type) \{ case...\} blocks around objectlib, wikilib and modifier.sefurl could be eliminated. Any opinions on that?
>>
>> asa
>>
>>
>>
>>
>>
>> I see that’s there’s a lot of switch($type) \{ case... \} code blocks around, and I’ve added some more. Besides objectlib.php, they also appear in modifier.sefurl.php (which is redundant with code in $objectlib -> add_object), and wikilib.php.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world’s most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_
>> TikiWiki-devel mailing list
>> TikiWiki-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world’s most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Why Register?

Register at tiki.org and you'll be able to use the account at any *.tiki.org site, thanks to the InterTiki feature. A valid email address is required to receive site notifications and occasional newsletters. You can opt out of these items at any time.