Usage of "checkboxes" field type

[Stjepan]

Does anyone have any expirience with using checkboxes (not checkbox) field type in development of Joomla components in backend?

What i ahve now is in form XML:

<field
   name="team_ids"
   type="checkboxes"
   label="Team"
   description="Select one more more teams in which this user is member">
   <option value="1">One</option>
   <option value="2">Two</option>
   <option value="3">Three</option>
</field>

It renders nicely in view using this piece of code:

....
<li>
   <?php echo $this->form->getLabel('user_id'); ?>
   <?php echo $this->form->getInput('user_id'); ?>
</li>
...


My question is, what type should be clumn in database that can store information about which checkbox is selected and which is not?

I googled alot for this answer but i couldnt find anything about it anywhere...

[Bruno Batista]

Easy :)

>> First Step: Create a Field

<?php
// No direct access to this file
defined('_JEXEC') or die();

// import the list field type
jimport('joomla.form.helper');
JFormHelper::loadFieldClass('list');

class JFormFieldInterest extends JFormField
{

/**
* The form field type.
*/
protected $type = 'Interest';

/**
* Method to get the field options.
*/
public function getInput ($data = 0)
{
static $count;
$count ++;

// Initialize variables.
$name = $this->name;
$selected = explode(',', $this->form->getValue('interest'));

$db = JFactory::getDbo();
$query = $db->getQuery(true);
$query->select('a.*, COUNT(DISTINCT b.id) AS level');
$query->from($db->quoteName('#__categories') . ' AS a');
$query->join('LEFT',
$db->quoteName('#__categories') .
' AS b ON a.lft > b.lft AND a.rgt < b.rgt');
$query->where('a.extension = "com_catalog.interests"');
$query->group('a.id, a.title, a.lft, a.rgt, a.parent_id');
$query->order('a.lft ASC');
$db->setQuery($query);
$groups = $db->loadObjectList();

// Check for a database error.
if ($db->getErrorNum()) {
JError::raiseNotice(500, $db->getErrorMsg());
return null;
}

$html = array();

$html[] = '<fieldset class="checkboxes" id="jform_interest">';
$html[] = ' <ul>';

for ($i = 0, $n = count($groups); $i < $n; $i ++) {
$item = &$groups[$i];

// Setup the variable attributes.
$eid = $name . $item->id;
// Don't call in_array unless something is selected
$checked = '';
if ($selected) {
$checked = in_array($item->id, $selected) ? '
checked="checked"' : '';
}
$rel = ($item->parent_id > 0) ? ' rel="' . $count .
'group_' .
$item->parent_id . '"' : '';

// Build the HTML for the item.
$html[] = ' <li>';
$html[] = ' <input type="checkbox" name="' .
$name .
'[]" value="' . $item->id . '" id="' .
$eid . '"';
$html[] = ' ' . $checked . $rel . ' /
>';
$html[] = ' <label for="' . $eid . '">';
$html[] = ' ' . str_repeat(
'<span class="gi">|&mdash;</
span>',
$item->level - 1) . $item->title;
$html[] = ' </label>';
$html[] = ' </li>';
}

$html[] = ' </ul>';
$html[] = '</fieldset>';

return implode("\n", $html);
}

}

>> Second Step: Call the field

<field name="interest" type="interest"
label="COM_CATALOG_FIELD_INTERESTS_LABEL"
description="COM_CATALOG_FIELD_INTERESTS_DESC" />

>> Third Step: Table store function

public function store($updateNulls = false) {
if (is_array($this->interest)) {
$this->interest = implode(',', $this->interest);
}
else {
$this->interest = implode(',', array());
}
}

ENJOY

If you need more help add on skype: totalpropaganda
I from Brazil, my company: www.atomtech.com.br

[Bruno Batista]

Just use:

public function store($updateNulls = false) {
                if (is_array($this->interest)) {
                        $this-

>interest = implode(',', $this->interest);
                }
                else {
                        $this->interest = implode(',', array());
                }
}

If you put direct options...

[elin]

Text

Elin

On Thursday, April 12, 2012 9:06:

[Stjepan]

