Clicky

Skocz do zawartości


Zdjęcie
- - - - -

[K3] koWolf - kilka dodatków

23 odpowiedzi w tym temacie

  • Zaloguj się, aby dodać odpowiedź

#1 rasgan

rasgan

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 241 postów
  • Skąd:Kleszczów

Napisano 19 marzec 2012 - 13:14

Hej,

zaczynam sobie pisać warsztat do Ko3.2.x więc może komuś się też przyda. Jeśli macie jakieś uwagi lub pomysły co może się przydać walcie śmiało. Postaram się jak mogę.

Mile widziana krytyka (konstruktywna).
Szczęścia w mrokach...

#2 rasgan

rasgan

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 241 postów
  • Skąd:Kleszczów

Napisano 19 marzec 2012 - 15:27

a bym zapomnial to jest na github użytkownik rasgan

https://github.com/rasgan

-- pozwoliłem sobie dodać link -- Zepco
Szczęścia w mrokach...

#3 skowron-line

skowron-line

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 131 postów

Napisano 19 marzec 2012 - 15:44

Jak robisz usprawnienia do ko to jakiegoś changloga wrzuć żeby było wiadomo co zmieniłeś.

#4 rasgan

rasgan

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 241 postów
  • Skąd:Kleszczów

Napisano 19 marzec 2012 - 18:04

nie tyle zmieniłem co wolf to osobny moduł z klasami isprawniajacymi pisanie np wiadomości flash czy sprawdzanie dostępu do akcji.
Szczęścia w mrokach...

#5 Zepco

Zepco

    Senior Mastah

  • Moderator
  • 1583 postów
  • Skąd:Kielce

Napisano 19 marzec 2012 - 19:01

Klasa wiadomości flash jest mocno przekombinowana. Nie ma potrzeby tworzyć instancji klasy. Zerknij na ten moduł .

Ja go jeszcze zmodyfikowałem, żeby nazwy klasy wiadomości były podawane jako nazwa funkcji, czyli:
Message::error('Jakiś błąd');
Message::success('udało się');

OŚWIADCZENIE: Ja, niżej podpisany, świadomy wszystkich konsekwencji tego posta postanawiam go dopuścić do użytku publicznego, albowiem bo gdyż aczkolwiek uważam, że nie wyrządzi on (znaczy: post) krzywdy nikomu innemu niźli mnie samemu (czyli autorowi posta).
-- Zepco --


#6 rasgan

rasgan

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 241 postów
  • Skąd:Kleszczów

Napisano 22 marzec 2012 - 23:26

Zapoznam się z tym modułem i może coś lepszego wymyślę.

Na razie zaczynam pisać galerię zdjęć, którą oczywiście wrzuciłem na githuba: https://github.com/rasgan
Szczęścia w mrokach...

#7 rasgan

rasgan

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 241 postów
  • Skąd:Kleszczów

Napisano 24 marzec 2012 - 00:12

Kilka zmian i dodatków w galerii. Czy macie jakiś pomysł jak zrobić next, prev w widoku zdjęcia do następnego i poprzedniego zdjęcia w albumie?
Szczęścia w mrokach...

#8 kevin

kevin

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 207 postów

Napisano 24 marzec 2012 - 07:32

Zobacz -> http://nospor.pl/mysql-faq.html#faq-4

#9 rasgan

rasgan

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 241 postów
  • Skąd:Kleszczów

Napisano 15 czerwiec 2012 - 10:58

https://github.com/rasgan/KoWolf-3.2.x - nowa wersja
Szczęścia w mrokach...

#10 mck

mck

    Jestę Blogerę

  • Admin
  • 1544 postów

Napisano 15 czerwiec 2012 - 11:09

Jak wrzucasz coś na githuba to dodawaj readme, żeby wiadomo było co to i po co to ;)

#11 Riu

Riu

    Senior Mastah

  • Webmastahy
  • PipPipPip
  • 949 postów

Napisano 15 czerwiec 2012 - 12:31

Message.php, aż się prosi żeby zamiast metod statystycznych rozwiązać to jakoś ładniej bez definiowania tych stałych, a właściwie bez powtarzania kilkukrotnie tej samej metody.

Mam jeszcze pytanie co do tego ACLa ponieważ nie korzystam z tego standardowego modułu i nie wiem jak on działa - tam są uprawnienia po kontrolerze i akcji?

Debian/Ubuntu + Kohana/Hanariu/Phalcon + MongoDB/MySQL + HTML5/CSS3 + Node.js/jQuery + CEO Sport Magazyn/CEO Hanariu


#12 rasgan

rasgan

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 241 postów
  • Skąd:Kleszczów

