ქართული საფიხვნო

jordano

Active Directory–სთან სამუშაოდ Java–ს ბიბლიოთეკები არ სჭირდება

AD–ს აქვს LDAP ინტერფეისი და პირდაპირ მაგით ხდება მუშაობა. მე ბლომად კოდი მაქვს ნაწერი მაგისთვის. თან არამარტო პაროლის შემოწმებისთვის, არამედ ხშირად უფლებების გაწერისთვის. ძალიან მარტივია. ვინმეს რამე უფლება უნდა პროგრამაში? მიმართავს მხარდაჭერის სამსახურს, ჩასვამენ შესაბამის ჯგუფში სტანდარტული საშუალებებით და ჰაიდა.

გუგლში ტონობით მასალა მოიპოვება მაგ მიმართულებით. უბრალოდ ის უნდა დაამუღამო, LDAP Query როგორ უნდა დაწერო და ზოგადად LDAP–ის სტრუქტურა როგორია.

http://java.sun.com/products/jndi/tutorial/ldap/index.html შეგიძლია ამით დაიწყო

მე თვითონ ამას ვიყენებ სამუშაოდ და LDAP Query–ებზე სავარჯიშოდ: http://jxplorer.org
_________________
Waiting for the revolution...

Alecoder

აქა მშვიდობა.
ესეიგი ჩემი ნელი სვლით და დიდი ინტერესით მივყვები ჩემს უკვე საყვარელ ჯავა 2 - ის წიგნს. მივედი როგორც იქნა მემკვიდრეობის უშუალო განხილვაზე სადაც ერთმა მეტად საინტერესო მასალამ მიიპყრო ჩემი ყურადღება ესაა super - ი.

რამდენადაც ცნობილია მემკვიდრე კლასს შეუძლია აიღოს მშობელი კლასიდან ყველა წევრი წვლადი და წევრი მეთოდი. თუმცა არის შეზღუდვაც. ანუ ის რომ, თუ მშობელი კლასის რომელიმე წევრს აქვს განსაზღვრული private ამ შემთხვევაში პირდაპირი წვდომა ქვეკლასიდან ამ ცვლადთან არ გაგვაჩნია.

შესაბამისად ჯავა როგორც სამეფო პროგრამირების ენა, რა სამეფო ენა იქნება თუ იმ პრობლემას ვერ გაუმკლავდა რომელსაც ქვე კლასიდან მშობელი კლასის პრივატ ტიპის ელემენტთან წვდომა ვერ შეძლო.

რამდენადაც გავიგე ფუნქცია super გვაძლევს საშუალებას, ქვე კლასიდან კონსტრუქტორის დახამრებით მივწვდეთ მთავარი კლასის private ტიპის ცვლადს და მოვახდინოთ გარკვეული ზემოქმედებაც.

ანუ ქვეკლასის კონსრუქტორში განსაზღვრული super - იძახებს მთავარი კლასის კონსტრუქტორს პარამეტრების რაოდენობის შესაბამისობით და ნაცვლად მთავარი კლასის კონსტრუქტორის პარამეტრებისა აწვდის ქვე კლასის კონსრუქტორში გადაცემულ პარამეტრებს. რაც საბოლოოდ იგივეს გავს როცა კლასსში ავღწერთ პრივატ ტიპის ელემენტებს და მასთან ფუნქციის საშუალებით ვურთიერთობთ.

ნუ ეს პირველი მიდგომაა ამ ფუნქციის. არის კიდევ მეორე მიდგომაც თუმცა აღარ ჩამოუვლი ეხლა

აბა რამდენად სწორად ვიბაასე?

არა უბრალოდ რაც დრო გადის უფრო მიყვარდება ეს ენა და დღეს ემოციები ვეღარ დავძლიე თან შეგეხმიანეთ

DaTval

jordano

მოკლედ რა, ეგ ჯავა 2–ის წიგნები ყველა უნდა დაწვა კაცმა

მაგაში არაა საქმე სინამდვილეში. super–ს აქვს 2–მაგი დანიშნულება:

1. მშობელი კლასის წევრებზე წვდომა. აქ private–სთან წვდომა შეუძლებელია იმ მარტივი მიზეზის გამო რომ private მოდიფიკატორია ბოროტი და შვილებს კანფეტს უმალავს. კანფეტს კი არა, კლასის წევრებს

2. როდესაც შვილი კლასის ობიექტი იქმნება, მისი კონსტრუქტორიდან (რომელიც ცხადად შეიძლება არ არსებობდეს მაგრამ არაცხადად ყოველთვის არსებობს) აუცილებლად იძახება მშობელი კლასის კონსტრუქტორი. არაცხადად. ანუ არსად წერია რომ აბა მშობელი კლასის კონსტრუქტორი გამოიძახეო მაგრამ იძახება თავისით. ჰოდა თუ მშობელ კლასს ბევრი კონსტრუქტორი აქვს, super–ით შეგვიძლია განვსაზღვროთ, რომელი მათგანი გამოიძახოს.

