Patarkit dėl OOP PHP

Šiuo metu reikia padaryti SQL užklausų išvedimą lentelėse, tų lentelių bus ~9 kai kurios su ta pačia užklausa kai kurios su kita, skirsis išvedami laukai ir tam tikri kiti parametrai. Manau reikia tai daryti panaudojus OOP galimybes tik nelabai įsivaizduoju kaip pritaikyti.

Dabar kas galvoje tai tik paprastas lentelių išvedimas su if sąlygomis kas aišku atrodo pakankami atsilikusiai kode, jau nekalbant jei man reikės paskui ką nors keisti kokioje nors rezultatų lentelėje.

Norisi kažkaip sukurti lentelę kaip abstraktų objektą su skirtingais parametrais priklausomai nuo to kur ji bus paišoma.

PVZ.: yra užklausa kuri grąžina 12 field'ų iš kurių tam puslapyje kur ją paišau reikia tik 5, kitame puslapyje ta pati užklausa, bet man jau reikia 8 fieldų ir t.t.

Nežinau ar supratot, bet gal kam teke susidurti su panašia užduotimi ir patarsit bent įdėjomis kaip optimaliausiai realizuoti tikį dalyką.

Arba šitas:

https://github.com/j4mie/idiorm

Labaiu norėtusi kažkokio algoritmo žodžiais pasakyto nei nuorodų į bibliotekas :) Naudojama ne interbase mano šitam konkrečiai reikalui kurį jau ne visi net palaiko.

vistiek juk reikes apibresti isvedamus laukus, kurt atskira funkcija arba per parametrus, arba selectint visus laukus su viena funkcija.

Nežinau ar supratot, bet gal kam teke susidurti su panašia užduotimi ir patarsit bent įdėjomis kaip optimaliausiai realizuoti tikį dalyką.

Nu aš ir nežinau ar supratau ko nori.. Bet kodėl tau toks variantas netinka?

// tarkim turi sql klasę.
public function get_data ( $tavo_uzklausa )
{

//čia atlieki visus veiksmus, kad gautum savo duomenis iš lentelės ir juos gražini kaip masyvą

return $rezultatas_masyve;

}

// O kai reikia panaudoti
$data = $sql -> get_data ( $tavo_uzklausa );

echo $data [ 'row_name' ];
echo $data [ 'row_name2' ];
echo $data [ 'row_name3' ];
echo $data [ 'row_name_ir_t_t' ]

Visgi atskiruose puslapiuose turėsi atlikti užklausą iš naujo nebent kešuosi užklausas.

Naudok Doctrine2 ORM ir nebus problemų su atvaizdavimu, nes tai bus itin paprasta :)

Nu aš ir nežinau ar supratau ko nori.. Bet kodėl tau toks variantas netinka?

 

 

// tarkim turi sql klasę.
public function get_data ( $tavo_uzklausa )
{

//čia atlieki visus veiksmus, kad gautum savo duomenis iš lentelės ir juos gražini kaip masyvą

return $rezultatas_masyve;

}

// O kai reikia panaudoti
$data = $sql -> get_data ( $tavo_uzklausa );

echo $data [ 'row_name' ];
echo $data [ 'row_name2' ];
echo $data [ 'row_name3' ];
echo $data [ 'row_name_ir_t_t' ]

Visgi atskiruose puslapiuose turėsi atlikti užklausą iš naujo nebent kešuosi užklausas.

o jeigu prireikia kazko tokio, t.y. ilgos uzklausos, tik tersi svarbia vieta be reikalo, tam ir skirtos funkcijos kad gautum reiksme, nesvarbu kiek vietos joje uzimtum ir kokius veiksmus joje atliktum... o iskur ta funkcija iskvieti turi but svaru.

