Session'daki attribute'lerin standart tag library ile okunabilmesi

Session içinde varolan attribute'leri standart tag library ile okuyabilmek gayet kolaydır.

<c:set var="test" value="${domain_test}"/> yaptığımızda bütün scope'lar içinden arayarak "domain_test" objesini bulur. Hatta bu attribute'un session da olduğunu bildiğimiz için <c:set var="test" value="${domain_test}" scope="session"/> diye verirsek de olur.

Fakat benim karşılaştığım sorun da olduğu gibi eğer session'a koyduğunuz objenin isminde "nokta" varsa "c:set" yukarıda örneklerde olduğu gibi davranmıyor.

Session'a koyduğumuz objenin ismi "domain.test" olsun. Bu durumda <c:set var="user" value="domain.test" scope="session"/> şeklinde tanımlarsak tag library session'daki domain objesinin test attribute'ünü set etmeye çalışacaktır. Eğer uyanık davranıp <c:set var="user" value="'domain.test'" scope="session"/> şeklinde değiştirirseniz zaten parse hatası alacaksınız :).

Gelelim çözümüne, <c:set var="test" value="${sessionScope['domain.test']}"/>
şeklinde tanımlamamız gerekiyor.

Bu durum JSTL 1.0 için sorun oluyor olabilir. 1.1 için denemedim.

JDK 1.4 ile Eclipse 3.3 sorunu

Eclipse 3.3 çıkalı kısa bir süre oldu. Tabi hemen yeni özelliklerini test etmek istedim. Her şey çok güzel fakat WTP kurdum çalışmadı. Spring IDE kurdum çalışmadı. Nasıl olur diye araştırırken Spring IDE'yi Eclipse 3.2'ye kurdum yine çalışmadı :). Sonuçta anlaşıldı. Eclipse 3.3 JDK 1.4 ile çalışıyor. Ama onun için geliştirilen plug-in'ler 1.5 istiyor.
Bu yüzden sizde eğer Eclipse 3.3 ve onunla beraber çıkan bütün platformları sorunsuz kullanmak istiyorsanız JDK 1.5 kullanın :).

Büyük projelerde kod organizasyon problemi

Büyük yazılım projelerinin en önemli sorunlarından biri çok uzun sürelerde geliştirildikleri veya istekler zamanla değiştiği için kod organizasyonlarının bozulmasıdır. Bir yerden sonra bu kodların refactor edilmesi gerekiyor. Juergen Hoeller(chief architect of the Spring Framework) bu konuda Spring Experience sempozyumunda yaptığı sunum ilgimi çekti. Sunun 88 dakika olduğu için bunun özeti daha çok işimi görecekti. Tabi özetini de buldum :). Bende özetin özetini yaparak özeti bir seviye daha ileriye götüreyim.

Yazılımlar geliştirilirken genellikle kod organizasyonu düşünülmez, zamanla kendiliğinde oluşur.
Paket bağımlığı ve modül bağımlığı konusunda "best practice" alınabilecek fazla kaynak bulunmuyor.
Kodlar mantıksal olarak organize edilmeli. "Code base" yıllar sonra tamamen yeni requirementlar olsa bile orjinal yapısına göre geliştirilmeye devam edilmeli.

Jurgen "Çoğu açık kaynak kodu yazılımları paket bağımlılığı konusunda kötü örnek oluşturuyor. JDK ve Hibernate gibi projeler örnek verilebilir." diyor.

Çift yönlü bağımlılık paketlerin yeniden kullanılabilirliğini azaltmaktadır. Zor olan kısmı tek yönlü bağımlılık yaparken kod duplication yapmamak. Çift yönlü bağımlılık için temel sebep aynı kod diğer pakette varken yeniden yazmamak. Bunun için gerekirse paketlerin yerlerini değiştirmek ama tek yönlü bağımlılık prensibini bozmamak gerekir.

Modülleri tanımlamak "challenging" olabilir. Modüller temel olarak deployment ihtiyaçlarına ve "conceptual boundaries"e göre oluşur. Bazıları modülleri "multi-tier" ayrımı göre yapıyor, fakat bu mantıksal modüllere uygun olmadığı için sorunlara sebep olur.

Temel olarak modüller "low coupling"- "high cohesion" prensibine göre düzenlenmelidir.

Her bir modülün bütün sistem içinde ayrı bir rolü olmalıdır ve bu rol herkes tarafından kolaylıkla anlaşılabilmelidir.

Spring geliştirilirken en önemli problem backward compatibility'miş. Küçükte olsa API farklılaşmasına izin verilmiş ama kod çiftlenmesine müsade etmemişler.

Eğer yeni bir modül ekleniyorsa bunun projenin neresinde olacağı üzerinden çok dikkatli olmuşlar. Kullanılan diğer frameworklerdeki değişiklikler bile spring kullanıcılarında aksettirilmemiş.

Bağımlılıkları düzenli olarak gözlemek ve yönetmek için araçları kullanmak gerekiyor.
Spring için JDepend ve SonarJ kullanılıyor.

http://www.infoq.com/presentations/code-organization-large-projects
http://mikenereson.blogspot.com/2007/06/spring-on-code-organization-for-large.html