As i understand (i'm really new into creating components for Joomla) your proposal is to create custom from field and to deal with data from that field with my own version of store function?
I tought that, as Joomla had this "checkboxes" field available that it does all job by iteself just like it does with rest of predefined fields. For example, there is no need to write your own store function for text fields etc.

What i did with my limited knowledge is that i created my own store function in tables that looks like this:

public function store($updateNulls = true) {

        if (is_array($this->team_ids))
        {
            $this->team_ids = implode(',', $this->team_ids);
        }
        else
        {
            $this->team_ids = implode(',', array());
        }

        // Initialise variables.
        $k = $this->_tbl_key;

        // If a primary key exists update the object, otherwise insert it.
        if ($this->$k) {
                $stored = $this->_db->updateObject($

this->_tbl, $this, $this->_tbl_key, $updateNulls);
        } else {
                $stored = $this->_db->insertObject($this->_tbl, $this, $this->_tbl_key);
        }
 
        // If the store failed return false.
        if (!$stored) {
                $this->setError(get_class($this).'::store failed - '.$this->_db->getErrorMsg());
                return false;
        }
 
        // If the table is not set to track assets return true.
        if (!$this->_trackAssets) {
                return true;
        }
 
        if ($this->_locked) {
                $this->_unlock();
        }
 
        return true;
    }

As you can see i took 1st part from you and rest i found somewhere on internet as only your code did not do the trick.
Now, data is saved in form of a string inside database.
What i'm afraid is that i'm gonna get into more trouble later when i'm gonna have to get that data back etc....

Is there no way Joomla can deal with "checkboxes" on it's own just like with every other predefined field type?

[elin]

As the OP said, there is already a standard field type checkboxes that works fine.

There is no reason to do anything more than to save the data, either in its own field with a name matching the field name or as part of a JSON string.

It saves as an array of the checked values.

The field should be a text field.

Elin

[Karthik m]

here the type is simple that type='chk'

[Stjepan]

Hey elin...i'm trying standard field type "checkboxes" and i cant make it work. Maybe it's because i'm at this thing for more than 8 hours now and my brain is kidna hurting me so maybe i'm forgetting something obvious.

1) In models->forms i set up field as this:

<field
            name="test"
            type="checkboxes"
            label="Test"
            description="Test description">

            <option value="1">One</option>
            <option value="2">Two</option>
            <option value="3">Three</option>
        </field>

2) In view->tmpl->edit i set up as this:
...
<li>
  <?php echo $this->form->getLabel('test'); ?>
  <?php echo $this->form->getInput('test'); ?>
</li>
...
3) In database i create column :

ALTER TABLE `kjd_teammembers` ADD `test` TEXT NOT NULL




When i go into administration, click on "new" for teammabers, in "edit" form i can now see 3 checkboxes "one" "two" and "three" which is all good.
But when i save or "apply" everything else from that form is saved in database except "test" column that should have checkbox values in it.

Am i forgetting something? Am i doing something wrong?

[Matias Aguirre]

Are you created the correct table or added the 'test' field to that table?

[Matias Aguirre]

Sorry i mean, the table class located on com_example/table. Ex:

class ExampleTable extends JTable

On Friday, 13 April 2012 10:38:52 UTC-3, Stjepan wrote:

On Friday, 13 April 2012 10:38:52 UTC-3, Stjepan wrote:

[Stjepan]

Yes, i do have com_testcomponent/table/member.php
As i created this component at very start with : http://www.notwebdesign.com/joomla-component-creator/ it was created automaticly.

View part of form that i'm testing is in: com_teammanagement\views\member\tmpl\edit.php and it is working fine with for example text input.
All i had to do is declare:

 <field name="ime"
            type="text"
            label="Upisi nesto"
            description="Upisi nesto opis"
        />
inside : com_teammanagement\models\forms\member.php
and:

<li>
                    <?php echo $this->form->getLabel('ime'); ?>
                    <?php echo $this->form->getInput('ime'); ?>
                </li>
