def pesel_is? (pes)
w = [1,3,7,9]
for i in 0..9
wk = (wk+pes[i]*$w[i%4])%10
end
k = (10- wk)%10
if (pes[10]=k)
return true
else
return false
end
end
(Funkcję przepisałem z PHP http://szewo.com/php/pesel.phtml )
mam ją w app/helper/application_helper.rb
Tylko czy jest dobrze napisana (nagłówek/deklaracja funkcji) i jak ją użyć? Controler index.
if pesel_is? params[:pesel]IMHO _is nie jest tutaj potrzebne, jesli uzywasz znaku zapytania ? to z konwencji wynika ze metoda bedzie zwracac true/false.
Natomiast jedna uwaga, helpery nie sa dostepne z poziomu controllera, tylko widoku, jesli chcesz robic validacje pesela to rob to w modelu. Metode pesel? umiesc w protected i uzyj validate albo validate_each. Jesli koniecznie chcesz miec ta metode dostepna w kontrolerze, wykorzystaj katlaog lib, albo zrob plugin 
Mozesz np rozszerzyc Klase Int i String
“123456789”.pesel?
albo
123465789.pesel?
Ale to juz bylby hardcore
W sprawie modelu
Skąd dany formularz wie z jakiego modelu korzystać?!
Chciałem w jednym formularzu skorzystać z 2-3 modeli (bo z niektórych korzystam w innych częściach strony)
Myślałem, że skoro pola w formularzu nazywam sobie w sposób
<input id="user_password" name="user[password]" size="30" type="password" />
<input type="text" name="user[email]" value="qwe@qer.ple" />
<input type="text" name="profil[first_name]" value="" />
To oprócz tego, że przy zapisie muszę użyć osobnych zapisów
if @profil.update_attributes(params[:user])
and @profidane.update_attributes(params[:profil])
To także 2 modele będę mógł wykorzystać 
a tu jednak nie działa mi ten drugi model, tylko formularz korzysta z tego głównego (co go pierwszego utworzyłem).
Więc skąd formularz wie z jakiego modelu korzystać i jak można korzystać z kilku modeli?
@pawel - nie zadziałało nie chce skorzystać z nowego modelu
app/models/profil.rb
class Profil < ActiveRecord::Base
validates_presence_of :first_name
validates_length_of :first_name, :in=>2
end
app/views/panel/dane.rhtml
[code=“ruby”]<% form_for :user, @profil, :url=> { :action => ‘update’ } do |user| %>
|
Dane logowania
PESEL: <%= user.text_field :pesel %> Hasło: <%= user.password_field :password %> E-mail: <% fields_for :profil, @profil do |profil| %> Dane personalne Imię: <%= profil.text_field :first_name %> <% end %> <% end %>[/code] Co zwraca: [code="html"]
|
:in przyjmuje range np :in => 2…48, sprobuj :minimum => 2, bo jak sie wszystko aktualizuje to sprawa walidacji a nie formularza
Wywala exception bo (validations.rb 468)
raise ArgumentError, “:#{option} must be a Range” unless option_value.is_a?(Range)
ale pewnie gdzies po drodze sie gubi i po prostu ta walidacja jest pomijana.
Skąd masz ten błąd niby?
Czyli jak naprawić to pomijanie validacji?
Co do funkcji walidującej to bardziej optymalne jest stworzenie tablicy w = [1,3,7,9,1,3,7,9,1,3] i wówczas odwoływać się do elementów tablicy przez $w[i] a niżeli definiować tablicę w = [1,3,7,9] i wtedy niepotrzebnie 10 razy wykonuje się operację modulo w pętli $w[i%4].
Mniej kodu nie zawsze oznacza szybsze działanie.
Ostatnio znalazłem fajną stronkę na której można bardzo dużo ciekawych i unikatowych rzeczy poczytać o numerze PESEL. Kolesie widać trochę się przyłożyli bo wszystko jest czytelne i w ogóle dobrze wygląda.
Pozdro
W kwestii peselu ważna uwaga: niektóre faktycznie nadane numery pesel mają niepoprawną sumę kontrolną. Zatem przy niepoprawnym numerze powinno być tylko generowane ostrzeżenie, ale nie powinno to uniemożliwiać zapisu takiego numeru do bazy.
Co do strony, którą zaproponował lukio, to może jest i ładna graficznie, ale raczej trudno stwierdzić, że są tam jakieś unikatowe informacje - strona w Wikipedii zawiera znacznie więcej informacji. A pobieranie opłat za banalne skrypty do sprawdzania numeru pesel i określania płci, to już czysta porażka. Tego typu algorytmy omawiam na 3 zajęciach w pierwszym semestrze studiów, bynajmniej nie informatycznych 
Acha, jeszcze jedna mała uwaga - w Ruby $ na początku nazwy zmiennej oznacza zmienną globalną, więc to w ogóle nie powinno pojawić się w kodzie. Rozumiem, że to po prostu phpowa naleciałość 
Mniej kodu zazwyczaj oznacza wolniejsze działanie. Ale jeśli ktoś nie implementuje aplikacji sprawdzającej 1000 peseli w ciągu sekundy, to różnica dzielenie modulo/brak dzielenia jest pomijalna. Optymalizacja ma sens wtedy gdy wiemy czy jej zastosowanie przyniesie jakikolwiek istotny efekt (dzięki profilowaniu). Oczywiście nie należy jej zupełnie pomijać, ale przywiązywanie do niej zbyt wielkiej wagi też nie jest właściwe.
[quote]W sprawie modelu
Skąd dany formularz wie z jakiego modelu korzystać?![/quote]
On tego wcale nie wiem - musisz mu to “powiedzieć”, a dokładniej zainicjować zmienne klasowe, powiedzmy @user oraz @profil, do których potem odwołujesz się przez form_for :user oraz fields_for :profile. Rozumiem jednak, że ta sprawa jest już załatwiona.
Jest jeszcze jedna rzecz, która zwróciła moją uwagę, ale dane niepełne, więc trudno mi tu cokolwiek rozstrzygać. Chodzi mi o użycie dwóch modeli User oraz Profil (czy Profil i Profildane, trudno mi wywnioskować na podstawie kodu). Jeśli wszystko tworzone jest razem, to po co używać dwóch klas dla relacji 1-1 (domyślam się, że jeden User ma tylko jeden Profil)? Jeśli zaś jest tworzone osobno to update chyba też lepiej rozbić?
Byłbym zapomniał - Lukio - witamy na forum
[quote=lukio]Co do funkcji walidującej to bardziej optymalne jest stworzenie tablicy w = [1,3,7,9,1,3,7,9,1,3] i wówczas odwoływać się do elementów tablicy przez $w[i] a niżeli definiować tablicę w = [1,3,7,9] i wtedy niepotrzebnie 10 razy wykonuje się operację modulo w pętli $w[i%4].
Mniej kodu nie zawsze oznacza szybsze działanie.[/quote]
Rozumiem ze Ty z tych co walcza o kazdy takt procesora ? W takim razie zapraszam na forum poswiecone asemblerowi a nie rubyonrails
ROR jest w wielu miejscach nie optymalne przez to ze stara sie byc czytelne dla programisty. Cos za cos.
Natomiast nie wydaje mi sie zeby optymalizowanie funkcji sprawdzajacych pesel mialo uzasadnienie:)
Kolega pewnie chce zastapic Mainfrejmy w ministrerstwie