-
Notifications
You must be signed in to change notification settings - Fork 27
[RFC] Deprecate extractors & introducing mappings #133
Comments
Containing all of the seo properties to a single document which can be attached to different phpcr document seems to have a few advantages over this approach.
|
@benglass that a good point i haven't seen. What makes the decision not even easier ... |
Hi @benglass, I don't fully support the idea, but I think it should be possible to integrate with the idea in this issue. We can have a Why I don't fully support your idea:
|
@wouterj on disadvantage: |
Regarding the strategy of append vs override I think this actually would need to be configurable on a per instance basis. For example you may generally want your title tags to prepend so that you have "Page | Section | Site" however you may need to specify that one some pages you just want to override the the title completely. I do agree that this inheritance/append/prepend control is an important feature. |
We have had this feature while creating the bundle but changed it to that translation key thing we have now. So the creation of title (i.e.) isn't visible anymore as you define |
@wouterj regarding your proposed mappings approach, how would this handle arbitrary meta fields like robots, http-equiv etc. so they could be passed along to sonata page for rendering? It seems we would also want a defined way to take an object that has seo data and transfer that to sonata page service for rendering (in a kernel listener on request, for example, if cmf main content is set then we would tell the page service about the metas from the loaded page). |
That is exactly what this bundle does :) https://github.com/symfony-cmf/SeoBundle/blob/master/EventListener/SeoContentListener.php#L56
You mean, without a property that provides a value, but just a static value? Then it would be a constraint defined on the class |
@wouterj I'm specifically talking about arbitrary fields like robots, http-equiv and them being passed to the sonata page in the SeoPresentation class at https://github.com/symfony-cmf/SeoBundle/blob/master/Model/SeoPresentation.php#L145 which right now has the hard coded title, keywords, etc. |
Why not adding a field mapping with type and value attribbutes? Like @seo\Field(type="og:image") |
@ElectricMaxxx yes that is what I mean, we would need something like that if we are moving to a maping-based solution like @wouterj is proposing. Another reason I think having things encapsulated into a separate SeoMetadata class may be a better approach is encapsulation. It prevents the class with the metadata from having to know the details about the metadata. I'm not sure I understand why 1-to-1 is bad. If you are worried about another hit to the database it could be implemented as a phpcr assoc with a getSeoMetadata getter (as you have) that just populates it from the persisted extras collection and returns an instance of SeoMetadata. It would be up to end users to decide whether they want to store the seo metadata as a separate document or create it on the fly in their document class from other class variables or an assoc variable. |
If i understand it right the mapping solution wouldn't change anything on the encapsulation of the SeoMetadata. Just the filling will be changed. Atm We have a direct property $seoMetadata (SeoAwareInteface) with a form type for admin support or the values will be extracted from content by an extractor pattern. So the basic properties like $title, $metaDescription, ... will stay and some extras will be added ($fields i.e.) - all with a coresponding mapping. Instead of filling the SeoMetadata by the extractors they would be filled by mapped properties/methods. We would be more flexible for scaleability and the SeoMetadata will stay with its interfaces. |
The more i think about it the more i belive that the mapping is almost equal to the extractor. Cause what does the driver? It calls a method (same as our defined ones) or fetches a properties value. instead of forcing the content to provide a getSeoTitle() method by an interface, the mapping just looks if there is a mapped "getter" for the title. |
@ElectricMaxxx so are you saying that a Page object which has seo metadata would have a getSeoMetadata method? If not im wondering how you would be able to attach the sonata seo metadata admin form to it since it wouldnt have getters/setters for the SeoMetadata |
The form type admin support is available for SeoAwaInterface only. Which mean the class has to implement getter/setter for SeoMetadata. Have a look at the form type and the admin extension (writing from my mobile, so the links would be hard) for more information. An extractor solution has no admin support except the developer just extract properes 1-1 that have its own admin support. To write an SeoAware admin support for mapped properties will be a little bit harder cause We won't have any fix properties to Point to. |
@wouterj at night i cam to the conclusion not to do that now. Lets keep that in mind for a 2.0 version. I think we shouldn't change everything now what took two month to work out. Lets expand the existing system on 1.* as long as it goes. Lets add an array for that arbitrary data to the SeoMetadata and create a form solution for that. I think we will need that time to figure out which values for the SeoMetadata are needed, which should be extendable which could be removed somehow. Lets give the bundle (and us) some time to learn. We have got several issues which wouldn't touch the SeoMetadata (#1, #132) which would be features to go into 1.1 alone. We would make more trouble/work then we would need. |
@ElectricMaxxx I have also thought about this tonight and I think we can do this in a BC way. So I agree with you, we should not worry about this for 1.0.0 anymore. Let's focus on some minor caching (will do that today) and usage of arbitrary data in SeoMetadata (can you do that in the coming days?). Then we can start worrying about this for 1.1, 1.2 or a later 1.x release |
@wouterj we do not need to hurry with that BC break. As i wrote: lets wait an learn what other properties will come and wants to be handled. We will see. |
@ElectricMaxxx there is no BC break :) |
So ... lets start in here ... @wouterj is watching the world cup atm, so i can do some stuff :-) But first one question: Why |
jms metadata handles different formats automatically. as a result different formats behave consistently and supporting additional formats is less work. |
OK, you are right. |
@ElectricMaxxx I've already integrated jms into the RoutinAuto component. I think it's easier if I take care of this. I'm on a holiday currently, but when I'm back I'll start a PR. |
No worries i just created a new branch with the main classes. :-) |
What about Annotation Support? Would need an AnnotationReader-/Parser (Doctrine)? |
Yes, jms only provide the domain layer of handling metadata. All implementation stuff (such as types of drivers) should come from other libraries. |
So i would say i leave it up to you @wouterj and i will have a look at the other (smaller) issue. I prepared a branch with some classes and defined the services. You just need to give them some life :-) |
Let's skip this for 1.1 |
👍 |
I would say today, based on the discussion on irc: lets skip that to 2.0 as a major feature. |
Yeah |
Current Issues
We are having 4 issues with the current Extractors mechanism:
(1) and (3) are especially pretty hard to solve using the extractors.
I think we should go in a complete new direction for 1.1, however that can make things more complicated. I don't know if that's really welcome, since this bundle is pretty nice because it's not complicated.
Using Mappings
My idea was to use mappings instead of extractors. Instead of implementing some interfaces and introducing some wrapper methods which just call other functions, we should have a way to "map" some values of the document to SeoMetadata.
This can be done using the JmsSerializer. Some examples:
Of course, we should also support Yaml and Xml mappings and mappings for methods. For instance:
Support Custom Data
Then we can also fix #131 by using a generic "Meta" mapping for custom meta values:
Keeping BC
Of course, we should be BC. So we should keep supporting the extractors, but deprecate it.
replaces #118
The text was updated successfully, but these errors were encountered: