ahmet usal wrote: > An itibariyle Emacs Wiki sayfasına da ekledim. > > Aycan Bey ilginiz ve olumlu yorumunuz için teşekkür ederim. Ben bu > konuda biraz farklı düşünüyorum. > > Topluca Web 2.0 diye adlandırdığımız ; Ajax - Javascript etkileşimiyle > web uygulamaları oluşturma konsepti bence programcı ile tasarımcı > arasındaki uçurumu azaltmakta; Şöyleki: > > Artık görsel yönden ne kadar güçlü tasarım yaparsanız yapın; > kullanıcıyla etkileşim halinde olmazsa; webde çığla büyüyen örneklere > bakan müşteriler ve kullanıcılar; yapılan çalışmayı yetersiz > bulacaklardır. Kullancıyla etkileşim için de; Temel web kodlama > altyapınız olmalıdır; içeriği sunumdan ayırmayı; css-html-javascript > üçlemesini iyi kodlamayı becerebilmeniz gerekir. Bu da tasarımcıyı bu > işe dahil edecek bir süreçtir. > > Adobe firması bile Spry diye lisansı görece serbest teknolojileri web > geliştiricilerinin kullanımına > açtı:http://labs.adobe.com/technologies/spry/ adresine bakın. Ortalık > Framework-Library diye kaynıyor. Programcılara KISS (Keep it Simple > Stupid) and DRY(Don't Repeat Yourself) prensipleriyle; mevcut > sunucu-istemci taraflı frameworklerle kolayca çalışabilecekleri empoze > ediliyor. > > Bu yaklaşımlar küçük projelerde tasarımcıların da; frameworklerle > kendi işlerini görebilecekleri anlamına geliyor. Eski tasarım araçları > artık yetersiz kalıyor. Dreamveawer en yeni sürümünde bile bir > "Firebug" eklentisinin yaptıklarını yapamıyor. Ortalık herzamankinden > güçlü ve işlevsel CMS'lerle dolu. Ben şahsen işlerimi bu şekilde > halletmeye çalışıyorum. (Bu yüzden ne tasarımcıyım ne de programcı:) > > Bu durumda ister istemez tasarımcı bile olsa herkes elini koda atmak > zorunda. Yapabileceği en iyi şeyde kolay kullanabileceği, işlevsel bir > metin editörü ile html-css-js kodlayıp, Firefox ile test etmek:) > > Mac makinalardaki Textmate bu yüzden patladı; Tüm bilgi veren > Screencastlerde en çok göreceğiniz kodlama ve tasarım unsurları > MacOSX-Textmate ve Firebug:) > > Ben sadece eski tüfekler metin düzenleyicilerine de emek verildiğinde > istenilen editör işlevselliğinin her platformda; özellikle web > kodlamasında fazlasıyla yakalanabileceğine bir örnek vermeye çalıştım; > kendim zevkle kullanıyorum...Win32 ortamında temiz screencast üretmeyi > becerdiğimde bu tür örnekleri de ekleyip buradan haber verme > niyetindeyim...Özellikle merak ettiğiniz modlar varsa onları > belirtirseniz, tanıtımda öncelik sahibi olurlar. Beni yanlış anlamanızı istemem. Bahsettiğiniz araçları kullanıyoruz ve sizin paylaşımlarınız ile bu araçlardan daha iyi faydalanıyoruz. Ancak ben tasarımla ilgilenen insanlardan yıllardır ufak tefek de olsa kod yazmalarını beklerken, bu ısrarlarımın yersiz olduğuna tanık oldum. Tasarımcılar bazen acemilikleri ile, bazen de sanatsal bakış açılarıyla üretimlerini tamamen görsel kaygılar üzerine yoğunlaştırıyorlar. Böyle de olması gerektiğini düşünüyorum. Aksi endüstriyel bir tasarım sürecine ve belki de bir miktar mühendisliğe de giriyor ki böyle bir sonuç yaptığımız web sitelerinin "ciddi anlamda tasarım çalışmaları var mı?" sorusuna götürüyor beni.
Bu düşüncemi desteklemek için var olan ürünlerin ve bunların çıktılarının ne kadar birbirine benzediğini örnek verebilirim. Biz yıllardır sütunlarla, menülerle desteklenmiş sitelere tanık olduk. Çünkü kaygılarımız görselden uzaktı. Tasarım deyince bilgisayar ile insan arasındaki etkileşimi anladık yıllarca. Oysa bunun ötesinde birşeyler yapmaya çalışanlar vardı. Hoş olanın ötesinde birşeyler var mıdır? Gerçek tasarımcılarla çalışabilecek yöntemleri bulmamız gerektiğini söylemeye çalışıyorum aslında. Bunun yönteminin de icra edene teknik eğitim vermekten geçmediğini düşünüyorum. > Sizin verdiğiniz UCW platformuna dayalı örneği inceledim. Mesela > http://mootools.net - Mootools diye bir javascript kütüphanesi; aynı > sizin yolunuzla javascript içinden Dom ve Css üretimi ve etkileşimine > imkan veriyor. Bu anlamda uygulamanız güçlü. Ama frameworkler de en > çok tercih edilen özellik; uygulama mantığının, veritabanın ve sunumun > ayrı katmanlarda çalıştırılması.(Sizin de bildiğiniz > Model-View-Controller Patterni) Bu programcı-tasarımcı ayrımını ve > işbirliğini kolaylaştırıyor. > > Sizin uygulamanız bileşen tabanlı ve tüm bu uygulama üretim mantığı > içiçe anladığım kadarıyla(yanlış anlıyorsam lütfen beni düzeltin.) > Bu anlamda programcı-tasarımcı ayrımını tamamen ortadan kaldırıyor > gibi göründü bana...Yani genel yaklaşımdan farklı bir yol. > MVC'yi ben tasarımcı ve programcının ayrılması olarak görmüyorum, bunlar zaten ayrık olgular bence. Uygulamanın görsel çıktısı, modeli ve bunların etkileşimlerinin birbirini etkilemeyecek şekilde kodlanabilmesi olarak algılıyorum. Bu şekilde düşünülürse geliştirmekte olduğumuz uygulama sunucusu ve bunun kullandığı kütüphaneler işlerini görüyorlar. Bir senaryoyla örnek verebilirim. Bir ana sayfa tasarlarken, öncelikle tasarımcının her türlü aracı kullanarak (kağıt kalemden, bilgisayar destekli çizim programlarına) bir konsept ortaya koymasıyla başlıyoruz. Daha sonra konsept tasarımın uygulanabilirliği üzerine düşünüyor ve gerekli durumlarda tasarımcıdan güncellemeler talep ediyoruz. Bu tasarımı bir makina sunacağı için sayısallaştırmak, işleri kolaylaştırmak için uygulamayı soyutlayarak modellemek ve bir akış mantığı kurmak gerekiyor. Bunu da lisp programcıları sürdürmeler ve nesnel programlama ile yapabiliyorlar. Bir giriş kutucuğu (login box) düşünecek olursak. Bu sayfanın soyut modelini nesnel olarak bileşenlerle aşağıdaki gibi kurulabiliyor. (defcomponent login-box (ajax-widget) ((username ...) (password ...)) (:default-initargs :dom-id "login-box")) (defmethod render (lb login-box) (<:form :id "login-form" :method "post" :action "#" (<:input :type "text" :name "username" :id "uname") (<:input :type "password" :name "password" :id "pass") (<:input :type "submit" :value "giriş" :action (if (authenticated? login-box) (call 'secure-main)))) Buraya kadar bileşeni ve bileşenin nasıl görüntüleneceğini yazdım. HTML çıktıyla birlikte giriş tuşunun ne işlevi olduğunu da ekledim. Ancak dileyen programcı bu işlevi aşağıdaki gibi de verebiliyor (belirteyim, benim tanıdığım programcılar bu ayrımı kullanmayı tercih etmiyorlar). (defmethod render-javascript (lb login-box) (ec :element "login-form" :event "onsubmit" :action ....)) (defserver-action submit-login (lb login-box) (server side code...)) (defclient-action submit-login (lb login-box) (client js code...)) Burada tanımlı javascript çıktısı elbette sayfanın içerisinde HTML ile birlikte girişimli olarak üretilmiyor. Tanımladığımız her javascript controller.js adlı kontrol dosyası olarak üretilerek HTML sayfamıza bağlanıyor. HTML çıktının nasıl bir görsel ile destekleneceğini ise aşağıdaki gibi programlayabiliyoruz. Burada programlayabilmekten kastım, oluşturulacak CSS çıktısının dinamik olarak (sunucu tarafındaki modele de bağlı olabilerek) oluşturulabilmesi. (defmethod render-css (lb login-box) (<:css "#login-box" :background-color (get-user-color (current-user)) :color "black")) Gene buradaki CSS çıktısı da sayfamıza style.css adıyla bağlanıyor. HTML içerisine girişmiyor. Ayrıca bütün kodlamayı dikey olarak lisp ile yapabilmemiz, gelişmiş özellikleri de kullanabilmemize olanak veriyor. Burada her problemi çözen bir şeyden bahsetmiyorum. Sadece geliştiricilerin daha hızlı uygulama geliştirmesine olanak sağlamaktan bahsediyorum. Bu örneklerle siz nasıl bir şeyler beklerdiniz? Sizin karşılaştığınız problemler neler ve nasıl çözümler önerebilirsiniz? Yorumlarınızı bekliyorum. Sevgiler... -- Aycan iRiCAN C0R3 Computer Security Group http://people.core.gen.tr/~aycan.irican/ _______________________________________________ cs-lisp mailing list cs-lisp@cs.bilgi.edu.tr http://church.cs.bilgi.edu.tr/lcg http://cs.bilgi.edu.tr/mailman/listinfo/cs-lisp
