Skip to content

Form type 'phpcr_document' not resolving uuid/identifier to document #147

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
koemeet opened this issue May 8, 2014 · 8 comments
Closed

Comments

@koemeet
Copy link

koemeet commented May 8, 2014

Hi,

When I use the form type phpcr_document and POST a documents identifier/uuid, it won't resolve correctly. If I use the full path of the node, the data model that comes out of the form is populated correctly. Also DocumentToPathTransformer.php seems not to be used at all, isn't it supposed to use this transformer?

This is how I use the form type:

// ...FormType::buildForm
->add('category', 'phpcr_document', array(
    'class' => 'Mango\CoreDomainBundle\Document\Category',
    'property' => 'name'
))

So, when I provide the path of the document it is resolved just fine. But when I want to use the identifier/uuid of the document, it won't resolve it correctly.

Is this a bug or am I using this incorrectly?

Note: I've read that you guys preferred using path over a uuid, but I can't use the path in my system. The uuid is much more convenient. That's why I use the uuid instead of using the documents path as id.

@koemeet koemeet changed the title Form type 'phpcr_document' not resolving uuid's (identifier) Form type 'phpcr_document' not resolving uuid/identifier to document May 8, 2014
@dbu
Copy link
Member

dbu commented May 9, 2014

i think the document type that works with uuid is phpcr_odm_reference_collection - we deprecated it in favor of phpcr_document because they are almost the same. the only difference is that we are missing #103 - if you have experience with the form layer and see how we could fix this, that would be much appreciated. otherwise you could try to use the phpcr_odm_reference_collection type.

@koemeet
Copy link
Author

koemeet commented May 9, 2014

I guess I cannot use phpcr_odm_reference_collection, because this returns PHPCR nodes rather than documents. I will try to find a way to achieve this with the phpcr_document form type.

@koemeet
Copy link
Author

koemeet commented May 9, 2014

I've got the following, which is working fine for me, but it does not solve the problem stated above. When I use the parent choice the data transformer is ignored, so it's not a full solution.

class PhpcrDocumentType extends AbstractType
{
    protected $dm;

    /**
     * @param DocumentManager $documentManager
     */
    public function __construct(DocumentManager $documentManager)
    {
        $this->dm = $documentManager;
    }

    public function buildForm(FormBuilderInterface $formBuilder, array $options)
    {
        $transformer = new DocumentToPathTransformer($this->dm);
        $formBuilder->addModelTransformer($transformer);
    }

    public function getParent()
    {
        return 'text'; // choice is not working correctly, so I use text as parent
    }

    /**
     * Returns the name of this type.
     *
     * @return string The name of this type
     */
    public function getName()
    {
        return 'mango_phpcr_document';
    }
} 

@dbu
Copy link
Member

dbu commented May 9, 2014

the phpcr_odm_reference_collection should operate on documents, not on phpcr nodes.

but if you have an idea how we can fix phpcr_document to work that way, please do a PR, would love to have it working.

@koemeet
Copy link
Author

koemeet commented May 12, 2014

I do not have very much spare time. But I think I can roll something out this week.

@dbu
Copy link
Member

dbu commented May 12, 2014

no worries, asking people if they want to do something is just my way of
saying i don't have any plans to address the feature. if you find time,
would be great ;-)

@dbu
Copy link
Member

dbu commented Aug 9, 2014

@steffenbrem did you look into this? we are wrapping up for the next release. if you can do a PR this week, it could still make it in.

ftr: this is a duplicate of #103

@lsmith77
Copy link
Member

closing as duplicate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants