Wprowadzenie
Aplikacja Obiekty deweloperskie pozwala na rejestrowanie i przeglądanie obiektów deweloperskich różnych typów. W niniejszym artykule opisany został obiekt o typie Namespace.
Opis
Namespace może być traktowany jako katalog w systemie plików lub jako pakiet w Javie. Namespace są zorganizowane hierarchicznie i służą do grupowania obiektów o powiązanej zawartości. Rezultatem jest struktura funkcjonalna, która pozwala uniknąć konfliktów nazewnictwa między obiektami deweloperskimi.
Każdy obiekt deweloperski jest przypisany do Namespace. Kombinacja nazwy obiektu deweloperskiego i typu obiektu deweloperskiego musi być unikalna w Namespace.
Struktura Namespace
Namespace są mapowane w strukturze drzewa. Korzeniem drzewa jest przestrzeń nazw com. Prefiks rozwoju jest przypisany do każdego systemu, w którym odbywa się rozwój. Poziom poniżej jest podzielony na te prefiksy. Rozwój odbywa się w przestrzeni nazw, która odpowiada prefiksowi rozwoju:
- com.cisag – rozwój standardowego rozwoju
- com.<prefiks rozwoju> – rozwój systemu przez partnera/klienta
Przestrzenie nazw znajdują się na kolejnym poziomie:
- .app – rozwój aplikacji standardowych partnerów i klientów
- .sys – rozwój systemu w standardowym rozwoju
- .pgm – interfejs między rozwojem systemu i aplikacji
- .dbu – przestrzeń nazw dla wygenerowanych obiektów deweloperskich. W tej przestrzeni nazw przechowywane są wersjonowane mapery i programy aktualizujące dla Business Objects, Extensions oraz Parts.
- .nls – przestrzeń nazw dla generowanych obiektów programistycznych do obsługi mechanizmu NLS.
W przestrzeniach nazw sys i pgm obiekty deweloperskie mogą być tworzone, zmieniane lub usuwane tylko przez standardowy rozwój. Obiekty deweloperskie w przestrzeniach nazw dbu i nls nie mogą być zmieniane, z wyjątkiem programów aktualizujących. Ponadto w tych przestrzeniach nazw nie można tworzyć żadnych obiektów deweloperskich.
Struktura przestrzeni nazw poniżej app, pgm i sys:
Namespace o specjalnym znaczeniu:
- obj: – w tej przestrzeni nazw można tworzyć tylko Business Objects, Parts, OQL-Views.
- ui: – interfejs użytkownika aplikacji
- gui: – komponenty wielokrotnego użytku dla interfejsu użytkownika (np.: EntityFields dla aplikacji)
- log: – logika aplikacji
Wszystkie obiekty deweloperskie namespace są zawarte w jej dzienniku rejestru.
Na zakładce Edytor dostępne są poniższe pola/parametry:
- Oznaczenie – opis techniczny namespace, ograniczony do 100 znaków.
- Odpowiedzialny – określa osobę odpowiedzialną za dany namespace. Akceptowani są tylko użytkownicy przypisani do systemu. Bieżący użytkownik jest wprowadzany podczas tworzenia nowego użytkownika.
- Testowa przestrzeń nazw – parametr odpowiadający za testowy namespace. Poniższe właściwości mają zastosowanie do testowych namespace:
- pełna nazwa musi zawierać „.test.”.
- testowe namespace mogą być tworzone i edytowane wyłącznie w zadaniu deweloperskim
- dla którego w polu Typ zadania wskazano wartość Test.
- obiekty deweloperskie w testowym namespace mogą być również tworzone i edytowane tylko w zadaniu deweloperskim dla którego w polu Typ zadania wskazano wartość Test.
- flagi nie można zresetować po pierwszej aktywacji.
- testowe namespace i zawarte w nich obiekty deweloperskie nie są przenoszone do innych systemów.
- zaznaczenie parametru Wewnętrzna przestrzeń nazw jest niedozwolone.
- Wewnętrzna przestrzeń nazw parametr ma zastosowanie do wewnętrznych przestrzeni nazw:
- mogą być tworzone i edytowane tylko w zadaniu deweloperskim o typie wewnętrzny.
- Obiekty deweloperskie w wewnętrznej przestrzeni nazw mogą być również tworzone i edytowane tylko w zadaniu deweloperskim o typie wewnętrzny.
- zaznaczenie parametru Testowa przestrzeń nazw jest niedozwolone.
- flagi nie można zresetować po aktywacji.