$data = $sql -> get_data ( "SELECT DISTINCT(wp_posts.ID),wp_posts.post_title,wp_posts.guid,
	 wm2.meta_value as img_link, 
	 CONCAT(wpo_su.option_value, 
REPLACE( REPLACE( REPLACE( REPLACE(wpo.option_value,'%year%',date_format(wp_posts.post_date,'%Y')) ,
'%monthnum%',date_format(wp_posts.post_date,'%m')) 
,'%day%',date_format(wp_posts.post_date,'%d')) 
,'%postname%',wp_posts.post_name ) ) as permalink  
	from wp_posts 
	LEFT JOIN 
       wp_postmeta wm1
       ON (
           wm1.post_id = wp_posts.id 
           AND wm1.meta_value IS NOT NULL
           AND wm1.meta_key = '_thumbnail_id'              
       )
   LEFT JOIN 
       wp_postmeta wm2
       ON (
           wm1.meta_value = wm2.post_id
           AND wm2.meta_key = '_wp_attached_file'
           AND wm2.meta_value IS NOT NULL  
       )
	INNER JOIN wp_options wpo on wpo.option_name='permalink_structure' 
	INNER JOIN wp_options wpo_su on wpo_su.option_name='siteurl' 
			  LEFT JOIN wp_term_relationships
			  ON wp_posts.ID = wp_term_relationships.object_id
	LEFT JOIN wp_term_taxonomy
			  ON wp_term_taxonomy.term_taxonomy_id = wp_term_relationships.term_taxonomy_id	  
			  WHERE wp_term_relationships.term_taxonomy_id != '318' and  wp_term_relationships.term_taxonomy_id != '319' and wp_term_relationships.term_taxonomy_id != '81' and wp_term_relationships.term_taxonomy_id != '146' and  wp_posts.post_type = 'post' and
					wp_posts.post_status = 'publish' and wp_term_taxonomy.taxonomy = 'category' and wp_term_taxonomy.parent != '72'
			  ORDER BY wp_posts.post_date desc 
			  LIMIT 5" );

Naudok Doctrine2 ORM ir nebus problemų su atvaizdavimu, nes tai bus itin paprasta :)

Visiškai palaikau tavo nuomonę :rolleyes:

o jeigu prireikia kazko tokio, t.y. ilgos uzklausos, tik tersi svarbia vieta be reikalo, tam ir skirtos funkcijos kad gautum reiksme, nesvarbu kiek vietos joje uzimtum ir kokius veiksmus joje atliktum... o iskur ta funkcija iskvieti turi but svaru.

Gal gali paaiškinti, ką tu turi omeny? Nes nelabai supratau apie kokia tu vietą ir švarą kalbi.

Gal gali paaiškinti, ką tu turi omeny? Nes nelabai supratau apie kokia tu vietą ir švarą kalbi.

apie tokia:

<?php $posts = get_posts(); ?>
<?php foreach($posts as $key=>$item): ?>
 // some html
 <?php $images = get_images($item->id); ?>
 <?php foreach($images as $image): ?>
      // some html
 <?php endoforeach; ?> 
<?php endoforeach; ?>

grazu? o cia?

