Witam

Mam pewien problem. Mam tabelę z wynikami rekordów z bazy danych. 1
wiersz tabeli = 1 rekord. W ostatniej kolumnie tabeli znajduja sie
guziki do wykonania operacji na rekordzie (usun, (de)aktywuj, edytuj
itp). W pierwszej kolumnie tabeli znajduja sie checkbox'y, po
zaznaczeniu ktorych rekord zaznaczany jest do multiedycji. Na dole
tabeli znajduje sie <select> z ktorego wybieram akcje dla tak
zaznaczonych rekordow, oraz submit, ktory wysyla liste rekordow, oraz
akcje do skryptu, ktory je obrobi.

Struktura wyglada tak (w uproszczeniu):

<form>
<table>
<tr>
<td>checkbox</td>
<td>dane</td>
<td><form>opcje dla jednego rekordu</form></td>
</tr>
[...]
<tr>
<td>opcje dla wielu rekordow</td>
</tr>
</table>
</form>

i teraz. Form SHOULD NOT be nested. Ww struktura działa prawidłowo w
firefoxie. Jest to czesc autorskiego CMS na swoje potrzeby, wiec na
razie przejmowac sie innymi przegladarkami nie musze. Niemniej chcialbym
wiedziec, czy takie rozwiazanie w przyszlosci nie bedzie mnie kosztowac
pracy, nerwow i przerabiania

--
pozdrawiam!

http://webtrunki.pl - piwa, wina, wódki, domowe wyroby
ZAPRASZAMY!!

do góry

olo pisze:
> Witam
>
> Mam pewien problem. Mam tabelę z wynikami rekordów z bazy danych. 1
> wiersz tabeli = 1 rekord. W ostatniej kolumnie tabeli znajduja sie
> guziki do wykonania operacji na rekordzie (usun, (de)aktywuj, edytuj
> itp). W pierwszej kolumnie tabeli znajduja sie checkbox'y, po
> zaznaczeniu ktorych rekord zaznaczany jest do multiedycji. Na dole
> tabeli znajduje sie <select> z ktorego wybieram akcje dla tak
> zaznaczonych rekordow, oraz submit, ktory wysyla liste rekordow, oraz
> akcje do skryptu, ktory je obrobi.
>
> Struktura wyglada tak (w uproszczeniu):
>
> <form>
> <table>
> <tr>
> <td>checkbox</td>
> <td>dane</td>
> <td><form>opcje dla jednego rekordu</form></td>
> </tr>
> [...]
> <tr>
> <td>opcje dla wielu rekordow</td>
> </tr>
> </table>
> </form>

Zamiast:

> <td><form>opcje dla jednego rekordu</form></td>

Zrób

<td>
<input type="submit" name="record_x" value="del" />
<input type="submit" name="record_x" value="edit" />
...
</td>

Wtedy nie musisz zagnieżdżać formularzy.

Możliwe że lepsze będzie użycie <button /> ale piszę z palca a coraz
mniej się bawię htmlem.

--
yew

do góry

yew pisze:
>> Struktura wyglada tak (w uproszczeniu):
>>
>> <form>
>> <table>
>> <tr>
>> <td>checkbox</td>
>> <td>dane</td>
>> <td><form>opcje dla jednego rekordu</form></td>
>> </tr>
>> [...]
>> <tr>
>> <td>opcje dla wielu rekordow</td>
>> </tr>
>> </table>
>> </form>
>
> Zamiast:
>
> > <td><form>opcje dla jednego rekordu</form></td>
>
> Zrób
>
> <td>
> <input type="submit" name="record_x" value="del" />
> <input type="submit" name="record_x" value="edit" />
> ...
> </td>
>
> Wtedy nie musisz zagnieżdżać formularzy.
>
> Możliwe że lepsze będzie użycie <button /> ale piszę z palca a coraz
> mniej się bawię htmlem.
>

sek w tym, ze ten "duzy" form, czyli ten przed cala tabela, ma zupelnie
inny "action" niz te "male" formy wewnatrz komorek. Teoretycznie daloby
rade wysylac wszystko zawsze do jednego skryptu, ktory juz odpowiednio
dane by obrobil, ale wydaje mi sie to troche nieeleganckie (zwlaszcza,
ze uzytkownicy moga miec rozne uprawnienia i nie kazdy moc np. usuwać
rekordy). Takto mam osobny plik .php do osobnej akcji i nie gubie sie
nawet jak po roku lub wiecej czasu wracam do projektu.

--
pozdrawiam!

http://webtrunki.pl - piwa, wina, wódki, domowe wyroby
ZAPRASZAMY!!

