Nette Documentation Preview

syntax
Modüller
********

.[perex]
Modüller, mantıksal birimlere kolayca bölünmeyi kolaylaştırarak Nette uygulamalarına netlik kazandırır.

Dosyaları sabit diskte klasörler halinde düzenlemeye benzer şekilde, Nette'de sunum yapan kişileri, şablonları ve diğer yardımcı sınıfları modüllere bölebiliriz. Bu pratikte nasıl çalışır? Basitçe yapıya yeni alt dizinler ekleyerek. İşte Front ve Admin olmak üzere iki modüllü bir yapı örneği:

/--pre
app/
├── UI/
│   ├── <b>Admin/</b>            ← Admin module
│   │   ├── @layout.latte
│   │   ├── Dashboard/
│   │   │   ├── DashboardPresenter.php
│   │   │   └── default.latte
│   │   └── ...
│   ├── <b>Front/</b>            ← Front module
│   │   ├── @layout.latte
│   │   ├── Home/
│   │   │   ├── HomePresenter.php
│   │   │   └── default.latte
│   │   └── ...
\--

Bu dizin yapısı sınıfların isim alanlarına da yansıtılır; örneğin `DashboardPresenter`, `App\UI\Admin\Dashboard` isim alanında yer alır:

```php
namespace App\UI\Admin\Dashboard;

class DashboardPresenter extends Nette\Application\UI\Presenter
{
	// ...
}
```

Uygulamada, `Admin` modülü içindeki `Dashboard` sunumcusuna iki nokta üst üste gösterimini kullanarak `Admin:Dashboard` olarak atıfta bulunuyoruz. `default` eylemi için `Admin:Dashboard:default` olarak adlandırıyoruz.