<?php $posts = get_data ( "SELECT DISTINCT(wp_posts.ID),wp_posts.post_title,wp_posts.guid,
                wm2.meta_value as img_link, 
                CONCAT(wpo_su.option_value, 
REPLACE( REPLACE( REPLACE( REPLACE(wpo.option_value,'%year%',date_format(wp_posts.post_date,'%Y')) ,
'%monthnum%',date_format(wp_posts.post_date,'%m')) 
,'%day%',date_format(wp_posts.post_date,'%d')) 
,'%postname%',wp_posts.post_name ) ) as permalink  
               from wp_posts 
               LEFT JOIN 
       wp_postmeta wm1
       ON (
           wm1.post_id = wp_posts.id 
           AND wm1.meta_value IS NOT NULL
           AND wm1.meta_key = '_thumbnail_id'              
       )
  ........" ); ?>
<?php foreach($posts as $key=>$item): ?>
 // some html
 <?php $images = get_data ( "SELECT DISTINCT(wp_posts.ID),wp_posts.post_title,wp_posts.guid,
                wm2.meta_value as img_link, 
                CONCAT(wpo_su.option_value, 
REPLACE( REPLACE( REPLACE( REPLACE(wpo.option_value,'%year%',date_format(wp_posts.post_date,'%Y')) ,
'%monthnum%',date_format(wp_posts.post_date,'%m')) 
,'%day%',date_format(wp_posts.post_date,'%d')) 
,'%postname%',wp_posts.post_name ) ) as permalink  
               from wp_posts 
               LEFT JOIN 
       wp_postmeta wm1
       ON (
           wm1.post_id = wp_posts.id 
           AND wm1.meta_value IS NOT NULL
           AND wm1.meta_key = '_thumbnail_id'              
       )..."); ?>
 <?php foreach($images as $image): ?>
      // some html
 <?php endoforeach; ?> 
<?php endoforeach; ?>

gal ir niekad nebus tokio ilgio uzklausos, bet as tikrai nesiusciau funkcijai per parametrus pacios uzklausos

apie tokia:

 

<?php $posts = get_posts(); ?>
<?php foreach($posts as $key=>$item): ?>
 // some html
 <?php $images = get_images($item->id); ?>
 <?php foreach($images as $image): ?>
  	// some html
 <?php endoforeach; ?> 
<?php endoforeach; ?>

grazu? o cia?

Tai žinoma, kad gražiau. Bet realiai tu parašei tą patį ką ir aš. Aš tik daviau pačio principo elementarų pavizdį.Tavo variante, visos užklausos pačiose funkcijose. Bet tokiu atveju turėsi kurti daug funkcijų ar nuorodų į jas: get_posts(), get_images, get_nicks, get_forums ir t.t. O jei reikės nustatyti papildomą parametrą?5?10? O jei Tavo duotoje užklausoje reikės pakeisti kelias field'ų reikšmes ir dar pusę pačios užklausos? Reikės didelę funkcija pasidaryti, kad suformuluotų normaliai užklausą iš daug įvairių parametrų, kas nėra praktiška (bent jau man taip atrodo) arba kurti begales funkcijų įvairiems variantams. Kai mano duotam variante užtenka tik pačią užklausą pakeisti ir viskas.

o jeigu prireikia kazko tokio, t.y. ilgos uzklausos, tik tersi svarbia vieta be reikalo, tam ir skirtos funkcijos kad gautum reiksme, nesvarbu kiek vietos joje uzimtum ir kokius veiksmus joje atliktum... o iskur ta funkcija iskvieti turi but svaru.

Taip man ir neatsakei, kodėl teršiu svarbią vietą ir kodėl turi būti švaru?

Nu aš ir nežinau ar supratau ko nori.. Bet kodėl tau toks variantas netinka?

 

 

// tarkim turi sql klasę.
public function get_data ( $tavo_uzklausa )
{

//čia atlieki visus veiksmus, kad gautum savo duomenis iš lentelės ir juos gražini kaip masyvą

return $rezultatas_masyve;

}

// O kai reikia panaudoti
$data = $sql -> get_data ( $tavo_uzklausa );

echo $data [ 'row_name' ];
echo $data [ 'row_name2' ];
echo $data [ 'row_name3' ];
echo $data [ 'row_name_ir_t_t' ]

Visgi atskiruose puslapiuose turėsi atlikti užklausą iš naujo nebent kešuosi užklausas.

O ar įmanoma kažkaip padaryti lentelės išvedimą be tų visų echo? Tarkim tarkim sukuriant kažkokį objektą su parametrais, parametrai galėtu būti kokių fieldus turėtu išvesti?

o jeigu prireikia kazko tokio, t.y. ilgos uzklausos, tik tersi svarbia vieta be reikalo, tam ir skirtos funkcijos kad gautum reiksme, nesvarbu kiek vietos joje uzimtum ir kokius veiksmus joje atliktum... o iskur ta funkcija iskvieti turi but svaru.

$data = $sql -> get_data ( "SELECT DISTINCT(wp_posts.ID),wp_posts.post_title,wp_posts.guid,
	 wm2.meta_value as img_link, 
	 CONCAT(wpo_su.option_value, 
REPLACE( REPLACE( REPLACE( REPLACE(wpo.option_value,'%year%',date_format(wp_posts.post_date,'%Y')) ,
'%monthnum%',date_format(wp_posts.post_date,'%m')) 
,'%day%',date_format(wp_posts.post_date,'%d')) 
,'%postname%',wp_posts.post_name ) ) as permalink  
	from wp_posts 
	LEFT JOIN 
       wp_postmeta wm1
       ON (
           wm1.post_id = wp_posts.id 
           AND wm1.meta_value IS NOT NULL
           AND wm1.meta_key = '_thumbnail_id'              
       )
   LEFT JOIN 
       wp_postmeta wm2
       ON (
           wm1.meta_value = wm2.post_id
           AND wm2.meta_key = '_wp_attached_file'
           AND wm2.meta_value IS NOT NULL  
       )
	INNER JOIN wp_options wpo on wpo.option_name='permalink_structure' 
	INNER JOIN wp_options wpo_su on wpo_su.option_name='siteurl' 
			  LEFT JOIN wp_term_relationships
			  ON wp_posts.ID = wp_term_relationships.object_id
	LEFT JOIN wp_term_taxonomy
			  ON wp_term_taxonomy.term_taxonomy_id = wp_term_relationships.term_taxonomy_id	  
			  WHERE wp_term_relationships.term_taxonomy_id != '318' and  wp_term_relationships.term_taxonomy_id != '319' and wp_term_relationships.term_taxonomy_id != '81' and wp_term_relationships.term_taxonomy_id != '146' and  wp_posts.post_type = 'post' and
					wp_posts.post_status = 'publish' and wp_term_taxonomy.taxonomy = 'category' and wp_term_taxonomy.parent != '72'
			  ORDER BY wp_posts.post_date desc 
			  LIMIT 5" );

Jeigu prireikia tokiu sql - reiskia chujova pas tave logika.

Dar perfrazuosiu klausymą paskutinį:

Kaip daug maž galima būtu sukurti klasę pvz Lentelė kuri turėtu 1 standartinį metodą (išvedimą visų fieldų kaip yra iš SQL) ir kitus metodus kurie perrašytu/papildytu tą pirmąjį, o vėliau jau galima būtu išsikviesti atitinkamą metodą priklausomai nuo to kurio mums reikės.

Ar čia visai ne į temą? Nelabai dar pagaunu kaip efektyviai naudoti OOP.

Dar perfrazuosiu klausymą paskutinį:

 

Kaip daug maž galima būtu sukurti klasę pvz Lentelė kuri turėtu 1 standartinį metodą (išvedimą visų fieldų kaip yra iš SQL) ir kitus metodus kurie perrašytu/papildytu tą pirmąjį, o vėliau jau galima būtu išsikviesti atitinkamą metodą priklausomai nuo to kurio mums reikės.

 

Ar čia visai ne į temą? Nelabai dar pagaunu kaip efektyviai naudoti OOP.

http://en.wikipedia.org/wiki/Object-relational_mapping

http://stackoverflow.com/questions/3438198/which-orm-for-codeigniter

Tai žinoma, kad gražiau. Bet realiai tu parašei tą patį ką ir aš. Aš tik daviau pačio principo elementarų pavizdį.Tavo variante, visos užklausos pačiose funkcijose. Bet tokiu atveju turėsi kurti daug funkcijų ar nuorodų į jas: get_posts(), get_images, get_nicks, get_forums ir t.t. O jei reikės nustatyti papildomą parametrą?5?10? O jei Tavo duotoje užklausoje reikės pakeisti kelias field'ų reikšmes ir dar pusę pačios užklausos? Reikės didelę funkcija pasidaryti, kad suformuluotų normaliai užklausą iš daug įvairių parametrų, kas nėra praktiška (bent jau man taip atrodo) arba kurti begales funkcijų įvairiems variantams. Kai mano duotam variante užtenka tik pačią užklausą pakeisti ir viskas.

 

Taip man ir neatsakei, kodėl teršiu svarbią vietą ir kodėl turi būti švaru?

Zinoma tersi vieta jeigu nesupratai as katik tau daviau kodo pavyzdziu, jug gali get_posts perduoti masyva su parametrais, ir padaryti kiek imanoma protingesne funkcija...o jei sukuri koki nauja lauka, ar prireikia kito laiko tai paredaguoji funkcija ir dasiduri ko reikia. Beje o kaip tu igyvendintum tokius duomenu atrinkimus? gal yra ir geresniu sprendimu, pasidalink. Beje i toki uzklausu builderi nekreipk demesio cia CI navarotas, galima su pure sql lygiai ta pati daryt :D

	function get_events($filters,$featured = null)
{
	$this->db->select('events.id,events.name,events.start_time,events.end_time,events.url,attend.attend_count,places.name as place_name,city.url as city_url,event_type.url as event_type_url,
	( 6371 * acos( cos( radians(places.latitude) ) * cos( radians( city.latitude ) ) * cos( radians( city.longitude ) - radians(places.longitude) ) + sin( radians(places.latitude) ) * sin( radians( city.latitude ) ) ) ) as distance
	');
	$this->db->from('events');
	$this->db->order_by("start_time", "asc"); 

	if(!empty($featured))
		$this->db->where('events.featured',$featured);
	else
		$this->db->where('events.featured',0);
	$this->db->where('events.is_published',1);

	if(isset($filters['radius']))
		$this->db->having('distance <',$filters['radius']);


	if(isset($filters['event_type']))
		$this->db->where('event_type.url',$filters['event_type']);

	if(isset($filters['city']))
		$this->db->where('city.url',$filters['city']);

	if(isset($filters['date']))
		$this->db->like('start_time',$filters['date']);
	else
		$this->db->where('end_time >',date('Y-m-d H:i:s'));	

	$this->db->join('attend', 'attend.event_id = events.id', 'left');
	$this->db->join('places', 'places.id = events.place_id', 'left');
	$this->db->join('city', 'city.id = places.city_id', 'left');
	$this->db->join('event_type', 'event_type.id = events.type_id', 'left');

	if($featured == 1)
		$this->db->limit(10);	
	elseif($featured == 0){
		if($this->input->get('page')){
			$current_page = intval($this->input->get('page'));
			$this->db->limit($this->pagination->per_page,$this->pagination->per_page*($current_page-1));
		}
		else $this->db->limit($this->pagination->per_page,0);
	}


	$query = $this->db->get();
	$data = array();
	foreach ($query->result() as $row)
	{
		$row->image = $this->get_image($row->id);

	   $data[] = $row;
	}
	return $data;

}

Jeigu prireikia tokiu sql - reiskia chujova pas tave logika.

Keista kad neteko formuot tokiu sql, siaip gali but belekiek ilgesnis :)

Man atrodo, kad čia gausis dar sudėtingiau ir neaiškiau su šitom visom mandrybėm nei klasikiniai selectai su lentelėmis. Ir niek čia nebus lengviau poto kažką dadėt ar atimt.

Keista kad neteko formuot tokiu sql, siaip gali but belekiek ilgesnis :)

Teko formuoti ir ne tokius pora kartu, bet esme tame, jog cia jau spaghetti kodas gaunasi.

Man atrodo, kad čia gausis dar sudėtingiau ir neaiškiau su šitom visom mandrybėm nei klasikiniai selectai su lentelėmis. Ir niek čia nebus lengviau poto kažką dadėt ar atimt.

Cia kur kas gilesnis dalikas yra vadinamas http://en.wikipedia.org/wiki/Design_Patterns Yra keletas smulkmenu, bet siaip viskas graziai yra aprasyta ir man net noro prisi***** nera.

 

 

Man atrodo, kad čia gausis dar sudėtingiau ir neaiškiau su šitom visom mandrybėm nei klasikiniai selectai su lentelėmis. Ir niek čia nebus lengviau poto kažką dadėt ar atimt.

Mandrybėm? Tai tik paprastas query builderis :)

Tau atrodo kad rašyti sql užklausas yra racionalu? Pasikartosiu, jei į lenteles žiūrėsi kaip į objektus, vertėtų pasidomėti doctrine2, kuri tau leis manipuoliuoti entity'čiais kaip tik tau norisi ir sql užklausas teks naudoti itin retai

$repository = $this->getDoctrine()
   ->getRepository('AcmeStoreBundle:Product');

// query for one product matching be name and price
$product = $repository->findOneBy(array('name' => 'foo', 'price' => 19.99));

// query for all products matching the name, ordered by price
$products = $repository->findBy(
   array('name' => 'foo'),
   array('price' => 'ASC')
);

tai keleto užklausų pavyzdys :)

