Skip to content
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

EZP-29104: Impl. ImageAsset field type #2403

Merged
merged 4 commits into from Sep 11, 2018

Conversation

adamwojs
Copy link
Member

@adamwojs adamwojs commented Jul 25, 2018

Question Answer
JIRA issue EZP-29104
Bug/Improvement no
New feature yes
Target version master
BC breaks no
Tests pass yes
Doc needed yes

ImageAsset Field Type allows to store images in independent content items of a generic Image content type, in the media library, instead of storing them within the original content item to make then reusable accross system.

From the kernel POV its works as same as a ezobjetrelation field type.

ImageAsset Field Type configuration

ImageAsset Field Type allows to configure the following options:

Name Description Default value
content_type_identifier Content type used to store assets image
content_field_identifier Field identifier used to asset data image
name_field_identifier Field identifier used to asset name name
parent_location_id Location where the asset are created 51

Example configuration:

ezpublish:
    system:
       default:
            fieldtypes:
                ezimageasset:
                    content_type_identifier: photo
                    content_field_identifier: image
                    name_field_identifier: title
                    parent_location_id: 106

Customizing ImageAsset Field Type rendering

Internally the Image Asset Type is render via subrequest (similar to other relation types). Rendering customization is possible by configuring view type asset_image:

ezpublish:
    system:
       default:           
            content_view:
                asset_image:
                    default:
                        template: '::custom_image_asset_template.html.twig'
                        match: []

Generating image variation from the Image Asset

Thanks to the eZ\Bundle\EzPublishCoreBundle\Imagine\ImageAsset\AliasGenerator decorator it is possible to work with \eZ\Publish\SPI\Variation\VariationHandler in same way as with Image Field Type.

TODO:

  • Implement feature / fix a bug.
  • Implement tests.
  • Fix new code according to Coding Standards ($ composer fix-cs).
  • Ask for Code Review.

@ezrobot

This comment has been minimized.

@adamwojs adamwojs force-pushed the EZP-29104-imageasset_clean branch 2 times, most recently from 6cabfd0 to f131f00 Compare July 27, 2018 09:01
@adamwojs adamwojs changed the title [WIP] EZP-29104: Impl. ImageAsset field type EZP-29104: Impl. ImageAsset field type Jul 27, 2018
/**
* {@inheritdoc}
*/
public function getFieldTypeIdentifier()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can add here return type hint

return $this->innerAliasGenerator->getVariation($field, $versionInfo, $variationName, $parameters);
}

public function supportsValue(Value $value): bool
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing docblock

/**
* {@inheritdoc}
*/
public function getVariation(Field $field, VersionInfo $versionInfo, $variationName, array $parameters = [])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing return type hint

}
}

public function imageAssetSettingsProvider()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing docblock and return type hint

class AliasGeneratorTest extends TestCase
{
/**
* @var \eZ\Bundle\EzPublishCoreBundle\Imagine\ImageAsset\AliasGenerator
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we use a single line or multiline for /** @var .... */ In this PR both are used

*
* @param \eZ\Publish\Core\FieldType\ImageAsset\Value $value
*
* @return mixed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@return array?


/** @var \eZ\Publish\API\Repository\ContentService|\PHPUnit_Framework_MockObject_MockObject */
private $contentService;
/** @var \eZ\Publish\API\Repository\LocationService|\PHPUnit_Framework_MockObject_MockObject */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing empty line

}

/**
* @expectedException \eZ\Publish\API\Repository\Exceptions\InvalidArgumentException
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

$this->assertEquals($expected, $actual);
}

public function dataProviderForIsAsset(): array
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add docblock here and below (createMapper(), createPartialMapper(), createContentWithId(), createContentWithContentType()?

@@ -76,4 +88,9 @@ public function getImageVariation(Field $field, VersionInfo $versionInfo, $varia
}
}
}

public function getImageAssetContentFieldIdentifier()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing docblock and return type hint

Copy link
Member

@alongosz alongosz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sorry, but from my perspective it's impossible to review. Please at least separate implementation from tests (I mean by commits). Since we're gonna squash this, PR commits don't need to have an issue number. They need to be in past tense though.

git reset origin/master

is your friend.

@adamwojs
Copy link
Member Author

adamwojs commented Aug 2, 2018

@alongosz I split PR into two separate commits as you requested: implementation and tests

@ezrobot

This comment has been minimized.

@ezrobot

This comment has been minimized.

use eZ\Publish\Core\Base\Exceptions\InvalidArgumentException;
use eZ\Publish\Core\FieldType\Image\Value as ImageValue;

class Mapper
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please either change this name to be more meaningful or add short PhpDoc stating what this class maps.

@ezrobot

This comment has been minimized.

@adamwojs
Copy link
Member Author

adamwojs commented Aug 3, 2018

PR ready for the final code review @alongosz @mikadamczyk

*
* @return bool
*/
public function isSearchable(): bool
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method is same as in parent class, so it is redundant

Copy link
Member

@alongosz alongosz Aug 6, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method is same as in parent class, so it is redundant

I'm sorry to disagree in this case. Relying on the fact that the current implementation of FieldType base core class returns false is risky. While we probably wouldn't change it for any minor version (though there's no BC promise for Core), it's going to be difficult to track in case of major version upgrade.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @mikadamczyk

I'm sorry to disagree in this case. Relying on the fact that the current implementation of FieldType base core class returns false is risky.

Not in this case: \eZ\Publish\Core\FieldType\FieldType is the abstract class . If I cannot rely on methods inherited from it, then I should implement \eZ\Publish\SPI\FieldType\FieldType from scratch.

@ezrobot

This comment has been minimized.

1 similar comment
@ezrobot

This comment has been minimized.

@adamwojs
Copy link
Member Author

PR updated according to @alongosz suggestions.

Copy link
Member

@alongosz alongosz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, one nitpick, but fixing it won't affect behavior, so can be tested by QA

QA:
please try to see if you're able to use it in multisite environment with changed SiteAccess-aware config of this feature per SA (I suggest just parent_location_id).
I'm asking for it because there are known issues when injecting dynamic parameters from SA config resolver.

$contentService: '@ezpublish.api.service.content'
$locationService: '@ezpublish.api.service.location'
$contentTypeService: '@ezpublish.api.service.content_type'
$mappings: '$fieldtypes.ezimageasset.mappings$'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the setting is introduced on Bundle level, here you should rather have some core fallback. It will also allow you to avoid overriding service in test yamls.

@barbaragr barbaragr self-assigned this Aug 22, 2018
Copy link

@barbaragr barbaragr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ready to merge @alongosz :)

@alongosz alongosz merged commit 4892d15 into ezsystems:master Sep 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
6 participants