KenMilabel
Ufak 2 not:
1.) Controller Siniflarinin Isimlerinin "Controller" ile bitmesi gerekliligi yok. Controller'inizi "KullaniciDenetcisi seklinde isimlendirebilirsiniz:
Dayle Reeds, Code Bright, pg 86:
In honesty, you can call the Controller whatever you like. As long as your controller extends
either BaseController or Controller then Laravel will know what you are trying to do. However,
suffixing a controllers name with Controller, for example ArticleController is somewhat of a
standard that web developers employ. If you plan to be working with others, then standards can be
extremely useful.
2.)Eger Resourceful ve RESTfull Controller (avantajlarii) kullanilimayacaksa, Controller icindeki method'larin isimleri de ne isterseniz olabilir (getGosterKullanici gibi). Bunun icin routes.php' da Controller methodunu direkt route olarak tanimlayarak istediginiz her isimdeki methodu calistirabilirsiniz. Fakat bu durumda Resourceful Controller'larini kullanma, ve tek bir route tanimi ile Controller icindeki tum restful method verblerine uyan methodlarini kullanma avantajini kaybediyorsunuz. Bu konvansiyona uymadan isimlendirilecek methodlara ayrica bir route olusturmaniz gerekiyor.
KenMilabel
@serginari:
Bence de, Ingilizce deki "migration" bile islevine cok uyan bir isim degil; "Goc" ise, bir yerden "goc etmek", (oradan ayrilmak) gibi geldigi icin cok uygun gelmiyor.
Halbuki "Migration", veritabaniniza tablolarinizi yerlestiriyor (Up). Yani bir yerden goc etmiyorsunuz, "bir yere" goc ediyor, yani (uygulamanizda tanimlanmis olan veri tabanina yerlesiyorsunuz). Onun icin, tercume ederken, "Yerlesim/Yerlesme" bence daha uygun bir terim gibi geldi.
"Seeding" ise, veritabanina yerlestirdiginiz tablolarin, tamamen bos olmasinin uygulamaniza getirecegi sakincalar olmasi durumunda, tablolariniza gerekli ilk kayitlari olusturmanizi sagliyor. Bu yuzden "Tohumlama" yerine, veri tabanina yerlestirilen tablolarin "filizlendirilmesi" demenin (yani tablolarin ilk kayitlarinin olusturulmasi) olarak, hem Ingilizcesine yakin, fakat "tohumlama" dan daha iyi anlasilir olabilecegini dusunuyorum.
Ersin Kandemir
"Closure" kavramı için ne düşünüyorsunuz? Ne diyebiliriz?
sergin
ben sergin, gitHub'da bu isim dolu olduğundan serginari adını aldım.
@KenMilabel Controller bilgisi için teşekkür ederim. Başka bir framework kuralı ile karıştırmış olmalıyım.
Migrasyon kelimesini şimdiye dek şöyle bilirdim. Programlama dilinin yeni bir sürümü çıkar, bazı şeyler değişir. Buna uyum sağlamak için şunu şunu yapmak lazım. Ya da siz VB.NET'ten C#'a gelmişsiniz, eski uygulamanızı ne yaparak yeni platforma uygun hale getirirsiniz.
Uygulamamızı bir süreç olarak düşündüğümüzde Laraveldeki migrasyon bir nevi sürüm kontrolü olarak tanımlanmış, Bu yüzden seyahatimizdeki önemli konaklama yerleri, dönüm noktaları olarak anlıyorum. Belki uygulamalar geliştirdikçe daha uygun bir türkçe karşılık bulabileceğiz.
Seeding için ise veritabanını test verileriyle doldurmak denmiş, ben sadece test verisi olarak algılıyorum. Seed tohum, çekirdek ya da ekin ekmek diye biliyorum ve filiz olarak hiç rastlamadım. Tohumlama ve filizlendirme yerine "tohum ekme" nin daha uygun olduğunu düşünüyorum.
sergin
Ersin Kandemir yazdı"Closure" kavramı için ne düşünüyorsunuz? Ne diyebiliriz?
callback yerine kullanılmış. Closure: kapatma, bitirme, son verme'den, ben "bitirme fonksiyonu" olarak çevirdim.
Ersin Kandemir
@sergin, sizin kullandığınız durum için "port etmek" daha uygun gibi. Mesela Python 2.x betiklerinin Python 3.x'e port edilmesi gibi.
Migrasyon daha çok veritabanı eşleme(sync?) ile ilgili bir işlem sanki.
Ersin Kandemir
sergin yazdıErsin Kandemir yazdı"Closure" kavramı için ne düşünüyorsunuz? Ne diyebiliriz?
callback yerine kullanılmış. Closure: kapatma, bitirme, son verme'den, ben "bitirme fonksiyonu" olarak çevirdim.
Bence bir kavram listesi çıkartıp hangilerinin çevrilip, hangilerinin olduğu gibi bırakılacağına karar vermeliyiz.
Closure olduğu gibi kalabilir mesela.
KenMilabel
Bu arada, sayin angelside hakli,
- "BaseController"'i, "TemelController" olarak ceviremezsiniz. Cunku kullanilan (extend edilen) sinif, Laravel framework'a ait olan bir sinif ve ismi sabit "BaseController". Fakat kendi Controller sinifiniza istediginiz ismi verebilirsiniz. Sonuna "Controller" eklenmesi de sart degil.
- Method ismi showProfile() in, gosterProfil() olarak tercume edilmesi ise bundan farkli birsey. Ayri bir route tanimlayarak Controller'daki gosterProfil() methodunu rahatca kullanabilirsiniz. Method isminin basinda "get", "show", vb olmasi da gerekmiyor. Fakat, bu sekilde isimlendirdiginizde, Ruby tarzi Resourceful Controller, yani tek bir route tanimlayarak, Controller'unuzdaki butun RESTful verbleri ile baslayan methodlariniza ulasma imkanini kaybediyorsunuz. Ayri bir route tanimlamaniz gerekiyor. Bunu kaybetmeden Turkcelestirme icin belki, showProfile() method ismi, ornegin showGosterProfil() olarak tercume edilebilinir.
Bunun yani sira, sayin MetalOxide ve Ersin Kandemir'e kesinlikle katiliyorum. Soyle ki:
Çevirilerde kod kısımlarında degisebilen (serbest olan) yerlerindede, ozellikle Türkçe isimlerin olmasını, yeni ogrenenler icin cok ama cok faydali goruyorum.
Ben Laravel'i kendim Ingilizce'sinden ogrenirken, verilen kod orneklerinde hangi terimin "Laravel'in" mecburi terimi, hangi kelimenin ise sadece o ornekte kullanilan bir Ingilizce terim oldugunu anlamak icin zorlanmistim, anlamak icin denemeler yapmam gerekmisti.
Kod orneklerinde, ornegin kullanmakta oldugumuz "UserController" da Controller'in mecburi olup olmadigini bile bilmiyoruz. Veya Resourceful bir Controller kullanildiginda showProfile() yonteminde, "show" mecburi, "Profile" mecburi degil. O zaman bunu, kod orneklerinde showGosterBilgilerini(), vb gibi tercume edersek, tercume edilmemis Ingilizce olan kisminin Laravel'e ait ve "mecburi" oldugunu, Turkce isimli kisminin ise "serbest" oldugunu Turkce'den ogrenenlere gosterme imkanimiz olur. Bunun, framework'u Ingilizce'sinden ogrenmeye gore bile daha avantajli ve daha aydinlatici olacagina inaniyorum.
sergin
migrasyon programlama dillerinde genel olarak bu anlamda kullanılıyor. Örneğin son olarak jQuery son birkaç sürümünde önemli değişiklikler yaptığı için eski sürümlere göre yazılmış kodların yeni sürümlerle uyumlu çalışabilmesini sağlayan migrasyon eklentileri yayınladı. Laraveldeki başka anlamda tabi.
KenMilabel
@serginari:
Cok memnun oldum, benim ismim de Kenan. On bilgi olarak: Ben pek programci sayilmam herhalde, kendi islerimde kullanmak icin agirlikli olarak "database", SQL ve server uygulamalari uzerinde calisiyorum. Programlama olarak, sadece on yuz (front-end) olarak kullanmak icin, VB uygulamalari hazirlayip, kullandim. Son 2-3 senedir de, database'lerimi internet uzerinden ve on yuzu (front-end) olarak, bir web-browser(ve HTML) kullanabilmek icin PHP ogrenmeye basladim, ve ilk framework tecrubem olarak Laravel 3'e basladim.
Laravel'deki Migration ve Seeding ile ilgili olarak (nacizane) gordugum su:
1.) Evet, Migration, dokumantasyonda, (uygulamanizin?) bir nevi surum yonetimi olarak soylenmis ve de "ayni uygulama gelistirmesi uzerinde calismakta olan bir ekibe kolaylik saglayacagi" belirtilmis.
Fakat, ozunde(!), Migration'in ve de Seeding'in de, (PHP de yazilmis olan) front-end uygulamanizdaki degisikliklerle veya "surumu"nun kontrolu ile hicbir alakasi(!) yok denilebilir.
Cunku, hic bir database kullanmaya ihtiyac duymadiginiz (ve gelistirmekte oldugunuz) bir Laravel uygulamaniz da rahatlikla olabilir. Migration'in da bunda size hicbir surum kontrolu veya ekip calismasi katkisi olmaz.
Veya, bir database kullanan uygulamanizi, lokal bilgisayarinizda gelistirirken, ayni database'i back-end olarak kullanmakta olan baska bir front-end yaziliminiz da olabilir.
Migrations ile yapacaginiz degisiklikler, sadece bu database'i etkiler. Uygulamanizi etkilemez, uygulamizin gercek bir surum kontrolunu de yapamaz.
Bu yuzden, "migrations" icin, (PHP kullanan front-end uygulamanizin degil de), uygulamanizin kullandigi back-end (SQL) database sisteminin "surum yonetimi" denilmesi herhalde daha dogru olurdu.
2.) Ayrica da, benim gordugum kadari ile, migrations'in ve seeding'in esas fonksiyonu (dokumantasyonda belirtilenlerden) farkli olabilir.
Anladigim kadari ile, migrations'in esas fonksiyonunun, soyle olabilecegini dusunuyorum:
Database kullanan bir uygulamanizin gelistirmesini tamamladiniz, artik domain isminizi yonledirdiginiz web-hosting firmasinin server'ina yukleyeceksiniz.
Web hosting firmasi size hem PHP ortami, hem de "bos" bir SQL database sagliyor.
Database kullanan bir PHP uygulamanizi, web-hosting firmanizin server'ina "upload" ettiniz.
Fakat web-hosting'in size sagladigi (uygulaminizin kullanacagi) oradaki SQL database'iniz ise hala bos. (database'iniz, uygulamanizi gelistirdiginiz lokal bilgisayarinizda kaldi)
Bu upload ettiginiz PHP-Laravel uygulamanizin kullanacagi database semanizi da oraya tasimaniz (yerlestirmeniz), oraya migrate ettirmeniz gerekiyor.
Kabaca 2 alternatifiniz var:
a. Ya PHP uygulaminizi gelistirirken kullanmakta oldugunuz lokal SQL server database sema'sinin, bir "dump"ini alip, web-hosting firmanizin size acmis oldugu database'e manuel olarak tasiyacaksiniz. (Ben bu sekilde yapiyorum)
b. Veya, upload etmis oldugunuz bu PHP uygulamaniz, yaratmis oldugunuz Migrations'lari kullanip, web-hosting firmasinin size saglamis oldugu database sisteminde, ayni bu sema ve tablolari oraya kendi "yerlestirecek". (Ben bu sekli denemedim)
Veya, yine ayni sekilde, mesela domain name'inizi yonlendirmis oldugunuz web-hosting firmanizi, bir baskasi ile degistirmek istediginizde, eski web-hosting firmanizin database'indeki database semanizi, yeni web-hosting firmasinin server'indaki database'de de yaratmaniz ve oraya da yerlestirmeniz (oraya goc etmesi/migrate) de gerekebilir.
Bana, (bunu cok emin olarak soylemiyorum, ama) migrations'in esas fonksiyonu sanki buymus gibi geldi. (yukarida da dedigim gibi, migrations'lar web-hosting server'inda calistirilabilir mi, veya nasil calistirilir, hic denemedim, bilmiyorum. Ben database semalarimi simdiye kadar hep manuel olarak ve SQL dump olarak tasiyorum).
Seeding icin de, seedinglerin esas amacinin, test "data" si amaci oldugunu zannetmiyorum:
"Seeding"ler icin de, "migrations" lar gibi ayni sekilde:
Lokal bilgisayarinizda gelistirdiginiz uygulamanizi, (production) server'ina tasidiginizda, ve gelistirirken uygulamanizin lokal SQL server'inizde kullanmakta oldugu database semasini, migrations'larini kullanarak, gerekli tablolarini oradaki database'e yerlestirdiginide, bu tablolari "bos" olarak yaratacak/yerlestirecek.
Fakat, ornegin menu basliklari bilgilerini bir database tablosunda depolayan ve oradan alan bir CMS uygulamanizda, "menuler" tablosunun "bos" olmasi durumunda, CMS uygulamaniz daha bastan calismayacagi icin, uygulamanizin menu basliklari bilgilerinin, (migrations ile bos tablolarinin yaratilmasi akabinde) bir menuler tablosuna "seed" edilmesi, "filizlendirilmesi" gerekiyor ki, uygulamaniz menuleri ile birlikte calissin ve bir CMS kullanicisi icin, icabinda bu menuler kullanilabilinip, baska yeni menuler de yaratma imkani olsun.
Bu sekilde dusundugumde, uygulamamizi, yeni bir database ortamina ve sistemine tasidigimizda, migrations (yerlesimler) ile yaratilacak bos tablolari, uygulamanin bastan calisabilmesi icin ihtiyac duyacagi kayitlari (ornegin uygulamadaki menu isimlerini) tablolarda yaratmaya (seedings) "filizlendirme" demek daha uygun olur diye dusunuyorum.
Cok selamlar,
KenMilabel
Ozet olarak soyle soyleyeyim:
Bir musteriniz sizden bir web-uygulamasi yazilimi istedi. Siz de PHP-Laravel uygulamasini hazirlayip, bir CD'ye kopyalayip kendisine verdiniz. Fakat bunun yaninda, uygulamanin kullanacagi database semasini da ayrica bir sql dump (database.sql) kendisine vermeniz gerekiyor.
Bunu ayrica vermek yerine, PHP-Laravel yaziliminizi, yuklendigi ortamdaki mevcut database sisteminde kullanacagi sema ve tablolari, ve tablolardaki ilk gerekli kayitlari (mesela menuler) kendi yaratacak sekilde hazirliyorsunuz. Bunun icin de migrations ve seedings kullaniliyor. Eger yanlis anlamadiysam.
Ersin Kandemir
Evet, migration ve seeding anlattığınız gibi bizim bilmediğimiz bir başka kullanım alanı yoksa. Uygulamanın ortamını hazırlıyorlar.
KenMilabel
Dokumantsayon Yerellestirme Calismalarinin tamamlanip, son ve kararli haline getirilmesini muteakip, mumkun mu bilmiyorum ama, bir sonraki "challange", LARAVEL framework'un Turkce Version'unun olusturulmasi olabilir.
Bu durumda, Turkce kullanicilarina buyuk bir hizmet yapmis oluruz. Tek kisitlari, php ve HTML(CSS) Ingilizce terimleri olur. Hatta Turkce olan bir "framework" ile bunun bile buyuk kismi hallolabilir.
Bu konuda Sinan Eldem'in ve Taylor Otwell'in fikirleri gerekiyor.
Ersin Kandemir
Çekirdeğe dokunmadan yapmak lazım öyle bir şey olacaksa. Facades denen olay tam olarak ne bilmiyorum ama onlara alias atanabiliyor. Onları Türkçeleştirmek kolay fakat metodlarının isimleri için başka bir şey düşünmek lazım.
Ben Framework'ün çevrilmesini gerekli görmüyorum. Dokümantasyon Türkçe olduktan sonra anlaşılması çok zor olmayacaktır.
Ersin Kandemir
app.php
'aliases' => array(
'Uygulama' => 'Illuminate\Support\Facades\App',
'Artisan' => 'Illuminate\Support\Facades\Artisan',
'Yetki' => 'Illuminate\Support\Facades\Auth',
'Blade' => 'Illuminate\Support\Facades\Blade',
'Onbellekleme' => 'Illuminate\Support\Facades\Cache',
...
),
Bu şekilde.
Aristona
Ersin Kandemir yazdıÇekirdeğe dokunmadan yapmak lazım öyle bir şey olacaksa. Facades denen olay tam olarak ne bilmiyorum ama onlara alias atanabiliyor. Onları Türkçeleştirmek kolay fakat metodlarının isimleri için başka bir şey düşünmek lazım.
Ben Framework'ün çevrilmesini gerekli görmüyorum. Dokümantasyon Türkçe olduktan sonra anlaşılması çok zor olmayacaktır.
Facade bir design pattern. Amacı zor olan konuların üzerine bir absraction çekip daha kolay bir çalışma ortamı sunmak.
Mesela bir örnek vereyim. Kullanıcı bilgisayarın düğmesine bastığında çalışmasını ister, yani kullanıcı aşağıdaki kodu yazar;
/* Kullanıcı */
class You {
public static void main(String[] args) {
Computer facade = new Computer();
facade.start();
}
}
Ama bilgisayarın başlatılması için çok fazla şey gerekir.
/* Complex parts */
class CPU {
public void freeze() { ... }
public void jump(long position) { ... }
public void execute() { ... }
}
class Memory {
public void load(long position, byte[] data) { ... }
}
class HardDrive {
public byte[] read(long lba, int size) { ... }
}
/* Facade */
class Computer {
private CPU processor;
private Memory ram;
private HardDrive hd;
public Computer() {
this.processor = new CPU();
this.ram = new Memory();
this.hd = new HardDrive();
}
public void start() {
processor.freeze();
ram.load(BOOT_ADDRESS, hd.read(BOOT_SECTOR, SECTOR_SIZE));
processor.jump(BOOT_ADDRESS);
processor.execute();
}
}
Laravel'de ise Facade için bir örneği aşağıda vereyim.
View::make('merhaba') yazdığımızda aslında;
Illuminate\Support\Facades\View::make('hello'); yazmış oluyoruz. Laravel bunu aliaslara bakarak kendisi çeviriyor.
Laravel, bizi bu uzun namespaceleri yazmakla uğraştırmamak için View adında bir alias oluşturulmuş.
Wiki sayfası:
http://en.wikipedia.org/wiki/Facade_pattern
smh
aslında alias ların çalışma mantığı, php5.3 ile gelen
class_alias fonksiyonudur.
Ersin Kandemir
Açıklamalar için teşekkürler. OOP ile ilgili şeylere pek hakim değilim. Özellikle design-pattern çeşitlerine.
pellempus
Emeği geçen herkese teşekkürler,
Ben de route için rota değil de "Yöneltme" olması taraftarıyım. Daha anlamlı duruyor.
Bir de çevirisi yapılan kavramların İngilizcesi de belirtilirse daha iyi olacaktır.Zaten bir çoğunda yapılmış ama eksik olanlar var.
Mesela:
http://dokuman.laravel.gen.tr/docs/localization
Burada Yerelleştirme (Localization) şeklinde başlık olması daha iyi olur.
İnternette bir çok döküman İngilizce. O yüzden Localization kelimesini gören biri en azından şaşkınlık geçirmez.
Aslında ben bu kelimelere İngilizce olarak bakmıyorum. Yazılımın evrensel dili olarak bakıyorum ve yerelleştirmesine karşıyım. Hangi framework açarsanız açın "Route" artık evrensel bir kavramdır. Route.php gördüğünüzde ne yapacağınızı bilirsiniz. Ancak bunu Türkçe olarak öğrenmiş biri, eğer İngilizcesini de bilmiyorsa zorluk yaşayacaktır. Bu yüzden parantez için orjinalleri belirtmek önemli.
Saygılar,
Aristona
pellempus yazdıEmeği geçen herkese teşekkürler,
Ben de route için rota değil de "Yöneltme" olması taraftarıyım. Daha anlamlı duruyor.
Bir de çevirisi yapılan kavramların İngilizcesi de belirtilirse daha iyi olacaktır.Zaten bir çoğunda yapılmış ama eksik olanlar var.
Mesela:
http://dokuman.laravel.gen.tr/docs/localization
Burada Yerelleştirme (Localization) şeklinde başlık olması daha iyi olur.
İnternette bir çok döküman İngilizce. O yüzden Localization kelimesini gören biri en azından şaşkınlık geçirmez.
Aslında ben bu kelimelere İngilizce olarak bakmıyorum. Yazılımın evrensel dili olarak bakıyorum ve yerelleştirmesine karşıyım. Hangi framework açarsanız açın "Route" artık evrensel bir kavramdır. Route.php gördüğünüzde ne yapacağınızı bilirsiniz. Ancak bunu Türkçe olarak öğrenmiş biri, eğer İngilizcesini de bilmiyorsa zorluk yaşayacaktır. Bu yüzden parantez için orjinalleri belirtmek önemli.
Saygılar,
Rota kelimesi değiştirilirse çok karışıklık çıkacağını düşünüyorum. Yöneltme, Yönlendirme, Yönlendirici vb. birçok opsiyon mevcut. Rota hem Route kelimesine yakın, hemde uygun bir sözcük. Kişisel düşüncem değiştirilmemesi gerektiği yönünde.
Parantez içerisinde Türkçe terimlerin İngilizcesinin yazılmasını kesinlikle doğru buluyorum, ancak her terimin yanına terim yazmaktansa, bir tane dosya oluşturup tüm çevirilerimizi orada not olarak bulundurabiliriz.
Örneğin bu sayfadaki bilgileri (
https://laravel.gen.tr/d/140), Readme.md içinde bir section açıp orada belirtebiliriz. Bunu yapmamız gerektiğini düşünüyorum çünkü bazı çeviriler gerçekten Türkçe'ye uygun olarak çevirilemiyor. Mesela unit test terimi yerine ünite testi kullanılmış (Çevirisi doğru, ünite testi, nesne testi, birim testi vb.) ancak Google'da arama yaptığınızda karşınıza 2. Sınıf Sosyal Bilgiler 3. Ünite Testi gibi alakasız sonuçlar çıkıyor.