Manual:ContentHandler/tr

ContentHandler özelliği, her şey için vikimetine güvenmek yerine, viki sayfalarındaki gelişigüzel içerik türlerini destekleyen bir mekanizmadır. Vikiveri projesinin bir parçası olarak geliştirilmiştir ve 1.21 sürümünden bu yana MediaWiki çekirdeğinin bir parçasıdır.

ContentHandler mimarisine kanonik genel bakış için, MediaWiki kod belgelerinde ContentHandler adresinde bakın.

Kullanılabilir içerik işleyicilerinin bir listesi için sayfasına bakın.

Hakkında
Bu oldukça radikal değişikliğin ardındaki mantık, tüm içerik için vikimetine güvenmeye zorlanmanın MediaWiki'de pek çok şeyi oldukça hantal hâle getirmesidir. Keyfi sayfa içeriği türleri için yeni takılabilir mimari, umarız:


 * tex veya markdown gibi bazı veya tüm sayfalarda farklı bir biçimlendirme dili kullanın.
 * CSS ve JavaScript sayfaları için özel durumlardan kurtulun.
 * yapılandırılmış yapılandırma verilerini, örn. Gadgets uzantısının MediaWiki:Gadgets-definition veya LanguageConverter MediaWiki:Conversiontable*** sayfalarında ne kullandığı.
 * vikimetin sayfalarına veri "ekleri" sağlayın, ör. coğrafi veriler için (sayfa için bir "çok parçalı" içerik modeli kullanarak, çok parçalı mesaj biçimi kullanılarak e-posta eklerinin uygulanmasına benzer şekilde). (Not: Bu hiçbir zaman gerçekleşmedi ve şimdi ile değiştirildi.)
 * kategorilerin vb. vikimetinin kendisinde tutulmadığı, ancak yine de normal şekilde saklanıp sürümlendirildiği bir sisteme geçiş (yine çok parçalı içerik modeli kullanılarak).
 * Vikiveri için yapılandırılmış verileri sayfa içeriği olarak kolay ve yerel bir şekilde depolayın.

Tasarım fikiri
Buradaki fikir, diğer türden verileri tam olarak vikimetinin şu anda depolandığı şekilde depolamak, ancak MediaWiki'yi her sayfa için ilgilendiği içerik türünden haberdar etmektir. Bu şekilde, her türlü veri bir viki sayfasının içeriği olarak kullanılabilir ve aynen eskisi gibi depolanır ve sürümü oluşturulur. Bunu başarmak için MediaWiki çekirdeğinde aşağıdakiler uygulandı:


 * her sayfanın içerik modelini takip edin. Bu, öncelikle veritabanındaki tablosunda (ayrıca  ve  tablolarında) yapılır ve ,   ve   gibi ilgili çekirdek sınıflar aracılığıyla erişilebilir hâle getirilir. İçerik modeli, ister metin içeren bir dize, ister dizilerin iç içe geçmiş yapısı veya bir PHP nesnesi olsun, içeriğin yerel formunu tanımlar. İçerikle ilgili tüm işlemler kendi yerel formu üzerinde gerçekleştirilir.
 * her revizyonun içerik formatını (serileştirme formatı) takip edin. Bu, öncelikle veritabanındaki tablosunda (ayrıca  tablosunda ancak  tablosunda değil) yapılır ve   gibi ilgili çekirdek sınıflar aracılığıyla erişilebilir hâle getirilir. Note that the serialization format is only relevant when loading and storing the revision, no operations are performed on the serialized form of the content.
 * Note: in case of flat text content (such as wikitext), the native form of the content is the same as the serialized form (namely, a string). However, conceivably, the native form of wikitext could be some form of AST or DOM in the future.
 * Note: the table records the content model for the current revision, while the  records the content model and serialization format. Model and format may in theory both change from revision to revision, though this may be confusing, and doesn't allow for meaningful diffs.

This means that all code that needs to perform any operation on the content must be aware of the content's native form. This knowledge is encapsulated using a pluggable framework of handlers, based on two classes:


 * The  class represents the content as such, and provides an interface for all standard operations to be performed on the content's native form. It does not have any knowledge of the page or revision the content belongs to. Content objects are generally, but not necessarily, immutable.
 * The  class, representing the knowledge about the specifics of a content model without access to concrete Content. Most importantly, instances of ContentHandler act as a factory for Content objects and provide serialization/deserialization. ContentHandler objects are stateless singletons, one for each content model.

The ContentHandler is also used to generate suitable instances of subclasses of,  ,  , etc. This way, a specialized UI for each content type can easily be plugged in through the ContentHandler interface.

All code that accesses the revision text in any way should be changed to use the methods provided by the Content object instead. Core classes that provide access the revision text (most importantly,  and  ) have been adapted to provide access to the appropriate Content object instead of the text.

Backward compatibility
The assumption that pages contain wikitext is widespread through the MediaWiki code base. To remain compatible with parts of the code that still assume this, especially with extensions, is thus quite important. The right way to provide good compatibility is of course not to change public interfaces. Thus, all methods providing access to the revision content (like, etc) remain in place, and are complemented with an alternative method that allows access to the content object instead (e.g.  ). The text-based methods are now deprecated, but shall function exactly as before for all pages/revisions that contain wikitext. This is also true for the action API.

A convenience method,, is provided to make it easy to retrieve a page's text. For flat text-based content models such as wikitext (but also JS and CSS),  will just return the text, so the old text-based method will return the same as it did before for such revisions. However, in case a text-based backwards-compatible method is called on a page/revision that does not contain wikitext (or another flat text content model, such a CSS), the behavior depends on the setting of : ignore makes it return null, fail causes it to raise an exception, and serialize causes it to return the default serialization of the content. The default is ignore, which is probably the most conservative option in most scenarios.

For editing however, non-text content is not supported per default. and the respective handlers in the action API will fail for non-textual content.

Links

 * and  classes :


 * Settings :


 * Extensions using ContentHandler :
 * How to add a new content model with an extension:
 * Basic example: Extension:Markdown
 * The extension
 * — a list of all content models (both in core and extensions)
 * — a list of all content models (both in core and extensions)