do góry

olo pisze:
> yew pisze:
> sek w tym, ze ten "duzy" form, czyli ten przed cala tabela, ma zupelnie
> inny "action" niz te "male" formy wewnatrz komorek. Teoretycznie daloby
> rade wysylac wszystko zawsze do jednego skryptu, ktory juz odpowiednio
> dane by obrobil, ale wydaje mi sie to troche nieeleganckie (zwlaszcza,
> ze uzytkownicy moga miec rozne uprawnienia i nie kazdy moc np. usuwać
> rekordy). Takto mam osobny plik .php do osobnej akcji i nie gubie sie
> nawet jak po roku lub wiecej czasu wracam do projektu.

IMO jest to właśnie eleganckie - to właśnie funkcja kontrolera, aby
rozdzielać akcje w zależności od zachowania użytkownika. Przyglądając
się realizacjom opartym o przeróżne frameworki twierdzę, że jest też
dość powszechne. Jeden kontroler może mieć kilka akcji - każda
realizowana w zależności od przesłanego submita.
Zagnieżdżone formy prędzej czy później odbiją się czkawką.

--
Radek N.

do góry

Radek N. pisze:
> IMO jest to właśnie eleganckie - to właśnie funkcja kontrolera, aby
> rozdzielać akcje w zależności od zachowania użytkownika. Przyglądając
> się realizacjom opartym o przeróżne frameworki twierdzę, że jest też
> dość powszechne. Jeden kontroler może mieć kilka akcji - każda
> realizowana w zależności od przesłanego submita.
> Zagnieżdżone formy prędzej czy później odbiją się czkawką.
>

no dobra. Namowiles mnie ;)

Przerobilem te tabelke tak, by jeden skrypt obslugiwal wszystkie
operacje. Aby nie robic sobie dodatkowej roboty i pozostac w zgodnosci z
pewnym systemem nadal zostaly osobne pliki .php do obslugi operacji na
pojedynczych rekordach, a plik do ktorego wysylane jest zapytanie po
prostu je includuje. Wszystko dziala prawidlowo, ale zostalo teraz jedno
male ale..

Mianowicie. Jedna z opcji na pojedynczym rekordzie to edycja. Jest na
swoj sposob wyjatkowa. Wszystkie pozostale buttony wykonuja natychmiast
pewne akcje: aktywacja, deaktywacja, usuwanie. Zas ten jeden nie
wykonuje zadnej akcji. Najzwyczajniej w swiecie przechodzi do zadanego
url z identyfikatorem rekordu do edycji w POST. Zeby zrozumiec w czym
problem przyblize zasade dzialania calego CMS:

- wszystkie form tak naprawde maja action=""
- w polu hidden przesylana jest informacja ze ma zostac wykonana akcja,
dzieki temu w index.php moge odpalic skrypt zajmujacy sie obrabianiem akcji
- akcje sa wykonywane zanim wyslany zostanie jakikolwiek naglowek
- po wykonaniu akcji strona moze zostac przekierowana pod zadany url
(jesli zostalo wyslane żądanie w innej informacji w polu hidden),
odswiezona jesli POST nie jest juz potrzebny, lub po prostu kontynuacja
wczytywania

w przypadku operacji na danych z tabeli o ktorej mowie, dane zostaja
wyslane do konkretnego pliku z konkretnymi ustawieniami, w tym wypadku:
zachowaj POST i zostan na stronie, z ktorej nastapilo wywolanie.
Sprawdza sie to dla wszystkich submitow z wyjatkiem edycji - bo ten nie
ma wykonywac zadnej akcji a tylko przejsc do innego URL w ktorym rekordy
sa edytowane.

Moge co prawda wyslac edycje takze do tego samego pliku kontrolera,
rozpoznac ja jako edycje i wyslac przekierowanie (bo jak wspomnialem nie
mam wyslanych zadnych naglowkow), ale potrzebuje przemycic identyfikator
rekordu do edycji i nie chcialbym robic tego GETem (estetyka, nigdzie
mie mam GET, tylko same POST).

w google znalazlem to: http://www.webmasterworld.com/forum88/10801.htm
co wskazuje, ze nie da sie w prosty sposob zrobic przekierowania z
danymi w POST.

Ktoś ma jakieś doswiadczenia w tym temacie?

--
pozdrawiam!

http://webtrunki.pl - piwa, wina, wódki, domowe wyroby
ZAPRASZAMY!!

do góry

