Could not load type "virtual_filter"

[ksn135]

I've tried to set filterable attribute to true on "virtual column" fullName.
In my entity I have fields for firstName, lastName and patronymic.
I have function getFullName() thats return string with all tree fields combined.
So, the question is: does it currently not supported or what am I doing wrong ?

[sescandell]

Hi @ksn135

I would say this is "normal" as we should not be able to guess on what fields you want to apply filters.

So, I think we can easily imagine a way to authorize "filters on virtual fields" (forcing developers to implement given method for example)... but this is so a kind of improvement.
That would be great actually... just have to think about it a little.

Maybe @loostro who works a lot lately on filters can provide us some clues on that question

[sescandell]

By the way, did you defined the dbType param to your virtual column?

[ksn135]

No, I just set filterType: ~ and it helps me to move on. )

[sescandell]

ok... sorry... I don't remember how it is working, and loostro changed all of this recently...
Let's wait for its feedbacks otherwise, I'll try to dive into the code looking for something

[ksn135]

I'm already dive too deeply into the code. Almost done! )

[ksn135]

Ta-da! Problem solved.
generator.yml

        fullName:
            filterable:    true
            filterType:    ~
            filterOn:      fuckin'.magick 

And add function to ListController class to actually filter rows:

    protected function filterFullName($queryFilter, $value)
    {
        $qb = $queryFilter->getQuery();
        $orx = $qb->expr()->orX();
        $term = $qb->expr()->literal('%'.$value.'%');
        $orx->add($qb->expr()->like("q.familyName", $term));
        $orx->add($qb->expr()->like("q.givenName", $term));
        $orx->add($qb->expr()->like("q.patronymic", $term));
        $qb->andWhere($orx);    
    }

Thank you all for your attention!

[sescandell]

Hi @ksn135

I think

filterOn:      fuckin'.magick 

Is like a "hack" of the system. As you can see in the view template, this is done to handle filters on "sub-entity" field (for exemple in a blog post model, to filter on author's name thanks to the field author.name).
Your sample is working... yes, but, IMHO, this is a "hack".

I really think we should handle "virtual_filters" by the same way (generating a function into the list controller), but without to have to distorde the generator file with awesome useless and invalid configuration (as the filterOn here).

What do you think?

[ksn135]

Yes, it's a bit of a hack. Right now I need to move on, customer is siting on my neck )
But you absolutely right, we should add special configuration parameter to document this behaviour.
I don't know how to name it. May be filterBy: {{ function name }} or filterManual: true ?

[sescandell]

I think we can simply check the filterType provided here by guessers (Doctrine ORM, Doctrine ODM and Propel) and manage this case.

[ksn135]

So, if filterType: ~ then do "some magic" ? )

[sescandell]

Actually, for now, if filterType is null, it fallbacks to the dbType. And if the dbType is virtual, it simply say "virtual_filter".

So I'm not sure filterType is null is enough... I don't know... It requires to have a better look to that part, but yes, that's the main idea.

[ksn135]

Yeah, I see. Better add a new configuration parameter or just use my hack... )))

[ksn135]

BTW, can't solve another problem, any suggestions?
http://stackoverflow.com/questions/27114146/how-to-setup-optional-date-field

[sescandell]

Waiting for stack overflow edit validation

I just created the following sample app:

 generator: admingenerator.generator.doctrine
params:
    model: Application\CoreBundle\Entity\Account
    namespace_prefix: Application
    concurrency_lock: ~
    bundle_name: AdminBundle
    pk_requirement: ~
    fields:
        id:
            filterable: 1
        name:
            filterable: 1
        expirationDate:
            formType:    s2a_date_picker
    object_actions:
        delete: ~
    batch_actions:
        delete: ~
builders:
    list:
        params:
            title: List for AdminBundle
            display: ~
            filters: ~
            actions:
                new: ~
            object_actions:
                edit: ~
                delete: ~
    excel:
        params: ~
        filename: ~
        filetype: ~
    new:
        params:
            title: New object for AdminBundle
            display:
                - name
                - expirationDate
            actions:
                save: ~
                list: ~
    edit:
        params:
            title: "You're editing the object \"%object%\"|{ %object%: Account.name }|"
            display:
                - name
                - expirationDate
            actions:
                save: ~
                list: ~
    show:
        params:
            title: "You're viewing the object \"%object%\"|{ %object%: Account.name }|"
            display: ~
            actions:
                list: ~
                new: ~
    actions:
        params:
            object_actions:
                delete: ~
            batch_actions:
                delete: ~

