developer.jelix.org is not used any more and exists only for history. Post new tickets on the Github account.
developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.

Opened 10 years ago

Last modified 9 years ago

#1071 assigned enhancement

jForms : add methods to the API to help manage reference count introduced in #876 fix

Reported by: bricet Owned by: laurentj
Priority: normal Milestone:
Component: jelix:forms Version: trunk
Severity: normal Keywords:
Cc: Blocked By: #272
Blocking: Documentation needed: no
Hosting Provider: Php version:

Description (last modified by laurentj)

Since #876 fix, jForms now have an internal counter to manage multiple create without any delete. This could happen, for example, if a user opens several browser windows/tabs of the same Jelix page. What is expected from the user is to be able to use whatever window/tab he wants, may be several if your application can handle with that.

So the use of JForms in that case is quite different.

For exemple, to avoid data overlap between several windows/tabs, you may want to clear() a jForm after making a fill() (if entered data is not accepted by your app). Destroy() only decrements the counter. You may want to destroy all instances, so add a destroyAllInstances(). You may also want to know how many instances of a form where created with getInstancesCount().

There is also a clean() method which exists but is not documented, as far as I know.

With those 3 additional methods, you could use jForms as is :

  • prepare : create() a jForms, whatever get() is (you may test getInstancesCount() if you want to avoid to many creations). Multiple create() on a given selector won't bloat $_SESSION since it just increments a counter. You may clean() before create() to remove old instances.
  • show : if you need to, setData() to some fields, fetch() your template assigning him the form and then clear() the form. This prevents multiple jForms data overlap
  • save : fill() your form. If there are data errors, clear() it and redirect to show(). If everything is OK, store your data or whatever you have to do with them, clear() your jForms and go to "end"
  • end : destroy() your jForms

In some place of your code, for example when a user connects, you can call destroyAllInstances() - with no args - to make sure all instances of all forms are destroyed.

Attachments (1)

ticket_1071.diff (3.6 KB) - added by bricet 10 years ago.
Patch to introduced 3 new methods

Download all attachments as: .zip

Change History (6)

Changed 10 years ago by bricet

Patch to introduced 3 new methods

comment:1 Changed 10 years ago by laurentj

  • Milestone set to Jelix 1.2

comment:2 follow-up: Changed 10 years ago by laurentj

  • Description modified (diff)
  • Milestone Jelix 1.2 deleted

you may want to clear() a jForm after making a fill() (if entered data is not accepted by your app).

Why doing a clear ? If you clear the form when there is an error, so the user loose all values he typed. Not very cool.

And I don't see when data are overlaped, with or without clear(). Because on each tab, when you submit, then you call fill(), and fill() overwrite data in the container in the session. So, what is the problem ?

destroyAllInstances(): why not..

getInstancesCount(): why not, but I think it is useless. jForms is designed to not manage ourselves instances... So what is the use case of this method ? Give me an example please.

comment:3 in reply to: ↑ 2 Changed 10 years ago by bricet

Replying to laurentj:

you may want to clear() a jForm after making a fill() (if entered data is not accepted by your app).

Why doing a clear ? If you clear the form when there is an error, so the user loose all values he typed. Not very cool.

You won't loose your data. If there is an error, you will do a POST, and then have a fill(), and then get your data.

Nevertheless, there is a trouble : reload a page having a pre-filled form (e.g. modify an account). => you will loose prefiled data and get an empty form. I admit (and now that I use this patch, I claim) that this solution is not as convinient as it should be ..

And I don't see when data are overlaped, with or without clear(). Because on each tab, when you submit, then you call fill(), and fill() overwrite data in the container in the session. So, what is the problem ?

I do not remember exactly the kind of problem for now. But one problem is the same as the previous one, but it seems to me that the behaviour results to more problems :

  • open 2 tabs
  • fill first one with errors and submit it
  • reload on second tab -> filled with first tab data

getInstancesCount(): why not, but I think it is useless. jForms is designed to not manage ourselves instances... So what is the use case of this method ? Give me an example please.

I admit that it shouldn't have a main purpose use. The only case in which it could be usefull is to limit the number of instances. An other way to deal with it could be in the create(). Don't know which way is the less worth ;)

As a conclusion of that patch, I think the way I did it was just a short term basis way to solve my problems. But this is too complex to use and there are drawbacks which could be considered as bugs.

May be we should consider having several real instances (an instance would correspond to a single token and a single data storage associated to that token) for each form. Not just a counter. This should avoid complex clear(), etc.

But this could lead to kind of DOS troubles. So a limit of instances should be introduced too, IMHO.

And there may be yet better and smarter solutions too ...

comment:4 Changed 9 years ago by laurentj

  • Owner set to laurentj
  • review review? deleted
  • Status changed from new to reviewing

comment:5 Changed 9 years ago by laurentj

  • Blocked By 272 added
  • Status changed from reviewing to assigned

I don't like very much this additionnal api. We should rework jforms internal, as proposed into ticket #272. See wiki:rfc/jforms-storage

Note: See TracTickets for help on using tickets.