[PHP] Goede oplossing?

[kaandorp]

Ik moet even een newssysteempje maken waarbij de gebruiker net als bij GoT een bericht typt op preview klikt eventueel op edit klikt en vervolgens op publish.

Om dit te krijgen laat ik bij een klik op preview alle form vars zetten in een array binnen de session array. Als de gebruiker dan weer op edit drukt worden deze vars teruggelezen uit de array. Als de gebruiker op publish drukt wordt het geheel in de database gezet.

Is dit een goede oplossing? Of zou ik het anders moeten doen.

[ACM]

Ik vindt het wel een leuke oplossing

Waarom niet?
Je kan ze ook continue heen en weer laten posten (edit/publish etc zijn tenslotte post-submitters).

[Verwijderd]

euhm en als die kerel een andere pagina aaroept en hij komt weer op die post pagina, wordt dan alsnog die troep weer ingelezen?

[kaandorp]

Uh.. Das een goeie. Waarschijnlijk niet, want ik geef een actie mee. En als die aktie niet is ingevuld kom je vanzelf op een leeg nieuw formulier.
Als de actie edit is zal hij wel kijken of er variabelen zijn. Alleen moet ik dus ff die vars leeg gooien zodra het hele zaakje in de db staat.

[LuCarD]

Wis de sessie op de post pagina....

dat is wat ik tenminste doe...

Ik doe in principe het zelfde met een inschrijf formulier. Ik maak in mijn sessie een soort tijdelijk DB. En op het moment dat de gebruiker zegt save sla ik alles in de echte db en wordt de sessie gewist.

[Janoz]

Ikzelf zet in de pagina gewoon precies hetzelfde formulier, maar nu met alle input types als hidden. Op deze manier is er geen enkel verschil tussen het submitten rechtstreeks vanaf het form en submitten na een preview. Het weer editen is vergelijkbaar emt wat er gebeurt als de velden niet goed worden ingevuld, met het verschil dat er nu geen foutmelding of waarschuwing oid gegeven moet worden.

[Verwijderd]

Op woensdag 22 mei 2002 13:29 schreef Janoz het volgende:
Ikzelf zet in de pagina gewoon precies hetzelfde formulier, maar nu met alle input types als hidden. Op deze manier is er geen enkel verschil tussen het submitten rechtstreeks vanaf het form en submitten na een preview. Het weer editen is vergelijkbaar emt wat er gebeurt als de velden niet goed worden ingevuld, met het verschil dat er nu geen foutmelding of waarschuwing oid gegeven moet worden.

zo doe ik het dus ook

[LuCarD]

Op woensdag 22 mei 2002 13:29 schreef Janoz het volgende:
Ikzelf zet in de pagina gewoon precies hetzelfde formulier, maar nu met alle input types als hidden. Op deze manier is er geen enkel verschil tussen het submitten rechtstreeks vanaf het form en submitten na een preview. Het weer editen is vergelijkbaar emt wat er gebeurt als de velden niet goed worden ingevuld, met het verschil dat er nu geen foutmelding of waarschuwing oid gegeven moet worden.

Wat nou als de data teveel is om door te sturen?
In mijn voorbeeld. Inschrijf formulier voor waterpolo toernooi.

Een Club kan zich inschrijven.
- Kan meerdere contact personen opgeven
- Kan meerdere teams inschrijven
- Kan meerdere scheidsrechters opgeven

Alle gegevens moeten volledig worden ingevuld anders heb je helemaal nix aan de data. Dus als een persoon halverwege stopt heb je nix aan de data. Zou jij dat dan via post vars door geven? niet echt handig.... lijkt me...

[Janoz]

Op woensdag 22 mei 2002 13:38 schreef LuCarD het volgende:

[..]

Wat nou als de data teveel is om door te sturen?
In mijn voorbeeld. Inschrijf formulier voor waterpolo toernooi.

Een Club kan zich inschrijven.
- Kan meerdere contact personen opgeven
- Kan meerdere teams inschrijven
- Kan meerdere scheidsrechters opgeven

Alle gegevens moeten volledig worden ingevuld anders heb je helemaal nix aan de data. Dus als een persoon halverwege stopt heb je nix aan de data. Zou jij dat dan via post vars door geven? niet echt handig.... lijkt me...

Het is natuurlijk ook een afweging. Het geval wat jij noemt is heel wat anders dan een newssubmitsysteempje ..

Bovenstaand voorbeeld zou ik persoonlijk oplossen door dit te verspreiden over meerdere formulieren. contactpersonen, scheidsrechters en teams horen allemaal in apparte tabellen. Een gebruiker moet als eerste zijn club inschrijven en kan vervolgens mbv een configuratie/profile/manager pagina teams/scheidsrechters/contactpersonen toevoegen. Voor elk van deze drie is er een appart formulier.

De gegevens uit deze formulieren gaan rechtstreeks de DB in, en niet in een sessie.

PS Ik zou zelf trouwens voor 1 contactpersoon kiezen. Het principe contactpersoon is juist bedoeld dat je 1 aanspreekpunt hebt waneer je iets wilt regelen en dat deze contactpersoon dit vervolgens in behandeling neemt, of je doorverwijst naar de verantwoordelijke.

[TheDane]

ehm, sessie variables hebben toch een maximale lengte?
wat nou als je een newsitem oid post, met daarin meer karakters dan er in de sessie variable passen?

dan gaat 't dus mis i presume ., opzich geinig idee, maar imho een beetje verkrachting van de mogelijkheden. (sessie is niet bedoeld om dergelijke data op te slaan i'd say ..

[LuCarD]

Op woensdag 22 mei 2002 14:03 schreef Janoz het volgende:

[..]

Het is natuurlijk ook een afweging. Het geval wat jij noemt is heel wat anders dan een newssubmitsysteempje ..

