set custom data in table depending on dynamic option list

[Atochex]

Hi everybody,

I must say that xataface is the slickest code I have seen so far. Great job.

I have developed a DB-driven site engine and am trying to use xataface for the admin part of it. I have a table field 'block_page' that will determine on what page a particular block should be displayed. Now the problem is that this field can hold 'pagename', 'all', or '_DISABLED_pagename'. 'Pagename' would be the name of the page the block should be displayed on, 'all' would mean it would display the content block on every page and '_DISABLED_pagename' would exclude this block on a particular page.

I have also a table called 'pages' and set up in the fields.ini for this table the drop-down to chose a page from the list.

Code: Select all

entry in fields.ini
[block_page]
widget:label = "Page Name"
widget:description = "Select the Page you want the Block to be displayed on"
widget:type = select
vocabulary = Pages

entry in valuelists.ini
[Pages]
__sql__ = "SELECT page_name FROM Pages ORDER BY page_name"


I was wondering how could I add another checkbox field 'display' to the form so that depending on the field 'display' the data in the field 'block_page' would show either 'pagename' or '_DISABLED_pagename'. Also how could I add the selection 'all' to the drop-down without having to add a page called 'all' to the 'Pages' table.

I apologize if that might sound a bit confusing.

I would greatly appreciate any help with this matter.

Thank you very much.

Chris

[shannah]

Hi Chris,

I was wondering how could I add another checkbox field 'display' to the form so that depending on the field 'display' the data in the field 'block_page' would show either 'pagename' or '_DISABLED_pagename'.

First, I'm guessing you would like to keep the strategy unchanged for specifying which is disabled and which is not. E.g. my initial question would be "why not keep the pagename and disabled/enabled values in separate fields?" I.e. add a boolean (tinyint) column named 'disabled'. Then the pagename field would hold only the tablename.

Assuming you need to stick with your convention of '_DISABLED_pagename', you can accomplish this by adding a column to your table called 'disabled', and then implementing a beforeSave() trigger to adjust the pagename field accordingly.

e.g.

Code: Select all

function beforeSave(&$record){
    if ( $record->val('disabled') ){
        if ( !preg_match('/^_DISABLED_/', $record->val('pagename') ){
            $record->setValue('pagename', '_DISABLED_'.$record->val('pagename'));
    } else {
        $record->setValue('pagename', preg_replace('/^_DISABLED_/','',$record->val('pagename'));
    }
}


However... it occurs to me that you may have problems reloading the form as the select list for pagename won't be matching up to the proper table name.

hmmm..

Any chance you can go for the first option, and just store the disabled info separate from the tablename?

Also how could I add the selection 'all' to the drop-down without having to add a page called 'all' to the 'Pages' table.

If I recall, you can mix __sql__ with static valuelist directives.

hence, in your valueslists.ini file:

Code: Select all

[Tables]
    all=All
    __sql__ = "select * from ....."


-Steve

[Atochex]

Steve,

thank you very much for your prompt response. I am very impressed with what you got going here. All the respect!

Yeah, I could store disabled info in a separate field. Have to restructure the site engine though.

You say that you can mix __sql__ with static valuelist directives? That's awesome. I will give it a try right away.

Thanks again

Chris

[Atochex]

E.g. my initial question would be "why not keep the pagename and disabled/enabled values in separate fields?"

The reason I would like to keep different entries for the "pagename" field is that since a block can be

disabled for all pages - simple by setting __DISABLED__ for the page name,
disabled for a particular page - __DISABLED__pagename for the page name,
enabled on all pages by setting 'All' for page name,
enabled for a particular page with just "pagename",

it is very convenient and a simple method by only dealing with one field for "pagename".

Adding another table field like 'display' - on/off would still require me to set the pagename and also it would be hard to know when a block is disabled for all pages OR a particular page and when disabled for all pages OR a particular page, unless I add another entry for 'display' like on/on-all/off/off-all, but still that requires me to choose a page name even though I might not need to set a particular page name since it might be disabled/enabled for "All" pages, therefore no need for a page name.

Does this make sense?

Thanks.

[shannah]

The logical way of solving the problem of having 2 pieces of information in a single field is to normalize the data. At least to the point where you can work with it.

The first step of normalization would be to split the 2 fields (disabled and pagename) into their own fields.

The logical meaning of this separation would be that:
a) disabled is checked and pagename is selected => the block is disabled for that page
b) disabled is checked and no pagename is selected => the block is disabled for all pages
c) disabled is unchecked and a pagename is selected => the block is enabled for that page
d) disabled is checked and no pagename is selected => the block is enabled for all pages.

Hence separating the information into separate fields does not increase complexity (no need for all/off/off-all fields).

If you wish to continue with the composite field (disabled and pagename in one column), and you want to have a select list for pagename, your valuelist will need to contain all possible {'__DISABLED__',''} pagename combinations.

Hence for each page the valuelist will need to have an entry for pagename and __DISABLED__pagename.

You can do this by defining the valuelist in the delegate class.

You could easily add a checkbox for disabled that would jump between the currently selected page and its corresponding disabled entry by overriding the before_pagename_widget block, and adding a little bit of javascript magic.

The down side of this would be that your valuelist would be longer and uglier.

Of course you could also use javascript to filter this list down on the edit form so the user doesn't see the ugly bit.

Best regards

Steve