inside com_teammanagement\views\member\tmpl\edit.php
and of course creating "ime" column in that database table.
Text that i insert into "ime" textfield is saved in that table but checkboxes data  is not (of course, checkboxes are in same table but different column that's set to text data type)

[elin]

Yes I think you are right, and looking back over some older posts, I think checkboxES 
(not checkbox)  has never really worked or at least it has never been documented how to make it work.  The HTML is set up correctly but the save is failing. Usually I end up doing a bunch of checkbox fields instead of checkboxes but that too is problematic since it doesn't give the correct array.  It would be really good for someone to dig into why this is failing. 

Elin

[elin]

Ok this was bothering me and here is what I found out. 

Usually when I am trying to understand JForm I use the contact edit form since it has so many fields available. I decided to change the address field to checkboxes.

My xml was like this:

<field name="address" type="checkboxes"

label="COM_CONTACT_FIELD_INFORMATION_SUBURB_LABEL"

description="COM_CONTACT_FIELD_INFORMATION_SUBURB_DESC"

multiple="true"

>

<option  value="red">red</option>

<option  value="blue">blue</option>

</field>

When I used it as a regular field trying to save in the address field in #__contact_details it fails to save. The data are there correctly in $data but they are not saving. 

However, if I move that field into either the metadata or params fields it saves perfectly but of course inside of the JSON string.   Curious, I discovered that the same holds true for true for type="list" multiple="true".  (Just like a single checkbox a list that selects only a single item is saving fine.)

What is causing this, I don't know. But at least that might help with a work around.

Elin

[Stjepan]

Well, "workaround" is pretty easy...just create save function in "tables/yourform.php" as i wrote somewhere above that merges array that's holding checkboxes data into string and it will happily save it to text database field.

Of course, youll have to create same thing for loading that data and turning it back to array.

What i'm wondering right now is, where is "original" save function for those "regular field types" ? Maybe by looking trough it's code we can figure this out.

It's just silly how much of my free time did i loose over thing thing that IS "built in" thing and i'm just glad i'm not only one with this problem...i tought it's just me and my lack of knowledge.

[elin]

One thing that is unusual about the checkboxes field is that it produces its own fieldset

string '<fieldset id="jform_metadata_myaddress" class="checkboxes"><ul><li><input type="checkbox" id="jform_metadata_myaddress0" name="jform[metadata][myaddress][]" value="red" checked="checked"/><label for="jform_metadata_myaddress0">??red??</label></li><li><input type="checkbox" id="jform_metadata_myaddress1" name="jform[metadata][myaddress][]" value="blue"/><label for="jform_metadata_myaddress1">??blue??</label></li></ul></fieldset>' (length=431)

So I suppose that is why when we are iterating though all known fields sets the way we are in params or meta data that is getting handled.

Since checkboxes are really a set of checkbox fields with the same control (name)

http://www.w3.org/TR/html401/interact/forms.html#checkbox

this makes sense. 

 

Elin

[Sam Moffatt]

For multivalued/complex variables (in this case an array) you will
need to override the handle those entries in a mechanism that makes
sense. The reason metadata and params work is because
ContactTableContact's bind method is manipulating it for you to store
it and JModelAdmin's getItem will automatically unpack the params
field and ContactModelContact unpacks the metadata field when reading.

Cheers,

Sam Moffatt
http://pasamio.id.au

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-general/-/W_mYh9iVvooJ.
>
> To post to this group, send an email to joomla-de...@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-gene...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-general?hl=en-GB.

[elin]

Ha I was just posting to the platform list asking about the intent here. So if checkboxes as a whole and any field types with multiple="true" as an option  requires custom handling I think that should probably be in the doc blocks?

Elin

> To post to this group, send an email to joomla-dev-general@googlegroups.com.

> To unsubscribe from this group, send email to

> joomla-dev-general+unsub...@googlegroups.com.

[Sam Moffatt]

I'd thought it'd be obvious that persisting non-scalar variables is
probably non-trivial. Does it get serialised to JSON into a field? XML
into a field? New rows in a related mapping table? Depending on what
you're doing each has it's pro's and con's.

Strings and numbers are rather much straight forwards, the norm there
is easy to determine however when you're dealing with multi-valued
fields you've got to make some decisions there on how that gets
stored.

Perhaps a tutorial on how to do this with an example might be useful
to point people to documentation however this is really not a JForm
specific topic, it's really a data modelling issue relevant for people
who may not even wish to use JForm.

Cheers,

Sam Moffatt
http://pasamio.id.au

>> > joomla-de...@googlegroups.com.

>> > To unsubscribe from this group, send email to

>> > joomla-dev-gene...@googlegroups.com.

>> > For more options, visit this group at
>> > http://groups.google.com/group/joomla-dev-general?hl=en-GB.
>

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-general/-/rqiSxt1F-9EJ.
>
> To post to this group, send an email to joomla-de...@googlegroups.com.

> To unsubscribe from this group, send email to

> joomla-dev-gene...@googlegroups.com.

[Stjepan]

If they made it as default field, they should have deal with it one way or another (for example, turn array into string, store into text field, on retrieve explode into array etc.), and if developer needs something more fancier or different or better or whatever, he can always create custom save functions etc. It's just silly to make it as it's right now...ppl are using ALOT of their time just to realize it's not working as rest of fields and it needs some sort of your private custom code.

Anyway, thanks to ppl from this group i managed to create custom save funciton that deal with array data and stores it. I'm shure ill manage to create laod function that will deal with that data on retrieve.

[Sam Moffatt]

Of course a multivalued field isn't going to work the same way as a
single valued field does. Just the same as a files form field doesn't
work the same way as a single valued field as well (files are really
just another specialized version of the multiple values). We still
ship a file form field because it's useful but how you handle that is
up to you. It's isn't the job of JForm to store stuff, it's to render
a form for you and provide mechanisms for manipulating it but
fundamentally persistence is not the job of JForm.

Cheers,

Sam Moffatt
http://pasamio.id.au

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-general/-/BddQe5j5kEEJ.

[elin]

Basically, we have a list of field types. Most of them work for people making forms by saying type="xxx" name="yyy" so it's totally reasonable for people to think that you can do the same for all. If they don't we need to make that clear.  We tell people, for example, that it's easy to make or modify a form, but in this case it's not.

Right now the only simple way to handle checkboxes is to put them in a $group (<fields>) and handle in the model.  I'm not going to go into why that is and why it works when you don't explicitly load the field by name, but it does. This doesn't do anything specifically for multi select items but it does allow the data to be saved in the form it is sent, including as an array, with no additional special handling required.

As usual the problem is when two different parts have to work together, in this case JForm and the model.  So right away we know that this is going to be a problem if you are modifying a form because as of now you need to modify the model too.  If you want to use the JRegistry toArray and loadString handling as we do for params you need to set up the $group in the form. So in fact we do rely on JForm to manage part of this, not just rendering but also preparing the data for processing so that the model can handle saving to and retrieving from the json. In fact I wonder if inside the cms maybe checkboxes ought to do this as part of setting up the html and whether in the form models  it makes sense to just handle it if we find json in a field instead of having doing to it by name (the way we do for params in JModelAdmin and the individually in a lot of models). 

Elin

> To post to this group, send an email to joomla-dev-general@googlegroups.com.

> To unsubscribe from this group, send email to

> joomla-dev-general+unsub...@googlegroups.com.

[Ljudotina]

Than it should be clearly documented.
For first time Joomla component wannabe developers like myself, this
kind of things are very repulsing. If things arn't "predictable" AND not
documented (checkboxes have no documentation or examples whatsoever on
joomla docs/forum) than ppl like me think "hm, where else will i bump
into things like that?" "Should i start working on some other CMS?" Etc.
For developers, good documentation is way more important than
"features". If i knew that "checkboxes" arn't "finished (or complete in
lack of better word) feature" like "textbox" than i would not loose 3
working days and i would get my hands "dirty" and get over this issue
long time ago. It's not problem that checkboxes are not working same
"easy" and "simple" way as "textfields", problem is that that
documentation about it is lacking.