Na bet kiek jau spėjau suprasti, OOP dar nėra tarp tavo sugebėjimų, tad gal vertėtų pradėti nuo to :)

Mandrybėm? Tai tik paprastas query builderis :)

 

Tau atrodo kad rašyti sql užklausas yra racionalu? Pasikartosiu, jei į lenteles žiūrėsi kaip į objektus, vertėtų pasidomėti doctrine2, kuri tau leis manipuoliuoti entity'čiais kaip tik tau norisi ir sql užklausas teks naudoti itin retai

 

 

$repository = $this->getDoctrine()
   ->getRepository('AcmeStoreBundle:Product');

// query for one product matching be name and price
$product = $repository->findOneBy(array('name' => 'foo', 'price' => 19.99));

// query for all products matching the name, ordered by price
$products = $repository->findBy(
   array('name' => 'foo'),
   array('price' => 'ASC')
);

 

tai keleto užklausų pavyzdys :)

 

Na bet kiek jau spėjau suprasti, OOP dar nėra tarp tavo sugebėjimų, tad gal vertėtų pradėti nuo to :)

Na nebutinai i doctrine, jug net tik php turi tai, bet ir kiti, tad i ORM aplamai.

Na nebutinai i doctrine, jug net tik php turi tai, bet ir kiti, tad i ORM aplamai.