yew wrote:
> Zamiast:
>
>> <td><form>opcje dla jednego rekordu</form></td>
>
> Zrób
>
> <td>
> <input type="submit" name="record_x" value="del" />
> <input type="submit" name="record_x" value="edit" />
> ...
> </td>
>
> Wtedy nie musisz zagnieżdżać formularzy.
>
> Możliwe że lepsze będzie użycie <button />

Nie będzie lepsze, chyba że chce mieć problemy w IE.

do góry

olo pisze:
> Przerobilem te tabelke tak, by jeden skrypt obslugiwal wszystkie
> operacje. Aby nie robic sobie dodatkowej roboty i pozostac w zgodnosci z
> pewnym systemem nadal zostaly osobne pliki .php do obslugi operacji na
> pojedynczych rekordach, a plik do ktorego wysylane jest zapytanie po
> prostu je includuje. Wszystko dziala prawidlowo, ale zostalo teraz jedno
> male ale..

Nie wiem, czy umiem Ci pomóc i przyznam, że nie analizowałem twojego
opisu (trochę czasu teraz nie mam).

1. Osobiście w takich tabelkach mam jednak GET, leci typu
controller=article&action=edit&id=23&... lub
controller=article&action=delete&id=23&... (tutaj o jakimś tokenie
pomyśl, żeby nie dało się kasować artykułów samymi linkami)

2. Czasem jak nad listą artykułów mam przyciski typu "Zaznaczone: usuń"
to faktycznie lecą POSTem.

3. Jeśli już muszę przekazywać coś między wywołaniami, to u mnie z
reguły z przesłanych danych POSTem tworzy się jakiś tam obiekt. Obiekt
mogę serializować. Serializowany obiekt zapisać w zmiennej sesji i
przekazywać w ten sposób między wywołaniami... ale to wszystko się
komplikuje, więc jeśli masz szanse ominąć ten proces to zrób to.

--
Radek N.

do góry

olo wrote:
> Moge co prawda wyslac edycje takze do tego samego pliku kontrolera,
> rozpoznac ja jako edycje i wyslac przekierowanie (bo jak wspomnialem nie
> mam wyslanych zadnych naglowkow), ale potrzebuje przemycic identyfikator
> rekordu do edycji i nie chcialbym robic tego GETem (estetyka, nigdzie
> mie mam GET, tylko same POST).

Po to jest właśnie get. Menu też masz zrobione jako formularz + post?

do góry

Paweł Piskorz pisze:
> olo wrote:
>> Moge co prawda wyslac edycje takze do tego samego pliku kontrolera,
>> rozpoznac ja jako edycje i wyslac przekierowanie (bo jak wspomnialem nie
>> mam wyslanych zadnych naglowkow), ale potrzebuje przemycic identyfikator
>> rekordu do edycji i nie chcialbym robic tego GETem (estetyka, nigdzie
>> mie mam GET, tylko same POST).
>
> Po to jest właśnie get. Menu też masz zrobione jako formularz + post?

dzien odstepu to jednak dobra ilosc. Chyba jakies zacmienie mialem :|

Menu odsyla do linkow postaci /modul/dzial/id/ itd.. nie wiem czemu
myslalem, ze bede musial zbudowac link postaci: /newsy/edytuj/?id=costam
a nie /newsy/edytuj/costam/

temat zalatwiony, zagniezdzonych <form> juz nie ma.

Dzięki wszystkim

--
pozdrawiam!

http://webtrunki.pl - piwa, wina, wódki, domowe wyroby
ZAPRASZAMY!!

do góry

Radek N. pisze:
> 3. Jeśli już muszę przekazywać coś między wywołaniami, to u mnie z
> reguły z przesłanych danych POSTem tworzy się jakiś tam obiekt. Obiekt
> mogę serializować. Serializowany obiekt zapisać w zmiennej sesji i
> przekazywać w ten sposób między wywołaniami... ale to wszystko się
> komplikuje, więc jeśli masz szanse ominąć ten proces to zrób to.

mam tak zrobione przekazywanie komunikatow, jesli wysylam żądanie
przeladowania strony celem usuniecia tablicy post. Komunikaty o ew.
bledach i informacje przekazywane sa w sesji i jesli istnieja po
przeladowaniu zczytywane, kasowane z sesji i wyswietlane. Ale
faktycznie, takiego rozwiazania wolalbym nie stosowac ;)

Niemniej sprawa sie rozwiazala o czym napisalem w poscie obok. Dzięki za
naprowadzenie

--
pozdrawiam!

http://webtrunki.pl - piwa, wina, wódki, domowe wyroby
ZAPRASZAMY!!

do góry