ახლა რა შუაშია #2–თან private წევრები? იმ შუაშია რომ მთელი ამ "ვალაკიტის" დანიშნულება მომდინარეობს მშობელი კლასის private ველებისთვის საწყისი მნიშვნელობების მინიჭების აუცილებლობიდან – ამაზე სასიცოცხლოდ შეიძლება იყოს დამოკიდებული მშობელი კლასიდან მემკვიდრეობით მიღებული მეთოდების კორექტულად მუშაობა. რადგანაც შვილი კლასი ზოგადად ვერ ხედავს მშობლის private ველებს, ამიტომ მისი კონსტრუქტორი ამ ველების ინიციალიზაციას (საწყისი მნიშვნელობების მინიჭებას) ვერ მოახდენს. ჰოდა იმის მაგივრად რომ აკრძალული მეთოდებით მიიღოს private ველებზე წვდომა, უბრალოდ ისეთ რამეს იძახებს, რაც მის მაგივრად მოახდენს ინიციალიზაციას. ანუ მშობელი კლასის კონსტრუქტორს.

რაც შეეხება private ველებზე წვდომას, მაგის საშუალება არსებობს Java Reflection API–თი, მაგრამ ეგ ნაადრევია ამ ეტაპზე

_________________
Waiting for the revolution...

chqareuli

გამარჯობათ. პროგრამას ვწერ jsp-ზე, სერვერად მაქვს დაყენებული Jboss და apache-ant-ი, და შემდეგ ვქმნი war-ფაილებს რომელიც არის jsp-ი ფაილების კრებული, ამ war-ს უშვებ ბრაუზერით და ჩვეულებრივ მუშაობს.

აუცილებელია თუ არა ear- ფაილების არსებობაც???

და მაინტერესებს სწორი მიმართულებით მივდივარ თუ არააა (პროგრამას დაახლოებით მინიმუმ 10000-ი მომხმერებელი ეყოლება ყოველ დღე )???

jordano

ear კარგია თუკი პროგრამა შედგება ბევრი ნაწილისაგან. მე ძირითადად ear–ებს ვაკეთებ რადგანაც მაქვს არამარტო war–ები, არამედ EJB მოდულები ცალკე jar–ებში და დამხმარე jar–ების ნაწილი საერთოა ყველა მოდულისთვის.

თუკი მარტო ვებ–აპლიკაციას წერ და მეტს არაფერს, war სრულიად საკმარისია.

ისე, "შიშველ" JSP–ზე წერა ვერაა კარგი გადაწყვეტა. მაგას ჯობია გამოიყენო JSP Model 2. აქ კარგადაა ახსნილი: http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html

კიდევ უკეთესი ვარიანტებიც არის მაგრამ რახან JSP–ზე წერ, მიგრაცია Model 2–ზე უფრო უმტკივნეულო იქნება.
_________________
Waiting for the revolution...

Alecoder

jordano
მეც ეგ არ ვთქვი კაცო ?

უბრალოდ, პირდაპირი გაგებით წვდომა არ აქვს რა თქმა უნდა. წვდომა აქვს ისევე მთავარი კლასის კონსტრუქტორის მეშვეობით რომელსაც აწვდის პარამეტრებს და მთავარ კლასსში განსაზღვრული კონსტრუქტორი ახდესნ ამ ცვლადების ინიციალიზაციას.

ანუ ცალსახად მაინც გამოდის რომ წვდომა აქვს პრივატ რიპის ელემენტებთან თუმცა არა პირდაპირი გაგებით.

რაც შეეხება 2.0 ვერსიას, ავად თუ კარგად მაქვს და უნდა წავიკითხო ბოლომდე. ხოლო შემდეგ იდეაში მაქვს რომ, ვიყიდო ინგლისურენოვანი წიგნი ჯავას უახლესი ვერსიის და ნუ იმით შესაბამისად განვამტკიცებ ცოდნასაც და აღმოვფხვრი ძველებურ მიდგომებს.

chqareuli

jordano

საერთოდ, ითვლება რომ Java–ზე ვებ–ინტერფეისის ასაწყობად უნდა გამოიყენო JSF (Java Server Faces).

მას აქვს უპირატესობებიც და ნაკლოვანებებიც. ძირითადი ნაკლოვანება ისაა რომ ინტერფეისის ნაწილი იწერება JSP–ზე, არა HTML–ტეგებით არამედ რაღაც მიმსგავსებულით. რაც ნიშნავს რომ რიგით ვებ–დიზაინერს, რომელმაც კარგად იცის HTML, კეფაზე იღუნავს CSS–ს და ა.შ. პრაქტიკულად ვერ გამოიყენებ. <f:commandButton> –ს რომ დაინახავს, ინსულტი დაემართება უეჭველად

არსებობს Tapestry, http://tapestry.apache.org/ რომლის მთელი იდეა ის იყო თავიდანვე რომ ვებ–დიზაინერი აკეთებდა HTML–ს და ამას ისე აბამდი შენს ჯავა–აპლიკაციას რომ მის ნახელავს არ ეხებოდი. თუმცა ამ საწყისი იდეიდან ბევრმა წყალმა ჩაიარა და ახლა ესეც JSF_ის მსგავს რამეს ჩალიჩობს ხოლმე ალაგ–ალაგ.

არსებობს ძველი, ბებერი, კბილებჩაფცქვნილი Struts, http://struts.apache.org რომელიც უხსოვარი დროიდან არსებობს და ჯერაც არ მოკვდა მე მგონი

რავი, ათასი რამე არსებობს. ყველაზე "ალესილი" ალბათ მაინც JSF–ია იმის გამო რომ Sun, Oracle და მსგავსი როჟები ყველანაირად ქაჩავდნენ.
_________________
Waiting for the revolution...