Tiesa. Pastaruoju metu tenka padirbėt daug su doctrine, tad ją ir rekomenduoju. Tačiau visos jos panašios :)

Visgi temos autorius, turėtų visų pirma išsiaiškinti kas yra Persistence Layer, kad galėtų naudotis bet kuriuo ORM, nes antraip tai netenka prasmės. :)

Tiesa. Pastaruoju metu tenka padirbėt daug su doctrine, tad ją ir rekomenduoju. Tačiau visos jos panašios :)

 

 

Visgi temos autorius, turėtų visų pirma išsiaiškinti kas yra Persistence Layer, kad galėtų naudotis bet kuriuo ORM, nes antraip tai netenka prasmės. :)

Nesimokins jis nieko)))

Mandrybėm? Tai tik paprastas query builderis :)

 

Tau atrodo kad rašyti sql užklausas yra racionalu? Pasikartosiu, jei į lenteles žiūrėsi kaip į objektus, vertėtų pasidomėti doctrine2, kuri tau leis manipuoliuoti entity'čiais kaip tik tau norisi ir sql užklausas teks naudoti itin retai

 

 

$repository = $this->getDoctrine()
   ->getRepository('AcmeStoreBundle:Product');

// query for one product matching be name and price
$product = $repository->findOneBy(array('name' => 'foo', 'price' => 19.99));

