[openeda:2004] - Jedno moje razmišljanje... by Toplica Tanaskovic <toptan@kde.org.yu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


	... vezano za tim 1, 2 i SVG.

	Mislim da je SVG suvišan iz dva razloga:
1. Moralo bi da se radi parsiranje pa onda instanciranje primitiva
2. Može da bude jako sporo ako je element komplikovan.

	Da malo pojasnim:
	Cilj nam je da imamo što manje režijskog posla, stoga mislim da bi
najbolje bilo kad dobijemo komponentu od tima 2 samo dodajemo, brišemo i 
menjamo primitive. Ovo za sobom povlači da komponenta mora da ima listu
primitiva koje bi trebalo instancirati pre predavanja timu 1. Postavlja se
pitanje ko to treba da radi:

	Ako radi tim 3:

	Onda tim 3 ima compile-time zavisnost prema definiciji klase grafičke 
primitive komponente, recimo EDAComponentPrimitive, što nije dobro jer će
tim 1 često to da menja dok ne dođe do optimalnog rešenja. Ovo je jako loše
i remeti nam celu organizaciju pošto timovi 1 i 3 ne bi trebalo nigde da 
se sretnu.

	Ako radi tim 2:
	Onda ćemo morati da imamo klasu koja će sadržati potrebne podatke za
instanciranje primerka klase grafičke primitive komponente. Kad nam tim 2
napravi instancu i prosledi je timu 1, pa ovaj nešto izmeni, tim dva će 
imati problem „vađenja“ sirovih podataka koje mora da da timu 3 da bi ovaj
to snimio negde, a pride i to što bi tim 2, ili imao compile-time zavisnost
prema timu 1, što ne sme da se desi, ili bi pak morao da definiše GUI klasu
što takođe ne sme da se desi pošto core ne sme da ima nikakve veze sa GUI-jem


Rešenje problema:

	Predložio bih tzv. čvrsto spregnuto (tight-coupled) rešenje. 
Postoje dve klase grafička i negrafička koja sadrži samo atribute primitive.
Nazovimo ih EDAComponentPrimitive i EDAComponentPrimitiveData.
Primer njihovih definicija:

class EDAComponentPrimitiveData
{
public:
	//atributi
}

class EDAComponentPrimitive: public QCanvasItem
{
public:
	EDAComponentPrimitive(QCanvas *canvas, EDAComponentPrimitiveData* d):
		QCanvasItem(canvas), data(d)
			{
				// uradimo ako treba još nešto
			}

// šta nam još treba

protected:
	EDAComponentPrimitiveData* data;
}

	Na ovaj način 	imamo direktnu vezu između grafičke i negrafičke
primitive. Sve što GUI izmeni u atributima grafičke primitive, to bi
trebala primitiva sama ili GUI sa strane da odraze u strukturi *data.
Kako smo koristili pokazivače izmene će momentalno bez ikakve intervencije
biti dostupe u listi koju drži biblioteka tima 2 tako da su podaci uvek
ažurni, i snimanje podataka je jednostavno. Instanciranje primerka
grafičke klase radi tim 1, a negrafičke tim 2.
	Grafičku klasu definiše tim 1, i niko drugi za nju ne zna, negrafičku
klasu definiše tim 2, a koriste je timovi 1 i 3. Ovo podrazumeva odvojeno
rukovanje grafičkim i negrafičkim atributima _komponente_ (ne primitive), 
što mislim da ne predstavlja problem, pošto su to po prirodi dve različite
stvari.
	Ovo takođe podrazumeva da se MORA mnogo voditi računa o bezbednosti 
signala. Vezu ka objašnjenu ovog problema i njegovom prevazilaženju sam 
dao u nekoj od prethodnih poruka.

	Mislim da je ovo elegantno rešenje koje će nam zadati najmanje i muka 
i posla.

	Očekujem vaša mišljenja. A ukoliko neko uoči neki propust neka obavezno
da i dobre primere da probamo da popravimo, a još bolje bi bilo da smisli
neko pametnije i bolje rešenje. Danima lupam glavu oko ovoga i ovo je 
najbolje što sam mogao da smislim.

	Nadam se da sam u izlaganju bio jasan i da nisam mnogo udavio :)
- -- 
Pozdrav,
Toplica
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAb4kXtKJqksC6c0sRAvNjAJ4tzJk9W6yWp4raD3cLpUJPmai7WgCfaazu
4hApMZg5XNW+ePrzcTZVVbA=
=1Ffd
-----END PGP SIGNATURE-----