[Sam Moffatt]

On Mon, Apr 16, 2012 at 10:29 AM, Ljudotina <ljud...@gmail.com> wrote:
> Than it should be clearly documented.

Thanks for volunteering! Since you now appear to have a great grasp of
the subject, I strongly encourage you to check out
http://docs.joomla.org, sign up and create the documentation that you
feel would have helped you diagnose this situation sooner. Having just
spent three days you know all of the pitfalls and are in one of the
strongest positions to ensure that any issues or gotchas are covered
in the documentation that you write.

Look forwards to seeing your contribution.

[Sam Moffatt]

As an aside I strongly encourage you to try other CMS' as every CMS
has it's strengths and weaknesses. I particularly encourage you to
build a simple extension in each system with roughly the same features
so you can get a view as a developer as this appears to be your
interest. At the end of the day you need to pick the best tool for the
job and having options you've got experience with helps with that.

Cheers,

Sam Moffatt
http://pasamio.id.au

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.

[Ljudotina]

I see your point. "Do something about it" is something i deal with every
day.
As far as documentation goes, i dont feel like someone who knows enough
to write something that will guide everyone who end up on joomla docs
(which i suppose is alot of fresh joomla developers).
I learned that "checkboxes" feature is not working like rest of em i
used, i learned how to bypass it, but i'm not sure if i'm doing it right
way and spreading my half baken knowlage around doesnt feel good nor i'm
native english speaker which can make it even more less understandable.