// query for all products matching the name, ordered by price
$products = $repository->findBy(
   array('name' => 'foo'),
   array('price' => 'ASC')
);

 

tai keleto užklausų pavyzdys :)

 

Na bet kiek jau spėjau suprasti, OOP dar nėra tarp tavo sugebėjimų, tad gal vertėtų pradėti nuo to :)

O jei prireiks panaudoti subselectus, join'us, datos formavimo funkcijas ir t.t ?

Niekad OOP tokiose situacijose nenaudojau, tai ir pačiam ydomu daros :)

Mandrybėm? Tai tik paprastas query builderis :)

 

Tau atrodo kad rašyti sql užklausas yra racionalu? Pasikartosiu, jei į lenteles žiūrėsi kaip į objektus, vertėtų pasidomėti doctrine2, kuri tau leis manipuoliuoti entity'čiais kaip tik tau norisi ir sql užklausas teks naudoti itin retai

 

 

$repository = $this->getDoctrine()
   ->getRepository('AcmeStoreBundle:Product');

// query for one product matching be name and price
$product = $repository->findOneBy(array('name' => 'foo', 'price' => 19.99));

// query for all products matching the name, ordered by price
$products = $repository->findBy(
   array('name' => 'foo'),
   array('price' => 'ASC')
);

 

tai keleto užklausų pavyzdys :)

 

Na bet kiek jau spėjau suprasti, OOP dar nėra tarp tavo sugebėjimų, tad gal vertėtų pradėti nuo to :)

Na taip nėra, dar tik pradedu ir manau kaip ir visiems kurie pradeda ar pradėdavo kažkada kyla klausimas kuom OOP skiriasi nuo funkcijų. Aš tiesiog negaliu dar sugalvoti kaip man tą OOp pritaikyti, kad jis būtu efektyvus, ne taip kad sukurti kažkokią klasę, o paskui ją vieną kartą ar 2 panaudoti, čia jau niekuom tada nesiskiria nuo paprasčiausios funkcijos, šito supratimo man dar trūksta, pradėsiu ryt skaityti Мэтт Зандстра - PHP. Объекты, шаблоны и методики программирования gal praregėsiu.

O kas liečia visas išvadintas pagalbines priemones tai manau reikia nuo jų pradėti kai įsisavinsiu kas tas OOP iš esmės yra.