Napisano 15 czerwiec 2012 - 16:34

Tak. Definiujesz tablicę ról jaką musi miec user by odpalic kontroler (role są z ANDEM a nie OREM) oraz tablicę w postaci nazwa akcji=>array(lista rol jak do kontrolera). Tablica akcji ma wyższy priorytet niż tablica kontrolera (nadpisuje ją, że tak powiem).
Szczęścia w mrokach...

#13 rasgan

rasgan

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 241 postów
  • Skąd:Kleszczów

Napisano 15 czerwiec 2012 - 16:50

Swoją drogą jeśli masz jakieś sugestie pomysły co do klasy messages lub innej wal śmiało. Przecież po to ta dyskusja i cały wątek prawda? Bo na razie tylko gadamy na forum że ten chetny i tamten, ale konkretów nie ma, to dałem co miałem na start.
Szczęścia w mrokach...

#14 kevin

kevin

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 207 postów

Napisano 15 czerwiec 2012 - 18:10

Hej.

Podzielę się własnymi uwagami nt. Twojego projektu.
Plik "default.php" (widok) - charset wyciągnąłbym z bootstrap.php - w końcu tam definiujemy kodowanie i stamtąd jest pobierana informacja, która przekazywana jest na cały szkielet frameworka.

W 15 linijce wyświetlasz pusty element section - dlaczego nie przeniesiesz tego elementu do widoku of "flash message" i w przypadku
wiadomości wyświetlisz go. Zbędne jest wstawianie pustych elementów do kodu.

Nazewnictwo - być może to tylko moje "widzi mi się", ale zawsze mi wmawiano/sugerowano, aby jednak trzymać się nazewnictwa angielskiego przy tworzeniu funkcji, definiowaniu zmiennych, itd - wyjątkiem mogą być komentarze rzecz jasna. Jednak zapis __('Mój dom jest cały niebieski') lepiej prezentuje się jednak po angielsku - bez zbędnych znaków polskich ogonków. Poza tym zmieniłbym zapis na: __('Header blue house') - i dopiero w plikach i18n definiował właściwe tłumaczenie, zamiast od razu narzucać taki schemat.

Klasa "message" - dużo narzuciłeś możliwości, jeśli chodzi o typ komunikatu. Osobiście w swojej klasie flash message posiadam tylko trzy typy
SUCCESS|NOTICE|ERROR i to sprawdza się moim zdaniem dobrze - pasuje do każdej sytuacji (tak mi się wydaje, że do każdej)

34-35 linijka; ponownie polskie tłumaczenia. Wyznaje taką zasadę, żeby jednak teskty trzymać w i18n a dopiero w kontrolerach wywoływać je za pomocą funkcji "__()" zamiast bezpośrednio w nich pisać. Nie podoba mi się taki zapis.

Flash message ma za zadanie pokazać komunikat i zniknąć zaraz po przejściu na następną podstronę.
Dlaczego tworzysz następną funkcje "clear()" skoro przy wyświetlaniu można użyć zapisu get_once()

Plik "core.php":

69 - w Kohanie brakuje mi auto ładowanie widoków na podstawie kontrolera/akcji; wciąż nie potrafię pojąć dlaczego nie ma tego w standardzie. Osobiście u siebie w aplikacji rozwiązałem w ten sposób:

Za pomocą funkcji Kohana::find_file() szukam czy istnieje plik dla: DIRECTORY/CONTROLLER/ACTION - jeśli istnieje to automatycznie
wczytuje jego zawartość i binduje to jako np. "content" aby wywołać w głównym layoucie - i mam środek. Nie muszę za każdym razem definiować tej regułki jaką przedstawiłeś w core.php#69 - bo to idzie z automatu.

Oczywiście uwzględniłem sytuacje, abym jednak mógł zmienić widok. Czyli do warunku find_file() dodaje przed instrukcje w stylu:
!isset($this->template->content)) (pisane z pamięci) jeśli nie jest zdefiniowany content to szukaj pliku :-)


Pzdr.


#15 rasgan

rasgan

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 241 postów
  • Skąd:Kleszczów

Napisano 16 czerwiec 2012 - 00:31

UPDATE na githubie

Kevin dzięki wielkie za uwagi, bardzo pomocne. Kilka osób zwróciło mi na to uwagę więc zmieniłem jezyk na angielski, choć kuleje strasznie. Okroiłem tez klasę messages. Faktycznie te trzy typy wystarczą.

Plik "default.php" (widok) - charset wyciągnąłbym z bootstrap.php - w końcu tam definiujemy kodowanie i stamtąd jest pobierana informacja, która przekazywana jest na cały szkielet frameworka.


