@somekind Siema, pamiętam żę ostatnio mówiłeś że dobrze by było że jak jest włączony "smart paste" w edytorze, to żeby edytor wykrył czy masz w schowku link do obrazka czy zwykły, jak do obrazka to wkleja jako obrazek, a jak nie to jako link.
Tylko teraz pytanie:
Co jak mam link do obazka w schowku, ale on nie wygląda jak obrazek (nie ma rozszerzenia), ale tak czy tak chcę go wekleić jako obrazek?
Teraz nie mogę tego zrobić w żaden sposób.
Bum. Mały update.
W 4programmers można podkreślić coś używając <u></u>, teraz w edytorze również jest dekoracja do tego.
PS: Teraz działa taże <b> oraz <i> ;)
Kolejna wersja edytora postów, 1.3.11 (https://danon.github.io/4play.demo)
Refaktoruję akcje JS na komendy StateCommand z CodeMirror, przez co edytor będzie bardziej transaction-based..
Z takich zmian funkcyjnych, to np jest taka zmiana:
Kolejny update edytora, 1.3.12, https://danon.github.io/4play.demo
Podczas pisania testów formatera, zauważyłem że mam buga, mianowicie jak ktoś wklei link w którym jest [ albo (, to powstały w ten sposób markdown jest malformed. Dodałem fixa, że wklejajka umie zanekodować odpowiednie znaki:
[, ] to encode( lub ) to encode< lub > to encode, bo zostanie błędnie zinterpretowany jako tag HTML\ to encodeOkazało się że `` jest traktowane jako tekst, nie jako inline, więć podczas wklejania linku obok/przed/za/w tym czymś to coś się zamienia z paragraphu na kod, więc trzeba było to ohandlować. Poprawiłem przy okazji inne zachowanie, teraz wszędzie jest taka zasada:
event.preventDefault(). Jeśli jest chociaż cień szansy że akcja zepsuje markdown, to edytor po prostu nic nie robi (przeglądarka po prostu wkleja co ma wkleić). Innymi słowy "jeśli user coś zepsuje, to żeby było na usera a nie na edytor".Napisze jeszcze tylko testy skrótów klawiszowych i wrzucam na 4programmers.dev
Nowy adres demo: https://danon.github.io/4play.demo/
Nie wiem czy jest sens wyłączanie stylowania dla znacznika <kbd>, bo podany skrót jest interpretowany jako błędny:
<kbd>Ctrl++</kbd> dwa separatory
jest prawidłowym, skrótem do np. powiększania treści na stronie w chrome.
Czy choćby jak zadam pytanie: jak napisać ç na klawiaturze bez tego znaku?
To skrót będzie taki Ctrl+,,c, czy wg instrukcji z MS: CTRL+, (PRZECINEK), c obie nie ostylujesz w edytorze. Wolę działanie deterministyczne, czyli niech <kbd> zawsze się styluje, a poprawność zostawmy autorowi.
Update:
Teraz sprawdziłem, że mozna ro zapisać tak Ctrl+Comma,c, przy okazji sprawdzania zdziwiłem się że jest czuły na wielkość znaków, to też moim zdaniem nie powinno mieć miejsca.
Panczo napisał(a):
przy okazji sprawdzania zdziwiłem się że jest czuły na wielkość znaków, to też moim zdaniem nie powinno mieć miejsca.
Tak, to jest by design.
Zamysłem było to, że jeśli ktoś chce pokazać jakiś skrót, to żeby to było spójne w ramach całego forum. Np żeby skrót Ctrl oraz przeicnek to wszędzie było Ctrl+Comma, a nie np raz Ctrl+,, Ctrl+Comma,Ctrl+Przecinek, albo nawet Ctrl, albo Ctrl + ,.
Np nie chciałbym żeby ktoś wpisał Ctlr+Enter (Ctlr to jest literówka, powinno być Ctrl), więc takiego czegoś nie koloruję, żeby dać znać autorowi od razu, że to co wpisał jest nie ok.
Nie upieram się, ale jedno pytanie: czy zmieniając edytor zmieni się też kod wyświetlający post? Bo teraz
<kbd>ctlr</kbd>, <kbd>Cltr</kbd>,<kbd>CTLR</kbd>
Będzie wyróżnione: ctlr, Cltr,CTLR
Panczo napisał(a):
Nie upieram się, ale jedno pytanie: czy zmieniając edytor zmieni się też kod wyświetlający post? Bo teraz
<kbd>ctlr</kbd>, <kbd>Cltr</kbd>,<kbd>CTLR</kbd>Będzie wyróżnione: ctlr, Cltr,CTLR
Nie, wyświetlający post pozostanie całkowicie bez zmian.
No właśnie, więc sam widzisz niejednoznaczność.
Nie, wyświetlający post pozostanie całkowicie bez zmian.
No to tym bardziej nie rozumiem tych sprawdzeń w stylowaniu kbd
Panczo napisał(a):
Nie, wyświetlający post pozostanie całkowicie bez zmian.
No to tym bardziej nie rozumiem tych sprawdzeń w stylowaniu
kbd
No idea jest taka żeby ludzie starali się pisać konsekwentniej skróty klawiszowe.
Jeśli ktoś się uprze wpisać <kbd>Crlt</kbd>, to niech wpisze.
Okej jest dupa.
Coyote ma kilka integracji ze swoim edytorem których na razie nie można dodać do 4play, więc muszę wprowadzić jeszcze kilka poprawek do edytora. Dopiero potem dodamy integrację z coyote.
Wypuszczona wersja 1.4.0 edytora: https://danon.github.io/4play.demo/
<sub> oraz <sup>
Esc emituje event onCancel, by móc cancelować treść.onSubmit, by móc wysłać formularz skrótem klawiszowym.Wypuszczona wersja 1.4.1 edytora: https://danon.github.io/4play.demo/
Bugiem było to że po zaznaczeniu treści z Ctrl+A, z jakiegoś powodu Ctrl+V wklejało treść, ale nie usuwało zaznaczenia, co dawało wrażenie braku akcji.
Bug na 99% wystąpi też na Macu, trzeba przetestować. Jak ktoś ma maca, fajnie jakby sprawdził, ja nie mam pod ręką.
@Adam Boduch: Cześć!
Udało mi się w miarę zintegrować nowy edytor, ale mam problem.
W bibliotece mam style w pliku .scss, i na demo one działają normalnie. Jak dołączyłem je do coyote'a, to się nie apply'ują. Muszę wykonać jakąś dodakową komendę żeby odpalić te style? Nie rozumiem czemu webpack ich nie dodaje.
Jest coś o czym zapomniałem, jeśłi chodzi o ładowanie styli z biblioteki?
@Adam Boduch Na razie dodałem takie coś do core.scss:
@import "../../node_modules/@riddled/4play/src/style";
Ale coś mi się wydaje że to jest mega słabe.
Póki co podniosłem wersję Node w kontenerze bo mieliśmy starą wersję 10.x i ona mogła stwarzać problemy z pakietami. Nie obyło się bez podniesienia wersji niektórych pakietów. Możesz więc zaktualizować swój obraz.
Jeżeli chodzi o import styli to możesz użyć ~ jako aliasu do node_modules.
Adam Boduch napisał(a):
Możesz więc zaktualizować swój obraz.
Ale masz na myśli dockerowy obraz? Bo ściągnąłem od nowa 4programmers/php-node i nie widzę różnicy. Hash taki sam jak wcześniej.
Hmmm, to dziwne. Jak widać, tutaj zaktualizowałem node.js: https://hub.docker.com/layers/63157053/4programmers/php-node/latest/images/sha256-0673ddf8c092b3ceaeb23ea4d276e35bb53acfe14ce560697a9e2e684a9367c6?context=repo
19h temu...
@Adam Boduch: Wrzuciłem PR: https://github.com/adam-boduch/coyote/pull/668
Tylko jest problem z integracją edytora z SearchBarem.
Zauważyłem że SearchBar przechwytuje wciśnięcie ?, i sprawdza jeśli efekt wyszedł z taga input|textarea|select|button, to to olewa. Problem jest taki że 4play jest na divie, który jest content-editable. Jest to zrobione po to żeby eventy edytora nakładane przez przeglądarke (skróty, outline, etc.) nie integrowały w biblioteke. Jeśli miałbym to zrobić na textarea, to musiałby pododawać preventDefault() do większość eventów.
Na razie ogarnąłem to tak, że <SearchBar/> robi checka, ale nie wiem czy to dobry pomysł?
Sam taki check by wystarczył, ale nie wiem czy wtedy przypadkiem nie złapiemy niepotrzebnych tagów?
if (htmlElement.isContentEditable) {
return false;
}
Więc dla pewności zrobiłem:
if (htmlElement.isContentEditable) {
return !htmlElement.closest(".editor-4play"); // make sure we found 4play editor
}
Kolejny postopne integracji 4play z coyote'm.
Zauważyłem że plugin do vue jest bardzo coupled do taga <textarea/>, więc najpierw trzeba "odkręcić" plugin od niego, i dopiero potem zintegrować z z coyotem.
Dokładnie to chodzi o kombinacje Ctrl+/. Ja chciałem zrobić tak jak jest na większości stron, czyli samo / ale był opór gdyż chyba nadpisywałoby to skrót używany na FF.
Ciekawe, bo używamy w module Praca CKEditora. On też oparty jest na content-editable ale sprawdziłem i tam mu ten skrót jakoś nie przeszkadza.
@TomRiddle czy gdzieś można zobaczyć źródła edytora? Bo coś nie mogę znaleźć. npm podaje że paczka zajmuje 100 kB :o Czy to jest rozmiar z testami? Bo aż się boje ile to będzie zajmować razem z CodeMirror :| Myślałem, czy by przy pomocy WebPacka nie ładować edytora dynamicznie. I co, nie dało się tego finalnie zintegrować z Prism czy z autocomplete używanym u nas?
P.S. Chyba dobrze by było zrobić merga Twojego brancha nie z masterem, ale z gałęzią o innej nazwie, prawda? Byśmy mogli wtedy na 4programmers.dev wdrożyć tę gałąź.
Adam Boduch napisał(a):
Dokładnie to chodzi o kombinacje Ctrl+/. Ja chciałem zrobić tak jak jest na większości stron, czyli samo / ale był opór gdyż chyba nadpisywałoby to skrót używany na FF.
Ale to ma działać również wtedy kiedy jest Focus na edytor? Czy tyło spoza? Bo zauważyłem że Ctrl+? pokazuje searcha, jeśli ma się focus nie w edytorze.
Ciekawe, bo używamy w module Praca CKEditora. On też oparty jest na
content-editableale sprawdziłem i tam mu ten skrót jakoś nie przeszkadza.
Może tam nie jest podpięty ten plugin? No dziwne, sprawdzę.
@TomRiddle czy gdzieś można zobaczyć źródła edytora? Bo coś nie mogę znaleźć. npm podaje że paczka zajmuje 100 kB :o Czy to jest rozmiar z testami?
Wysłałem Ci zapro na githubie.
Bo aż się boje ile to będzie zajmować razem z CodeMirror :| Myślałem, czy by przy pomocy WebPacka nie ładować edytora dynamicznie.
Mój kod edytora to około 12 plików po 30-50 linijek każdy. W repo dodatkowo są testy, kodu około 20x więcej plus demo. Te testy w ogóle zajęły sporo czasu żeby je napisać, teraz jest ich około 220, otestowane są komendy, eventy, formatowanie i niektóre extensiony.
Mogę Ci wysłać podsumowanie ile zajmuje dokładnie każdy jeden z "pod-elementów" CodeMirror.
I co, nie dało się tego finalnie zintegrować z Prism czy z autocomplete używanym u nas?
Z jednym i drugim są dwa podejścia.
Z pismem jest taki że nie udało mi się łatwo "wydestylować kolorowania" bo prism miesza bezpośrednio w DOMie, na co nie można pozwolić jak się używa CodeMirror. Mogę wystawić API dla dowolnego kolorowania, ale problemem jest, jak zrobić żeby Prism wolał moje API zamiast mieszać w DOMie bezpośrednio.
Co do autocomplete - pomyślałem że mógłbym skorzystać z tego co autocomplete co już jest w coyote (dla userów), ale jest w 4play również autocomplete do kodu, więc kod autocomplete'a tak czy tak byłby zaladownay.
P.S. Chyba dobrze by było zrobić merga Twojego brancha nie z masterem, ale z gałęzią o innej nazwie, prawda? Byśmy mogli wtedy na 4programmers.dev wdrożyć tę gałąź.
Tak myślałem na początku, ale nie widziałem żadnej branchy develop ani nic takiego. Zrobię rebase z nowym masterem i zmienię target.
@Adam Boduch Czy jeśli zmienię <textarea> w aktualnym markdown.vue na nowy edytor, to autocomplete userów będzie gdzieś jeszcze używany?
Możemy pójść na wiele kompromisów co do nowego edytora. Domyślam się że masz porobione plugin w Vue do komponentów, bo chciałbyś mieć taką strukturę "extensionów", żeby móc dodawać zachowanie do edytora bez potrzeby jego zmiany, taki Open/Close? Bo jeśli tak to super, bo nowy edytor jest zbudowany na podobnej zasadzie. Np. żeby wyłączyć autocomplete wystarczy go nie dodawać jako extension, i już :> masz już dostęp do Github'a, więc możesz zauważyć że w pliku Editor.js widać to bardzo ładnie, że tak na prawdę to ja bardziej rozwijam extensiony do code mirror, niż faktyczny edytor, więc jeśli mamy jakiś problem z extensibility to z nowym edytorem możemy to łatwo ogarnąć. Editor.js to bardziej taka fasada.
Co do kolorowania składni, to możemy w sumie wywalić je. Będziemy kolorować tylko block kodu na szaro, ale samych słów kluczowych nie musimy, byłyby na czarno. Wtedy można by się pozbyć extensiona - parser języków. No albo możemy tak przerobić Prism żeby nie mieszał w DOMie tylko zwrócił jakąś listę tokenów albo coś takiego. Twój wybór w sumie. Bo tak jak o tym teraz myślę, to faktycznie trochę głupio że w edytorze jest jedno kolorowanie a w poście inne.
Co do ładowania dynamicznego różnych extensionów, to możemy to zrobić, powinno to działać całkiem okej.
Co do autocomplete, to mi osobiście bardzo się podoba motyw że z extensionem CodeMirror do autocomplete, okienko się pokazuje pod cursorem, a nie na dole. Fajne to działa jak jest długi post, pewnie dałoby się to dodać do aktualnego, ale w nowym już jest.
PS: Myślę że wystarczy żebyś mi powiedział dokładnie jakie cechy ma spełniać ten edytor od strony developerskiej?
Może np chciałbyś żeby edytorem dało się sterować dyrektywami Vue? Teraz zrobiłem tak że wszystko jest włączone domyślnie, ale bardzo prosto dałoby się go tak przerobić, żebyś mógł np. dodać autocomplete pisząc <vue-editor v-autocomplete/> albo żeby się dało włączyć kolorowanie dyrektywą v-parse czy coś takiego. Widzę taki motyw w Twoich komponentach Vue, i jeśli zależy Ci na tym to możemy dodać coś takiego do nowego edytora, no problemo. On jest zbudowany na extensionach tak czy tak, więć po prostu możemy włożyć kilka extensionów do "core'a edytora", a reszte dodawać przez dyrektywy i pluginy.
A jeśli chodzi Ci o coś innego, to just tell me, dostosujemy nowy edytor pod Twój styl.
TomRiddle napisał(a):
Ale to ma działać również wtedy kiedy jest Focus na edytor? Czy tyło spoza? Bo zauważyłem że Ctrl+? pokazuje searcha, jeśli ma się focus nie w edytorze.
Tak, dokładnie. Ten skrót miał działać jedynie poza polami, gdzie możemy wpisać tekst.
Mój kod edytora to około 12 plików po 30-50 linijek każdy. W repo dodatkowo są testy, kodu około 20x więcej plus demo. Te testy w ogóle zajęły sporo czasu żeby je napisać, teraz jest ich około 220, otestowane są komendy, eventy, formatowanie i niektóre extensiony.
Spoko. Pewnie npm podaje rozmiar całego repo, wraz z testami :)
Z pismem jest taki że nie udało mi się łatwo "wydestylować kolorowania" bo prism miesza bezpośrednio w DOMie, na co nie można pozwolić jak się używa CodeMirror. Mogę wystawić API dla dowolnego kolorowania, ale problemem jest, jak zrobić żeby Prism wolał moje API zamiast mieszać w DOMie bezpośrednio.
Tak myślałem na początku, ale nie widziałem żadnej branchy
developani nic takiego. Zrobię rebase z nowymmasterem i zmienię target.
Ok, utworzyłem gałąź staging.
@Adam Boduch Czy jeśli zmienię
<textarea>w aktualnymmarkdown.vuena nowy edytor, to autocomplete userów będzie gdzieś jeszcze używany?
Tak. Obecnie mamy następujące komponenty:
<input> wraz z listą rozwijalną. Używamy go np. w wiadomościach prywatnych do podpowiadania nazw użytkowników.<textarea> albo <input>. Obecnie służy do podpowiadania nazw użytkowników po wpisaniu znaku '@'Możemy pójść na wiele kompromisów co do nowego edytora. Domyślam się że masz porobione plugin w Vue do komponentów, bo chciałbyś mieć taką strukturę "extensionów", żeby móc dodawać zachowanie do edytora bez potrzeby jego zmiany, taki Open/Close? Bo jeśli tak to super, bo nowy edytor jest zbudowany na podobnej zasadzie. Np. żeby wyłączyć autocomplete wystarczy go nie dodawać jako extension, i już :> masz już dostęp do Github'a, więc możesz zauważyć że w pliku
Editor.jswidać to bardzo ładnie, że tak na prawdę to ja bardziej rozwijam extensiony do code mirror, niż faktyczny edytor, więc jeśli mamy jakiś problem z extensibility to z nowym edytorem możemy to łatwo ogarnąć.Editor.jsto bardziej taka fasada.
Fajnie :)
Co do kolorowania składni, to możemy w sumie wywalić je. Będziemy kolorować tylko block kodu na szaro, ale samych słów kluczowych nie musimy, byłyby na czarno.
No właśnie. Może tego nie potrzebujemy? Co myślicie? Bo i tak nie ogarniemy tego tak jak ogarnia to Prism (oraz liczby języków, które Prism ogarnia).
Adam Boduch napisał(a):
Ale to ma działać również wtedy kiedy jest Focus na edytor? Czy tyło spoza? Bo zauważyłem że Ctrl+? pokazuje searcha, jeśli ma się focus nie w edytorze.
Tak, dokładnie. Ten skrót miał działać jedynie poza polami, gdzie możemy wpisać tekst.
Może dodać jakiś generyczny test typu if (target ma klasę 'text-input') { nie odpalaj szukarki; }, wtedy w dowolnym miejscu można dodać .text-input bez potrzeby każdorazowego poprawiania testu szukarki?
Adam Boduch napisał(a):
Z pismem jest taki że nie udało mi się łatwo "wydestylować kolorowania" bo prism miesza bezpośrednio w DOMie, na co nie można pozwolić jak się używa CodeMirror. Mogę wystawić API dla dowolnego kolorowania, ale problemem jest, jak zrobić żeby Prism wolał moje API zamiast mieszać w DOMie bezpośrednio.
Co do kolorowania składni, to możemy w sumie wywalić je. Będziemy kolorować tylko block kodu na szaro, ale samych słów kluczowych nie musimy, byłyby na czarno.No właśnie. Może tego nie potrzebujemy? Co myślicie? Bo i tak nie ogarniemy tego tak jak ogarnia to Prism (oraz liczby języków, które Prism ogarnia).
Okej, to wywalmy teraz kolorowanie z code-mirror, będzie w kontroli wersji więc w razie czego się przywróci. A na razie będzie na czarno kolor, i może się uda ogarnąć Prism'a, żeby nie modyfikował DOMu, ale to na później.
Tak myślałem na początku, ale nie widziałem żadnej branchy
developani nic takiego. Zrobię rebase z nowymmasterem i zmienię target.Ok, utworzyłem gałąź
staging.
Cool, dzięki.
@Adam Boduch Czy jeśli zmienię
<textarea>w aktualnymmarkdown.vuena nowy edytor, to autocomplete userów będzie gdzieś jeszcze używany?Tak. Obecnie mamy następujące komponenty:
- autocomplete.vue: jest to pole
<input>wraz z listą rozwijalną. Używamy go np. w wiadomościach prywatnych do podpowiadania nazw użytkowników.- prompt.vue: może być użyty w
<textarea>albo<input>. Obecnie służy do podpowiadania nazw użytkowników po wpisaniu znaku '@'- dropdown.vue: ten komponent jest użyty w dwóch powyższych. Po prostu jest to lista z wynikami wyszukiwania, którą można nawigować klawiszami góra/dół
I rozumiem że w żadnym z tych miejsc nie chcesz używać nowego edytora? Bo np. w nich już nie ma markdownu? Bo w sumie łatwo możnaby tak dobrać extensiony w CodeMirror, żeby nie było markdownu, kolorowania ani nic takiego, i byłby sam tylko autocomplete? Rzucam pomysł tylko.
Ja powiem tak. Jeśli edytor jest taki "defaultowy", to można używać <input/>, <markdown/>. Ale jak chcemy dodać jakieś zachowanie, nt treści w nim, np dodaj * dookoła tekstu, to już można by CodeMirror użyć. IMO! Ale może też to nie ma sensu, i lepiej się ograniczyć tylko do edytora postów/mikroblogów. Rzucam pomysł tylko.
Możemy pójść na wiele kompromisów co do nowego edytora. Domyślam się że masz porobione plugin w Vue do komponentów, bo chciałbyś mieć taką strukturę "extensionów", żeby móc dodawać zachowanie do edytora bez potrzeby jego zmiany, taki Open/Close? Bo jeśli tak to super, bo nowy edytor jest zbudowany na podobnej zasadzie. Np. żeby wyłączyć autocomplete wystarczy go nie dodawać jako extension, i już :> masz już dostęp do Github'a, więc możesz zauważyć że w pliku
Editor.jswidać to bardzo ładnie, że tak na prawdę to ja bardziej rozwijam extensiony do code mirror, niż faktyczny edytor, więc jeśli mamy jakiś problem z extensibility to z nowym edytorem możemy to łatwo ogarnąć.Editor.jsto bardziej taka fasada.Fajnie :)
Cooll
Marooned napisał(a):
Adam Boduch napisał(a):
Ale to ma działać również wtedy kiedy jest Focus na edytor? Czy tyło spoza? Bo zauważyłem że Ctrl+? pokazuje searcha, jeśli ma się focus nie w edytorze.
Tak, dokładnie. Ten skrót miał działać jedynie poza polami, gdzie możemy wpisać tekst.
Może dodać jakiś generyczny test typu
if (target ma klasę 'text-input') { nie odpalaj szukarki; }, wtedy w dowolnym miejscu można dodać.text-inputbez potrzeby każdorazowego poprawiania testu szukarki?
Spoko pomysł w sumie, mnie też dziwił ten check sprawdzania tagów.
Tylko nie wiem czy poszedłbym w klasę (może lepiej dyrektywa Vue, skoro search bar jest w Vue), albo jeśli to ma być klasa to ja bym ją bardziej przybliżył do samego search'a, typu "non-search-input", albo coś bardziej generic jak "focus-contained-input", znaczący "focus nie wychodzi poza ten input"). Sama klasa .text-input mi wygląda jak coś co styluje input z jakiegoś bootstrapa.
Ale pomysł spoko.
TomRiddle napisał(a):
I rozumiem że w żadnym z tych miejsc nie chcesz używać nowego edytora? Bo np. w nich już nie ma markdownu? Bo w sumie łatwo możnaby tak dobrać extensiony w CodeMirror, żeby nie było markdownu, kolorowania ani nic takiego, i byłby sam tylko autocomplete? Rzucam pomysł tylko.
"Czysty" textarea jest używany w komentarzach - np. pod postem, czy do wpisów na mikro. Myślę, że póki co prosty textarea starcza, ale w przyszłości - kto wie :)
Adam Boduch napisał(a):
Co do kolorowania składni, to możemy w sumie wywalić je. Będziemy kolorować tylko block kodu na szaro, ale samych słów kluczowych nie musimy, byłyby na czarno.
No właśnie. Może tego nie potrzebujemy? Co myślicie? Bo i tak nie ogarniemy tego tak jak ogarnia to Prism (oraz liczby języków, które Prism ogarnia).
Zrobione ;)
https://danon.github.io/4play.demo/
PS: Przez to żę nie ma już dynamicznego ładowania kolorowania języków czas builda się znacznie wykrócił.
@Adam Boduch: Chyba coś się nie udało: https://github.com/adam-boduch/coyote/runs/4582099281?check_suite_focus=true
Wywaliły się testy, które operują na <textarea>. Możemy powrócić do tego później. Czy mógłbyś zmienić swojego pull requesta z brancha master na staging?