Echt

Bovenstaand voorbeeld zou ik persoonlijk oplossen door dit te verspreiden over meerdere formulieren. contactpersonen, scheidsrechters en teams horen allemaal in apparte tabellen. Een gebruiker moet als eerste zijn club inschrijven en kan vervolgens mbv een configuratie/profile/manager pagina teams/scheidsrechters/contactpersonen toevoegen. Voor elk van deze drie is er een appart formulier.

Het zijn ook drie verschillende pagina's, maar zonder dat alle gegevens zijn ingevuld dan zijn de andere gegevens niks waard...

En als dus een persoon midden in het invullen toch besluit om te wachten of het niet te doen, dan krijg je dus fouten in je DB (incomplete data)

De gegevens uit deze formulieren gaan rechtstreeks de DB in, en niet in een sessie.

PS Ik zou zelf trouwens voor 1 contactpersoon kiezen. Het principe contactpersoon is juist bedoeld dat je 1 aanspreekpunt hebt waneer je iets wilt regelen en dat deze contactpersoon dit vervolgens in behandeling neemt, of je doorverwijst naar de verantwoordelijke.

Aanvoerders zijn ook handig om te weten.....

[Janoz]

Op woensdag 22 mei 2002 14:08 schreef LuCarD het volgende:
Het zijn ook drie verschillende pagina's, maar zonder dat alle gegevens zijn ingevuld dan zijn de andere gegevens niks waard...

En als dus een persoon midden in het invullen toch besluit om te wachten of het niet te doen, dan krijg je dus fouten in je DB (incomplete data)

die incomplete data is niet zo'n heel groot probleem. De data klopt op zich wel, want er word alleen een nieuw record toegevoegd waneer een heel formulier ingevuld is, maar het kan natuurlijk voorkomen dat een club geen teams/scheidsrechters heeft opgegeven.

Deze dingen kun je echter heel simpel afvangen. Met een paar simpele queries kun je achterhalen hoeveel teams er al opgegeven zijn ed. Desnoods zet je op de managment pagina een melding als "Jullie inschrijving is nog niet geldig omdat jullie nog x scheidsrechters beschikbaar moeten stellen" of "Je mag maximaal met y teams meedoen"

Daarnaast bied je mensen de mogelijkheid om de volgende dag nog een team toe te voegen of eventueel weg te laten.

Voeg tot slot een deadline toe en eventueel een knop waarmee gebruikers hun inschrijving zelf kunnen locken en klaar.

[..]

Aanvoerders zijn ook handig om te weten.....

Een aanvoerder vind ik persoonlijk iets anders dan een contactpersoon van de hele club. Mischien niet IRL, maar wel in een DB.

[victorv]

Niet zelf maken. http://www.Xoops.org

[LuCarD]

Op woensdag 22 mei 2002 14:20 schreef Janoz het volgende:

[..]

die incomplete data is niet zo'n heel groot probleem. De data klopt op zich wel, want er word alleen een nieuw record toegevoegd waneer een heel formulier ingevuld is, maar het kan natuurlijk voorkomen dat een club geen teams/scheidsrechters heeft opgegeven.

Eens...

Deze dingen kun je echter heel simpel afvangen. Met een paar simpele queries kun je achterhalen hoeveel teams er al opgegeven zijn ed. Desnoods zet je op de managment pagina een melding als "Jullie inschrijving is nog niet geldig omdat jullie nog x scheidsrechters beschikbaar moeten stellen" of "Je mag maximaal met y teams meedoen"

Had een optie geweest... hmmmm ...

Daarnaast bied je mensen de mogelijkheid om de volgende dag nog een team toe te voegen of eventueel weg te laten.

De data word in de database geladen, wat weerhoud mij om die zelfde gegevens de andere kant op te laden? Dus vanuit database naar de sessie toe

Voeg tot slot een deadline toe en eventueel een knop waarmee gebruikers hun inschrijving zelf kunnen locken en klaar.
[..]

Een aanvoerder vind ik persoonlijk iets anders dan een contactpersoon van de hele club. Mischien niet IRL, maar wel in een DB.

Was een keuze/verzoek van de persoon die het toernooi organiseerde. En als het gemakkelijk kan waarom zou je dan commetaar geven?

[LuCarD]

Op woensdag 22 mei 2002 14:23 schreef Sonii het volgende:
Niet zelf maken. http://www.Xoops.org

Wat heeft dit te maken met het onderwerp?

[Janoz]

Hieruit blijkt maar weer dat er meerdere wegen naar Rome leiden.

[LuCarD]

Op woensdag 22 mei 2002 14:32 schreef Janoz het volgende:
Hieruit blijkt maar weer dat er meerdere wegen naar Rome leiden.

Tja maar de een is van kinderkopjes en de ander is ZOAB

[kaandorp]

Op woensdag 22 mei 2002 13:29 schreef Janoz het volgende:
Ikzelf zet in de pagina gewoon precies hetzelfde formulier, maar nu met alle input types als hidden. Op deze manier is er geen enkel verschil tussen het submitten rechtstreeks vanaf het form en submitten na een preview. Het weer editen is vergelijkbaar emt wat er gebeurt als de velden niet goed worden ingevuld, met het verschil dat er nu geen foutmelding of waarschuwing oid gegeven moet worden.

Dus zodra er op edit gedrukt wordt post je al die hidden vars naar de edit page en vang je weer af met $_post[var]?

Zou dit een betere optie zijn als hoe ik het doe?

[kaandorp]

Heb nog een probleempje ontdekt. Als ik het doe met hiddens i.p.v. sessions krijg je als je bijvoorbeeld een nieuwsitem hebt een compleet nieuwsitem met opmaak etc. in je source te staan. En dat wil je natuurlijk niet.