But if you think that solution from this topic is good enough, and that
my english is good enough, i'll be glad to write it to joomla docs wiki.

As working with other CMS's, i'm working on whatever my clients need.
I'm not one of those that will praise one thing just bcause i like it.
Every other CMS has it's own pitfalls, payd or free, but that doesnt
make this situation better or worse. What can make one CMS better than
next one is knowlage about where pitfall is. If you know it exists and
if you know where it is, than you can plan ahead and jump over it.

Reality is that documentation about "checkboxes" is non existant and it
would feel much better if those that created it would write something
about it....even "This feture is not "finished solution" like
"textfield" feature and needs custom save/load/whatever functions (i
dont even know list of functions that should be created) to be able to
store/load data to/from database."
Even that sentence in joomla docs would save alot of people alot of
their working/free time.

As i said...if you think that that kind of submitions are OK for joomla
docs, you can expect my to add in stuff whenever i end up in dead ends
like this.

[Mark Dexter]

Hi. The great thing about the wiki is that anyone can edit and improve an article. So I would encourage you to draft an article on the wiki with your solution. You can always put in some type of text like "I'm not sure this is the best way but it is the way I have made it work.".

Other people will be free to edit your article either to fix grammar or to suggest changes to the substance.

Often times the hardest thing about adding a new article to the wiki is figuring out the title. If you have any questions about that, feel free to ask here. In this example, it could go in as an FAQ or as a Trick and Tip.

I would probably suggest an FAQ with a title like "How do you save a checkboxes field to the database?".

Thanks. Mark

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To post to this group, send an email to joomla-dev-general@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-general+unsub...@googlegroups.com.

[elin]

So overall my feeling about this and the issues we have about multiselect (including media and list with multiple = "true")  in the tracker is that 

a. We definitely need to document in the CMS that these fields and fields options within  do not work (as of now) in the same manner as other fields in JForm.

b. From the CMS perspective not saving is a bug to my mind.  

Assuming that the platform doesn't see it as a bug and wants to maintain maximum custom handling possibilities,  the CMS should decide how i it wants to save such data and implement that so that CMS developers/users will be able to just use the fields like any other fields. My feeling is that multiselect should be saved as arrays the way they currently are if you put them into the params i.e. ['red,'blue'] but as Sam said someone could make an argument for json or something else for that matter. And I would say for media we should change the required check to work as people are expecting i.e. that if a file is attached it will validate as required. Basically JForm already expects those data to be arrays so arrays make sense to me.

c. This is somewhat related and somewhat tangential, but  now that JModelAdmin doesn't have to hypothetically support any other applications, I think we should move the model's handling of the metadata json to there where we already are handling params.  But we also might want to  go further and try to provide a way to make it so that developers can use the same custom handling as the core for those instead of having to write their own.  It wouldn't handle everything because there is  some in the table also but why not simplify it anyway.

Elin

To unsubscribe from this group, send email to joomla-dev-general+unsubscribe@googlegroups.com.

[JM Simonet]

For multiple ="true", see tracker
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=28402

This patch saves values as arrays. Would have to be tested further.

JM

To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.

For more options, visit this group at

http://groups.google.com/group/joomla-dev-general?hl=en-GB.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/xMLHG2fa6vQJ.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.