With this entity mapping:

 Application\CoreBundle\Entity\Account:
type: entity
table: null
id:
    id:
        type: integer
        id: true
        generator:
            strategy: AUTO
fields:
    name:
        type: string
        length: 255
    expirationDate:
        type: datetime
        nullable: true
lifecycleCallbacks: {  }

And of course, just in case, the entity:

 <?php

namespace Application\CoreBundle\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * Account
 */
class Account
{
    /**
     * @var integer
     */
    private $id;

    /**
     * @var string
     */
    private $name;

    /**
     * @var \DateTime
     */
    private $expirationDate = null;


    /**
     * Get id
     *
     * @return integer 
     */
    public function getId()
    {
        return $this->id;
    }

    /**
     * Set name
     *
     * @param string $name
     * @return Account
     */
    public function setName($name)
    {
        $this->name = $name;

        return $this;
    }

    /**
     * Get name
     *
     * @return string 
     */
    public function getName()
    {
        return $this->name;
    }

    /**
     * @param \DateTime $expirationDate
     * @return $this
     */
    public function setExpirationDate(\DateTime $expirationDate = null)
    {
        $this->expirationDate = $expirationDate;

        return $this;
    }

    /**
     * @return \DateTime
     */
    public function getExpirationDate()
    {
        return $this->expirationDate;
    }
}

And no specific customization on my entity neither my admin config or anything else... and it works well.

Does it helped you? Are you doing something specific in your application?

[ksn135]

The differences is only one. You set field type to datetime. Can you change type to date in your test application ?
In my case when you create entity and leave this field empty, after save it will become filled with current date.
When you try to clear the field and save the form, validation error occurs "Invalid Date".
So, I understand your proposal, to convert my field to datetime. It'll try tomorrow.
Thanks for advice!

[sescandell]

I've made exactly the same test / application changing the type to date and it's still working.

[ksn135]

I've just added Gedmo Timestampable and Blameable behavior to my entity and now it's work.
Before:

--
-- Table structure for table `news_item`
--

CREATE TABLE `news_item` (
`id` int(11) NOT NULL,
  `title` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `content` longtext COLLATE utf8_unicode_ci NOT NULL,
  `image_path` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `version` int(11) NOT NULL DEFAULT '1',
  `publishedAt` datetime DEFAULT NULL
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=2 ;

After addition:

CREATE TABLE `news_item` (
`id` int(11) NOT NULL,
  `title` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `content` longtext COLLATE utf8_unicode_ci NOT NULL,
  `image_path` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `version` int(11) NOT NULL DEFAULT '1',
  `publishedAt` datetime DEFAULT NULL,
  `createdBy` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `updatedBy` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `createdAt` datetime NOT NULL,
  `updatedAt` datetime NOT NULL
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=4 ;

It's very strange, but you can see below, I'm not insane:

--
-- Dumping data for table `news_item`
--
INSERT INTO `news_item` (`id`, `title`, `content`, `image_path`, `version`, `publishedAt`, `createdBy`, `updatedBy`, `createdAt`, `updatedAt`) VALUES
(1, 'hgjhgjhg', 'bjhjkhgkjgkjhgjkgkjh', NULL, 1, '2014-11-28 00:00:00', NULL, NULL, '0000-00-00 00:00:00', '0000-00-00 00:00:00'),
(2, '12123123', '1231231231232', NULL, 1, '2014-11-28 00:00:00', NULL, NULL, '0000-00-00 00:00:00', '0000-00-00 00:00:00'),
(3, '11', '222', NULL, 1, NULL, 'ksn135', 'ksn135', '2014-11-28 11:40:51', '2014-11-28 11:40:51');

Did you see thouse strange values "0000-00-00 00:00:00" ? Before last schema update new entities gots this values into empty publishedAt field on save. And on first edit action publishedAt field automaticaly recieve current date as it "saved" value.
Problem solved and I can't reproduce it.
Thank you!