Z linijki set_locale czy dodatkowa zmienna? A może lepiej z configuracji globalnej?

Flash message ma za zadanie pokazać komunikat i zniknąć zaraz po przejściu na następną podstronę.
Dlaczego tworzysz następną funkcje "clear()" skoro przy wyświetlaniu można użyć zapisu get_once()


Dlatego, że funkcja generowanie komunikatów ma opcję wyłączenia czyszczenia. A jak będzie mi potrzeba wyświetlać wiadomości bez kasowania? A tak już jest gotowe i tyle.

69 - w Kohanie brakuje mi auto ładowanie widoków na podstawie kontrolera/akcji; wciąż nie potrafię pojąć dlaczego nie ma tego w standardzie. Osobiście u siebie w aplikacji rozwiązałem w ten sposób:

Za pomocą funkcji Kohana::find_file() szukam czy istnieje plik dla: DIRECTORY/CONTROLLER/ACTION - jeśli istnieje to automatycznie
wczytuje jego zawartość i binduje to jako np. "content" aby wywołać w głównym layoucie - i mam środek. Nie muszę za każdym razem definiować tej regułki jaką przedstawiłeś w core.php#69 - bo to idzie z automatu.

Oczywiście uwzględniłem sytuacje, abym jednak mógł zmienić widok. Czyli do warunku find_file() dodaje przed instrukcje w stylu:
!isset($this->template->content)) (pisane z pamięci) jeśli nie jest zdefiniowany content to szukaj pliku :-)


A nie możesz podzielić się kodem przypadkiem? Po co koło od nowa wymyślać.
Szczęścia w mrokach...

#16 Riu

Riu

    Senior Mastah

  • Webmastahy
  • PipPipPip
  • 949 postów

Napisano 16 czerwiec 2012 - 00:41

Wiesz - po skróceniu to teraz wygląda identycznie jak źródło - https://github.com/G...kohana-message.

Debian/Ubuntu + Kohana/Hanariu/Phalcon + MongoDB/MySQL + HTML5/CSS3 + Node.js/jQuery + CEO Sport Magazyn/CEO Hanariu


#17 kevin

kevin

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 207 postów

Napisano 16 czerwiec 2012 - 08:39

Jeśli chodzi o wyciąganie kodowania, to w pliku bootstrap#82 masz init różnych parametrów do aplikacji frameworka - zobacz, że standardowo masz kodowanie "utf8", które oczywiście możesz zmienić dodająć do Kohana::init parametr charset

Tak czy inaczej, w widoku wywołujesz <?php echo Kohana::$charset ?> i gotowe. W jednym pliku "bootstrap" definiujesz kodowanie i to rozchodzi się na cały framework.

Odnośnie wywoływania widoków - zacznę może od struktury głównych kontrolerów:

controller/application/core.php extends controller_template
controller/application/acp.php extends controller/application/core.php (kontroler od panelu admina)
controller/application/main.php extends controller/application/core.php (kontroler główny)

Rozbijam to na parę głównych kontrolerów, aby w core.php definiować globalne funkcje (np.usuwanie sesji użytkowników online, wczytywanie widoków, itd - a w acp.php oddzielam kod, który sprawdza uprawnienia do logowania, itd)


wywoływanie widoków kod (wycinki kodu):
public $template	= 'application/layout'; // główny layout - zaraz opisze strukturę niżej

	public function after()
	{
		if ( $this->auto_render )
		{

			$this->_initLayout();
                }
      }

	public function _initLayout()
	{
		// System request.
		$directory  = Request::current()->directory();
		$controller = Request::current()->controller();
		$action		= Request::current()->action();

		$container 	= 'application/layout/default';
		$actionpath = "{$directory}/{$controller}/{$action}";

		// View for ACP.
		if ( $directory == 'acp' )
			$container 	= 'application/layout/acp';
		
		// Load new container view.
		if ( !isset($this->template->container) )
			$this->template->container = View::factory($container);
		
		// Load container->output view.
		if ( isset($this->template->container) AND !isset($this->template->output) AND Kohana::find_file('views', "{$actionpath}") )
			$this->template->container->output = View::factory($actionpath);
	}

a teraz kwestia plików od widoku:

views/application/layout.php
w tym pliku mam sam szkielet strony (czyli nagłówki title, sekcje body, ładowanie css, itd)
+ ważny fragment kodu, czyli: <?php if ( isset($container) ): echo $container; endif ?>

w "container" trzymam kod html od:
a) widoku głównego (czyli strony głównej portalu, w której tylko środek się zmienia)
b) albo od layoutu od panelu admina