-- 

Please keep the Subject wording in your answers

This e-mail and any attachments may be confidential. You must not disclose or use the information contained in this e-mail if you are not the
intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies.

-----------------------------------------------------------

Jean-Marie Simonet  /  infograf768

Joomla Production Working group

Joomla! Translation Coordination Team 

[elin]

That is NOT about saving as is explained in the discussion. That is about setting the defaults if you already have custom handling for save set up. That is related since if you decide to save as arrays you know how defaults should come in (and you can also decide about presets).  However currently if you select multiple="true" and don't provide custom handling it will not save.

I think we should also consider adding a selected element to the appropriate jform types or perhaps to jformfield itself since that would solve  one of the other most common form related issue reports we get which is that people set defaults as a way to get presets and are then surprised that if the user unselects all the defaults are saved. Maybe the platform team would go for that, I don't know, but if not we could do it.

Elin

To post to this group, send an email to joomla-dev-general@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-general+unsub...@googlegroups.com.

For more options, visit this group at

http://groups.google.com/group/joomla-dev-general?hl=en-GB.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/xMLHG2fa6vQJ.

To post to this group, send an email to joomla-dev-general@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-general+unsub...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.

[Bruno Batista]

FIELD

    <fieldset name="tires">
        <field name="tires" type="checkboxes" label="COM_CONDOS_FIELD_TIRES_LABEL" description="COM_CONDOS_FIELD_TIRES_DESC">
            <option value="1">COM_CONDOS_FIELD_TIRES_FLEFT_LABEL</option>
            <option value="2">COM_CONDOS_FIELD_TIRES_FRIGHT_LABEL</option>
            <option value="3">COM_CONDOS_FIELD_TIRES_RLEFT_LABEL</option>
            <option value="4">COM_CONDOS_FIELD_TIRES_RRIGHT_LABEL</option>
            <option value="5">COM_CONDOS_FIELD_TIRES_STEPPE_LABEL</option>
        </field>
    </fieldset>

IN THE MODEL

    /**
     * Method to get a single record.
     *
     * @return    mixed    Object on success, false on failure.
     * @since    1.6
     */
    public function getItem($pk = null)
    {
        if ($item = parent::getItem($pk)) {
            $item->tires = explode(',', $item->tires);
        }
       
        return $item;
    }

IN THE TABLE

    /**
     * Stores a Vehicle
     *
     * @param    boolean    True to update fields even if they are null.
     * @return    boolean    True on success, false on failure.
     * @since    1.6
     */
    public function store($updateNulls = false)
    {
...
...
...
        // Salve services
        if (is_array($this->tires)) {
            $this->tires = implode(',', $this->tires);
        }
        else {
            $this->tires = implode(',', array());
        }
       
        // Attempt to store the data.
        return parent::store($updateNulls);
    }

>:)

Em quinta-feira, 12 de abril de 2012 19h27min29s UTC-3, Stjepan escreveu:

Does anyone have any expirience with using checkboxes (not checkbox) field type in development of Joomla components in backend?

What i ahve now is in form XML:

<field
   name="team_ids"
   type="checkboxes"
   label="Team"
   description="Select one more more teams in which this user is member">

   <option value="1">One</option>
   <option value="2">Two</option>
   <option value="3">Three</option>
</field>

It renders nicely in view using this piece of code:

....
<li>
   <?php echo $this->form->getLabel('user_id'); ?>
   <?php echo $this->form->getInput('user_id'); ?>
</li>
...


My question is, what type should be clumn in database that can store information about which checkbox is selected and which is not?

I googled alot for this answer but i couldnt find anything about it anywhere...

[Sam Moffatt]

You're confusing the UI form rendering library (JForm) with the data
persistence layer. The problem is not that JForm doesn't understand or
deal with multivalued or complex fields correctly (e.g. checkboxes,
multiselect lists, file upload, etc) because when you feed JForm the
data the fields are rendered appropriately and JForm hands over the
data in an appropriate format (as an array) to the persistence layers.
The issue is that the data persistence layer isn't understood properly
and assumed that it should just work. There is a lack of understanding
where that border exists between form management layer (rendering,
data filtering, etc) and data persistence layer. Even if you never
used JForm and built all the HTML yourself you'd still have to do much
of the same tasks.

