{5} Assigned, Active Tickets by Owner (Full Description) (26 matches)

In a dao, if you have an "insertpattern" on a PK and on a regular field, this leads to a notice (Trying to get property of non-object) on insert().

This is due to a SELECT generated to get the value of insertpattern'ed regular field (this request does not return anything as there is a WHERE clause on PK, and insertpattern'ed PK's value is not known).

This SELECT request is not generated if a PK has an insertpattern and regular fields does not. I guess we should have a system to get the value in those cases too.

To my point of view, the only way to solve the problem (keeping current functionnalities) would be to make a dummy request (e.g. "SELECT NOW()" in MySQL) to get PK insertpattern'ed value(s), then use those values on the INSERT and, if needed, in the SELECT's WHERE-clause.

(necessite ImageMagick?)

Je pense qu'il serait interessant de pouvoir transformer un svg en jpeg ou en png grâce à la classe jImagemodifier.

Dans ce cas, il faudra peut-être au moins compléter la documentation de la balise image.

Je me lance ?

Bonjour,

Dans jForms, par exemple, il n'est pas possible d'appliqué un trim() automatiquement. Exemple:

J'ai un simple jForms:

<input ref="nom" type="string" required="true">
    <label>Nom</label>
</input>

<input ref="prenom" type="string">
    <label>Prénom</label>
</input>

Seul le nom est requis, dans ce cas là pas de problème, mais le prénom est à choix, et si le visiteur tape " abcde", alors ma variable contiendra aussi " abcde", je suis obligé de faire un trim() à la main pour obtenir "abcde".

Je pense à un nouvel attribut du style trim="true/false/ltrim/rtrim" dans jForms

On pourrais aussi penser à un nouvel attribut du genre "xss_clean" qui applique automatiquement un htmlspecialchars

Un peu comme dans Codeigniter =>  http://codeigniter.com/user_guide/libraries/form_validation.html#preppingdata je trouve cette fonction pas mal.

Qu'en pensez-vous?

...either you would have to upload the file every time you submit the form in update context...

patch:  https://bitbucket.org/julieni/jelix-trunk-patches/src/128b1c3f30f5/jForms-empty-uploads-should-not-replace-existing-values-in-dao.patch

patch is here:  https://bitbucket.org/julieni/jelix-trunk-patches/src/128b1c3f30f5/jForms-dynamic-fill-with-class-datasource.patch

Current behaviors of URL engine should be improved.

The current simple url engine does not make sens any more and simple and basic significant engine are difficult to configure.

We should have only one URL engine, based on the current significant url engine. So we could remove the support of driver in jUrl. However, we could provide another kind of drivers, allowing to choice how urls informations are stored: in a php file like today, or a sql database etc...

In urls.xml, we should have a way to have simple url like for the basic url engine.

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.

The objective is to generate a such jDAO query on a MySQL database (example) :

DELETE table1 FROM table1 LEFT JOIN table2 ON (table1.fk = table2.id) WHERE table1.critere = 1

AND table2.autre IS NULL

see:  http://jelix.org/forums/forum/5-jelix-utilisation-et-developpement/posts/9690-9072-resolu-jdao-condition-sur-une-property-issue-d-une-optionalforeigntable

patch:  https://bitbucket.org/julieni/jelix-trunk-patches/src/128b1c3f30f5/jForms-choice-should-be-allowed-in-group.patch

Sometimes, in a form, we need to duplicate some fields dynamically. A typical example is to have upload fields to attach a file to an article. The number of this field depends of the need of the user, so there are some buttons to add dynamically a new upload field, or to remove an upload field.

<repeat> could bring this feature. Example:

<repeat ref="uploadedfile" min="1" max="5" count="3"
        addlabel="Add a new file" removelabel="remove this file">
   <label>...</label>
   <input ref="filelabel"><label>title for the file</label></input>
   <upload ref="file"><label>the file to upload</label></input>
   <!-- <datasource dao="".../> -->
</repeat>

the input and the upload elements will be repeated 3 times. But if we indicate a datasource element, there will have as many input/upload files as records given by the datasource.

the uplodadedfile data will be an array with data of each input/upload "lines".

To have a better handling of submit buttons (because of the bug in ie6, see ticket #431), we can use an array as a name :

<input type="submit" name="cmd[commande_A]" value="Commande A"> <input type="submit" name="cmd[commande_B]" value="Commande B"> <input type="submit" name="cmd[commande_C]" value="Commande C">

So we can know which submit button has been clicked, without to check the value.

Il est actuellement impossible de créer des groupes de niveau supérieur à 1 dans un jForm.

I think we should use this UI to display errors and maybe other things...