Sunulan yapı katı değildir; yapılandırmada [ihtiyaçlarınıza göre tamamen özelleştirebilirsiniz |#mapping]. .[tip]

Modüller, sunucular ve şablonların yanı sıra bileşenler ve yardımcı sınıflar gibi diğer tüm dosyaları da içerebilir. Bunları nereye yerleştireceğinizi düşünüyorsanız, bir `Accessory` klasörü kullanmayı düşünün:

/--pre
app/
├── UI/
│   ├── Admin/
│   │   ├── <b>Accessory/</b>
│   │   │   ├── FormFactory.php
│   │   │   └── AdminLayout.php
│   │   ├── Dashboard/
│   │   └── ...
\--


İç İçe Modüller .[#toc-nested-modules]
--------------------------------------

Modüller, diskteki bir dizin yapısına benzer şekilde birden fazla iç içe geçme seviyesine sahip olabilir:

/--pre
app/
├── UI/
│   ├── <b>Blog/</b>             ← Blog module
│   │   ├── <b>Admin/</b>        ← Admin submodule
│   │   │   ├── Dashboard/
│   │   │   └── ...
│   │   ├── <b>Front/</b>        ← Front submodule
│   │   │   ├── @layout.latte
│   │   │   ├── Home/
│   │   │   └── ...
│   ├── <b>Forum/</b>            ← Forum module
│   │   └── ...
\--

 `Blog` modülü `Admin` ve `Front` alt modüllerine ayrılmıştır. Bu aynı zamanda `App\UI\Blog\Admin` ve benzer şekilde görünen isim alanlarına da yansıtılır. `Admin` alt modülü içindeki `Dashboard` sunucusuna atıfta bulunmak için, bunu `Blog:Admin:Dashboard` olarak adlandırıyoruz.

Yerleştirme, alt alt modüllerin oluşturulmasına izin vererek gerektiği kadar derin olabilir.

Örneğin, yönetimde `OrderDetail`, `OrderEdit`, `OrderDispatch`, vb. gibi sipariş yönetimiyle ilgili birçok sunucunuz varsa, `Detail`, `Edit`, `Dispatch` ve diğerleri gibi sunucuların düzenleneceği bir `Order` modülü oluşturabilirsiniz.


Bağlantı Oluşturma .[#toc-creating-links]
-----------------------------------------

Sunucu şablonlarındaki bağlantılar geçerli modüle görelidir. Bu nedenle, `Foo:default` bağlantısı geçerli sunum yapan kişiyle aynı modülde bulunan `Foo` sunum yapan kişiye yönlendirir. Örneğin, geçerli modül `Front` ise, bağlantı şu şekilde olur:

```latte
<a n:href="Product:show">link to Front:Product:show</a>
```

Bir bağlantı, bir modülün adını içerse bile görelidir ve bu durumda bir alt modül olarak kabul edilir:

```latte
<a n:href="Shop:Product:show">link to Front:Shop:Product:show</a>
```

Mutlak bağlantılar diskteki mutlak yollara benzer şekilde yazılır, ancak eğik çizgiler yerine iki nokta üst üste konur. Böylece, mutlak bir bağlantı iki nokta üst üste ile başlar:

```latte
<a n:href=":Admin:Product:show">link to Admin:Product:show</a>
```

Belirli bir modülde mi yoksa onun alt modülünde mi olduğumuzu öğrenmek için `isModuleCurrent(moduleName)` fonksiyonunu kullanabiliriz.

```latte
<li n:class="isModuleCurrent('MyEshop:Users') ? active">
	<a n:href="Product:">...</a>
</li>
```


Yönlendirme .[#toc-routing]
---------------------------

[Yönlendirme ile ilgili bölüme |routing#Modules] bakın.


Haritalama .[#toc-mapping]
--------------------------

Eşleme, sınıf adının sunum yapan kişinin adından türetilmesine ilişkin kuralları tanımlar. Bu kurallar [yapılandırmada |configuration] `application › mapping` anahtarı altında belirtilir.

Bu sayfada daha önce bahsedilen dizin yapıları aşağıdaki eşleştirmeye dayanmaktadır:

```neon
application:
	mapping: App\UI\*\**Presenter
```

Eşleme nasıl çalışır? Daha iyi anlamak için öncelikle modülsüz bir uygulama hayal edelim. Sunucu sınıflarının `App\UI` ad alanı altında olmasını istiyoruz, böylece `Home` sunucusu `App\UI\HomePresenter` sınıfıyla eşleşir. Bu, şu yapılandırma ile gerçekleştirilebilir:

```neon
application:
	mapping: App\UI\*Presenter
```

Bu eşleme, `App\UI\*Presenter` maskesindeki yıldız işaretini `Home` sunum yapan kişi adıyla değiştirerek çalışır ve sonuçta `App\UI\HomePresenter` nihai sınıf adı elde edilir. Çok basit!

Ancak, bu ve diğer bölümlerdeki örneklerde görebileceğiniz gibi, sunum yapan sınıfları isimsiz alt dizinlere yerleştiriyoruz, örneğin, `Home` sunum yapan `App\UI\Home\HomePresenter` sınıfıyla eşleştirilmiştir. Bu, yıldız işaretinin iki katına çıkarılmasıyla elde edilir (Nette Application 3.2 gerektirir):

```neon
application:
	mapping: App\UI\**Presenter
```

Şimdi, sunum yapan kişileri modüllerle eşleştirmeye geçelim. Her modül için özel eşlemeler tanımlayabiliriz:

```neon
application:
	mapping:
		Front: App\UI\Front\**Presenter
		Admin: App\UI\Admin\**Presenter
		Api: App\Api\*Presenter
```

Bu yapılandırmaya göre, `Front:Home` sunucusu `App\UI\Front\Home\HomePresenter` sınıfıyla eşleşirken, `Api:OAuth` sunucusu `App\Api\OAuthPresenter` sınıfıyla eşleşir.

 `Front` ve `Admin` modülleri benzer bir eşleme yaklaşımına sahip olduğundan ve bu türden daha fazla modül olması muhtemel olduğundan, bunların yerini alan genel bir kural oluşturmak mümkündür. Sınıf maskesine modül için yeni bir yıldız işareti eklenir:

```neon
application:
	mapping:
		*: App\UI\*\**Presenter
		Api: App\Api\*Presenter
```

Sunum yapan kişi `Admin:User:Edit` gibi çok seviyeli iç içe modüller için yıldız işareti segmenti her seviye için tekrarlanır ve `App\UI\Admin\User\Edit\EditPresenter` sınıfı ortaya çıkar.

Alternatif bir gösterim, dize yerine üç segmentten oluşan bir dizi kullanmaktır. Bu gösterim bir öncekine eşdeğerdir:

```neon
application:
	mapping:
		*: [App\UI, *, **Presenter]
		Api: [App\Api, '', *Presenter]
```

Konfigürasyonda sadece bir kuralımız varsa, genel olanı, kısaca yazabiliriz:

```neon
application:
	mapping: App\UI\*\**Presenter
```

Modüller

Modüller, mantıksal birimlere kolayca bölünmeyi kolaylaştırarak Nette uygulamalarına netlik kazandırır.

Dosyaları sabit diskte klasörler halinde düzenlemeye benzer şekilde, Nette'de sunum yapan kişileri, şablonları ve diğer yardımcı sınıfları modüllere bölebiliriz. Bu pratikte nasıl çalışır? Basitçe yapıya yeni alt dizinler ekleyerek. İşte Front ve Admin olmak üzere iki modüllü bir yapı örneği:

app/
├── UI/
│   ├── Admin/            ← Admin module
│   │   ├── @layout.latte
│   │   ├── Dashboard/
│   │   │   ├── DashboardPresenter.php
│   │   │   └── default.latte
│   │   └── ...
│   ├── Front/            ← Front module
│   │   ├── @layout.latte
│   │   ├── Home/
│   │   │   ├── HomePresenter.php
│   │   │   └── default.latte
│   │   └── ...

Bu dizin yapısı sınıfların isim alanlarına da yansıtılır; örneğin DashboardPresenter, App\UI\Admin\Dashboard isim alanında yer alır:

namespace App\UI\Admin\Dashboard;

class DashboardPresenter extends Nette\Application\UI\Presenter
{
	// ...
}

Uygulamada, Admin modülü içindeki Dashboard sunumcusuna iki nokta üst üste gösterimini kullanarak Admin:Dashboard olarak atıfta bulunuyoruz. default eylemi için Admin:Dashboard:default olarak adlandırıyoruz.

Sunulan yapı katı değildir; yapılandırmada ihtiyaçlarınıza göre tamamen özelleştirebilirsiniz.

Modüller, sunucular ve şablonların yanı sıra bileşenler ve yardımcı sınıflar gibi diğer tüm dosyaları da içerebilir. Bunları nereye yerleştireceğinizi düşünüyorsanız, bir Accessory klasörü kullanmayı düşünün:

app/
├── UI/
│   ├── Admin/
│   │   ├── Accessory/
│   │   │   ├── FormFactory.php
│   │   │   └── AdminLayout.php
│   │   ├── Dashboard/
│   │   └── ...

İç İçe Modüller

Modüller, diskteki bir dizin yapısına benzer şekilde birden fazla iç içe geçme seviyesine sahip olabilir:

app/
├── UI/
│   ├── Blog/             ← Blog module
│   │   ├── Admin/        ← Admin submodule
│   │   │   ├── Dashboard/
│   │   │   └── ...
│   │   ├── Front/        ← Front submodule
│   │   │   ├── @layout.latte
│   │   │   ├── Home/
│   │   │   └── ...
│   ├── Forum/            ← Forum module
│   │   └── ...

Blog modülü Admin ve Front alt modüllerine ayrılmıştır. Bu aynı zamanda App\UI\Blog\Admin ve benzer şekilde görünen isim alanlarına da yansıtılır. Admin alt modülü içindeki Dashboard sunucusuna atıfta bulunmak için, bunu Blog:Admin:Dashboard olarak adlandırıyoruz.

Yerleştirme, alt alt modüllerin oluşturulmasına izin vererek gerektiği kadar derin olabilir.

Örneğin, yönetimde OrderDetail, OrderEdit, OrderDispatch, vb. gibi sipariş yönetimiyle ilgili birçok sunucunuz varsa, Detail, Edit, Dispatch ve diğerleri gibi sunucuların düzenleneceği bir Order modülü oluşturabilirsiniz.

Sunucu şablonlarındaki bağlantılar geçerli modüle görelidir. Bu nedenle, Foo:default bağlantısı geçerli sunum yapan kişiyle aynı modülde bulunan Foo sunum yapan kişiye yönlendirir. Örneğin, geçerli modül Front ise, bağlantı şu şekilde olur:

<a n:href="Product:show">link to Front:Product:show</a>

Bir bağlantı, bir modülün adını içerse bile görelidir ve bu durumda bir alt modül olarak kabul edilir:

<a n:href="Shop:Product:show">link to Front:Shop:Product:show</a>

Mutlak bağlantılar diskteki mutlak yollara benzer şekilde yazılır, ancak eğik çizgiler yerine iki nokta üst üste konur. Böylece, mutlak bir bağlantı iki nokta üst üste ile başlar:

<a n:href=":Admin:Product:show">link to Admin:Product:show</a>

Belirli bir modülde mi yoksa onun alt modülünde mi olduğumuzu öğrenmek için isModuleCurrent(moduleName) fonksiyonunu kullanabiliriz.

<li n:class="isModuleCurrent('MyEshop:Users') ? active">
	<a n:href="Product:">...</a>
</li>

Yönlendirme

Yönlendirme ile ilgili bölüme bakın.

Haritalama

Eşleme, sınıf adının sunum yapan kişinin adından türetilmesine ilişkin kuralları tanımlar. Bu kurallar yapılandırmada application › mapping anahtarı altında belirtilir.

Bu sayfada daha önce bahsedilen dizin yapıları aşağıdaki eşleştirmeye dayanmaktadır:

application:
	mapping: App\UI\*\**Presenter

Eşleme nasıl çalışır? Daha iyi anlamak için öncelikle modülsüz bir uygulama hayal edelim. Sunucu sınıflarının App\UI ad alanı altında olmasını istiyoruz, böylece Home sunucusu App\UI\HomePresenter sınıfıyla eşleşir. Bu, şu yapılandırma ile gerçekleştirilebilir:

application:
	mapping: App\UI\*Presenter

Bu eşleme, App\UI\*Presenter maskesindeki yıldız işaretini Home sunum yapan kişi adıyla değiştirerek çalışır ve sonuçta App\UI\HomePresenter nihai sınıf adı elde edilir. Çok basit!

Ancak, bu ve diğer bölümlerdeki örneklerde görebileceğiniz gibi, sunum yapan sınıfları isimsiz alt dizinlere yerleştiriyoruz, örneğin, Home sunum yapan App\UI\Home\HomePresenter sınıfıyla eşleştirilmiştir. Bu, yıldız işaretinin iki katına çıkarılmasıyla elde edilir (Nette Application 3.2 gerektirir):

application:
	mapping: App\UI\**Presenter

Şimdi, sunum yapan kişileri modüllerle eşleştirmeye geçelim. Her modül için özel eşlemeler tanımlayabiliriz:

application:
	mapping:
		Front: App\UI\Front\**Presenter
		Admin: App\UI\Admin\**Presenter
		Api: App\Api\*Presenter

Bu yapılandırmaya göre, Front:Home sunucusu App\UI\Front\Home\HomePresenter sınıfıyla eşleşirken, Api:OAuth sunucusu App\Api\OAuthPresenter sınıfıyla eşleşir.

Front ve Admin modülleri benzer bir eşleme yaklaşımına sahip olduğundan ve bu türden daha fazla modül olması muhtemel olduğundan, bunların yerini alan genel bir kural oluşturmak mümkündür. Sınıf maskesine modül için yeni bir yıldız işareti eklenir:

application:
	mapping:
		*: App\UI\*\**Presenter
		Api: App\Api\*Presenter

Sunum yapan kişi Admin:User:Edit gibi çok seviyeli iç içe modüller için yıldız işareti segmenti her seviye için tekrarlanır ve App\UI\Admin\User\Edit\EditPresenter sınıfı ortaya çıkar.

Alternatif bir gösterim, dize yerine üç segmentten oluşan bir dizi kullanmaktır. Bu gösterim bir öncekine eşdeğerdir:

application:
	mapping:
		*: [App\UI, *, **Presenter]
		Api: [App\Api, '', *Presenter]

Konfigürasyonda sadece bir kuralımız varsa, genel olanı, kısaca yazabiliriz:

application:
	mapping: App\UI\*\**Presenter