więc przechodzimy teraz do:

views/application/layout/default.php (badź acp.php)

a w tych plikach jak mówiłem główny wygląd dla strony i kod:
<?php if ( isset($output) ): echo $output; endif ?>

odpowiada za wczytanie widoku: /DIRECTORY/CONTROLLER/ACTION

ogólnie to tak się teraz to prezentuje:

=> layout.php
==> default.php
====> edit.php (np. dla news/edit/51)


rzecz jasna, jeśli chcemy inny layout (zamiast default.php zmienić na np. login.php - bo podstrona będzie miała kompletnie inny widok)
to tylko w kontrolerze np. user/login definiujemy:

$this->template->container = View::factory('application/layout/login');

Pzdr.

#18 rasgan

rasgan

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 241 postów
  • Skąd:Kleszczów

Napisano 18 czerwiec 2012 - 08:05

@riu - dodałem linka do oryginału, tam się wzorowałem i przerabiałem, a jak uprościłem to wyszło tak samo :) Więc dodałem link.

@kevin bardzo fajny pomysł, ale coś mi nie chce to działać. Jak dam inicjację widoków w after tak jak ty to masz to mi się nie inicjują w ogóle. Muszę nad tym posiedzieć chwilkę.
Szczęścia w mrokach...

#19 Zepco

Zepco

    Senior Mastah

  • Moderator
  • 1583 postów
  • Skąd:Kielce

Napisano 18 czerwiec 2012 - 09:35

Może zapominasz o parent::after() ?

OŚWIADCZENIE: Ja, niżej podpisany, świadomy wszystkich konsekwencji tego posta postanawiam go dopuścić do użytku publicznego, albowiem bo gdyż aczkolwiek uważam, że nie wyrządzi on (znaczy: post) krzywdy nikomu innemu niźli mnie samemu (czyli autorowi posta).
-- Zepco --


#20 rasgan

rasgan

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 241 postów
  • Skąd:Kleszczów

Napisano 18 czerwiec 2012 - 10:26

tak zapomniałem :) dzięki
Szczęścia w mrokach...

#21 rasgan

rasgan

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 241 postów
  • Skąd:Kleszczów

Napisano 22 czerwiec 2012 - 14:50

Kolejny update - możliwość odpalenia skinów. Dziś będę walczył z userami.
Szczęścia w mrokach...

#22 skowron-line

skowron-line

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 131 postów

Napisano 24 czerwiec 2012 - 10:23

<?php 
// Create controller name
        if ($dir == '') $controller_name = 'Controller_'.$controller_name;
        if ($dir != '') $controller_name = 'Controller_'.$dir.'_'.$controller_name;
?>
Czy to napewno musi tak wyglądać ??

Edit:
<?php
 /**
* Set success message
*
* @static
*
* @param $text Message content
* @param array|null $options Options
*/
    public static function success($text, array $options = NULL)
    {
        Message::set(Message::SUCCESS, $text, $options);
    }


    /**
* Set error message
*
* @static
*
* @param $text Message content
* @param array|null $options Options
*/
    public static function error($text, array $options = NULL)
    {
        Message::set(Message::ERROR, $text, $options);
    }


    /**
* Set notice message
*
* @static
*
* @param $text Message content
* @param array|null $options Options
*/
    public static function notice($text, array $options = NULL)
    {
        Message::set(Message::NOTICE, $text, $options);
    }
Tu też można by zrobić jedną wspólną metodę do której tylko parametry będziesz przekazywał.

#23 rasgan

rasgan

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 241 postów
  • Skąd:Kleszczów

Napisano 25 czerwiec 2012 - 10:46

<?php 
// Create controller name
        if ($dir == '') $controller_name = 'Controller_'.$controller_name;
        if ($dir != '') $controller_name = 'Controller_'.$dir.'_'.$controller_name;
?>


A co tu złego?

Co do drugiej uwagi to jest metoda SET a pozostałe trzy to tylko ułatwienie
Szczęścia w mrokach...

#24 phpion

phpion

    Senior Mastah

  • Użytkownik
  • PipPipPip
  • 774 postów
  • Skąd:Sosnowiec, Dąbrowa Górnicza

Napisano 25 czerwiec 2012 - 11:05

Może zastosuj po prostu if-else? Najładniej byłoby moim zdaniem tak:
$controller_name = 'Controller_'.($dir != '' ? $dir.'_' : '').$controller_name;

Notifero - Technologie Informatyczne | Warsztat: Kohana 3.x/2.x + PostgreSQL/MySQL | Programista Kohana




Użytkownicy przeglądający ten temat: 0

0 użytkowników, 0 gości, 0 anonimowych