Perhaps the misunderstanding comes from the belief that the database
layer should be coupled to the form layer - or is in fact coupled. The
reality is that there is no coupling between the form definitions used
to render the data and the models and table structures used to persist
them.

There are examples in the system of how to persist multivalued fields
to the database. The module manager has an example of how you can use
a mapping table to persist multivalued data (module menu assignment).
The params stored throughout the system use a JSON format (previously
INI) which is also a valid way to store data.

The problem is that there isn't a definitive way to store a
multivalued or complex field. There is really one way to store a
string or a number. I think it simply comes down to the fact that at
least on my machine when I do "echo array('pies')" I get "Array" in
response. Should the persistence layer automatically assume that if it
got an array that it should JSON encode it? How does it know which
fields it should JSON decode then? Does it sniff for it? What happens
when you store JSON then in a field that you don't want automatically
decoded for you? For example someone inputs raw JSON into the content
manager's text field then randomly com_content starts getting an
object back instead of the string it wanted. Do you then couple your
persistence layer to your form layer? This provides an interesting
question of what happens when you don't want to have a form for
whatever reason. Though a JTableForm could certainly be done where you
pass in a form definition some how (constructor?) and it then parses
the XML to determine whats multivalued or not and then persists it
using JSON serialisation but that sounds like a lot of overhead for
saving five lines of code occasionally and still doesn't solve what
happens when you need to override that behaviour anyway and store it
as CSV, XML, INI or in a distinct table.

Cheers,

Sam Moffatt
http://pasamio.id.au

>>> joomla-de...@googlegroups.com.

>>> To unsubscribe from this group, send email to

>>> joomla-dev-gene...@googlegroups.com.

>>> For more options, visit this group at
>>> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
>>>
>>

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.

> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-general/-/xMLHG2fa6vQJ.
>
> To post to this group, send an email to joomla-de...@googlegroups.com.

> To unsubscribe from this group, send email to

> joomla-dev-gene...@googlegroups.com.

[elin]

I actually do understand it.  

This is an important distinction between platform and application. There is no coupling in the platform except in JContentTable but there is coupling all over the place in the CMS. (Actually since JContent has a bunch of JSON encoded fields in the content table there must be some seamless handling there too.)

The problem is that users ... i.e. in this case people making forms ... expect that all form fields will just work. You absolutely are correct there. But that's the market for the CMS, you are not supposed to have to understand everything to do something like make a simple form in the CMS. This is a difference between the application layer and the platform layer.  We don't have a core form generator, so we do expect people to learn to use xml, but we don't expect them to know about the complexities of data persistence. 

 It's not an unreasonable expectation given that we don't tell them otherwise. So minimally we do need to document. 

Yes part of the issue is not having the JTableForm / JTableAdmin equivalent to JModelForm/JModelAdmin. The issue is not JForm, Jform renders the input properly. The problem is when it gets saved to the table and read from the table.  This requires custom handling at the moment.

So, really the CMS could make the decision, yes since JForm puts the data in an array and we're already saving it as an array when we are inside params, we are going to default to array. If a developer wants to do something different she can extend JTable herself and handle it differently. Or we could say csv or json or we could even give the option.  Like instead of multiple="multiple" multiple="array" multiple="JSON"  ... it would be a great project for someone to do that. Right now I kind of want to just get the array part working though. By the way, that's the format for multiselect in Google Forms. 

We already have the multiple boolean, but i think we could add a JSON element to say this is a field where I want to decode JSON and then we wouldn't need all the hard coded special stuff for params in JModelAdmin and JTableContent etc and metadata all over the place not to mention other situations where we are using form fields to hold JSON.

Elin

>>> joomla-dev-general@googlegroups.com.

>>> To unsubscribe from this group, send email to

>>> joomla-dev-general+unsub...@googlegroups.com.

>>> For more options, visit this group at
>>> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
>>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-general/-/xMLHG2fa6vQJ.
>

> To post to this group, send an email to joomla-dev-general@googlegroups.com.

> To unsubscribe from this group, send email to

> joomla-dev-general+unsub...@googlegroups.com.