Feature #48090
closed
AbstractTagBasedViewHelper should have a remove attributes method.
0%
Description
It would be nice if it would be possible to remove attributes forcefully just before rendering a tag.
For example:
<f:image src="myImage.jpg" alt="Me" width="100c" height="100c" removeAttributes="{width,height}">
would render a 100x100 cropped processed image but would have the width and height attributes removed from the img tag:
<img src="myProcessedImage.jpg" alt="Me">
I think this could be a useful functionality on all tags.
Updated by Alexander Opitz over 9 years ago
- Project changed from 2559 to TYPO3 Core
- Category set to Fluid
Updated by
Updated by Claus Due over 8 years ago
Just a tiny update from the side lines: this issue has been reviewed, judging if it has any impact on or is affected by the merging of the standalone Fluid package as TYPO3 dependency.
Verdict: NOT AFFECTED. However, I would discourage creating this feature. It's sort of the wrong direction: removing tags you don't want, rather than not assigning them in the first place. If "Dave" would like to forcibly remove natural properties on the tag after having specified exact dimensions which logically would be echoed in the tag attributes, "Dave" should create a custom ViewHelper subclassing f:image, one that doesn't assign any height/width. Or the other solution: use a standard <img> and f:uri.image instead, giving you 100% control over attributes.
PS: syntax error in code example; assume "Dave" means either an array or a CSV.
Updated by Dave no-lastname-given over 8 years ago
Obviously "Claus" has not built a responsive website where despite removing "natural" attributes from tags images can still have set dimensions. The display of the image is determined by CSS and not inline attributes however you still may want your image cut to a certain size. What once was natural may not be wanted. Unfortunately the ability to physically resize an image is built into the unnatural and non standard fluid template attributes of width and height. Moving into the future I do believe fluid should give as much output control for the coder as possible. If the coder wishes to modify a tag for whatever purpose, in any shape or form, make it easy for them not difficult. Implying the set "Claus" perception of natural rules is not necessarily helpful in a world of changing rules.
I think I have also mentioned before that fluid should be fluid, and not kludge that requires the coder to jump hoops to roll view helpers to fix every minor limitation of fluid. The more flexibility you give to the coder the less issues you will have from them, which is why I think fluid should open up to the entire PHP API and not just an artificial limited subset which needs to be implemented for every one.
Updated by Claus Due over 8 years ago
Disclaimer: I remember Dave and his passive aggressive tone, even years later. Now he's also making untrue statements about my personal experience and knowledge, and he's not reading the suggestions he is given - which have cost me time to provide him with - and I'm mildly offended by that. Two things that offend me are falsehoods and ungratefulness and Dave displays both. This comment may show some signs weariness over that.
Unfortunately the ability to physically resize an image is built into the unnatural and non standard fluid template attributes of width and height.
Incorrect. The same attributes are possible on f:uri.image, as are maxWidth and maxHeight. See https://fluidtypo3.org/viewhelpers/fluid/master/Uri/ImageViewHelper.html
Moving into the future I do believe fluid should give as much output control for the coder as possible.
I agree. That's why I suggested to you that you can use f:uri.image instead - and gain 100% control over every single attribute that gets added. How much more output control do you need, honestly? Maybe you missed my original suggestion (it requires that you read it all instead of just skipping and reacting in what looks like arrogance over being rejected).
If the coder wishes to modify a tag for whatever purpose, in any shape or form, make it easy for them not difficult.
What's easier:
- Invent a new parameter requiring new processing and new documentation, which works contrary to the nature of every single other ViewHelper argument across the popular packages of fluid, vhs and flux (that's more than 300 total ViewHelpers sharing one common thing about arguments: they're additive).
- Or use a manual HTML tag and a ViewHelper to generate the exact "src" or "href" you require.
Well, for you of course it is easier to just demand that we change the API and write the new documentation that explains why this logic is reverse, rather than you teach yourself the value of using manual HTML for the tags and ViewHelpers for the attribute. Please.
Implying the set "Claus" perception of natural rules is not necessarily helpful in a world of changing rules.
I find that funny in an absurd and offensive kind of way. But it makes me want to not help you; makes me want to keep any further suggestions reserved for people who will appreciate them.
I think I have also mentioned before that fluid should be fluid, and not kludge that requires the coder to jump hoops to roll view helpers to fix every minor limitation of fluid.
New features with logic reversed when compared to 300+ use cases is not a hoop, but considering use of manual HTML is? Try to acknowledge that knowing when and how to use alternative syntax is even more valuable than knowing about a special parameter with reverse logic, and we'll both be better off. You won't have to look silly and waste time because you attack my conclusions based on your own ignorance. And I won't have to be annoyed that you do that.
The more flexibility you give to the coder the less issues you will have from them, which is why I think fluid should open up to the entire PHP API and not just an artificial limited subset which needs to be implemented for every one.
You may want to take this opportunity to look up my name in connection with "fluid". I'm really not the person you should be attacking here, Dave.
Updated by Dave no-lastname-given over 8 years ago
Sorry Claus I don't mean to grind your gears but the passive aggression came from your side, when you placed my name in quotes.
Whether or not you see my use case, the need to control which attributes should be rendered by a view helper that outputs a html tag is still a reasonable request and use case. Your work-around is not making it easier for the developer, as it is forcing them to reconstruct a tag. We have a view helper to construct such a tag. Why not use it. Such a solution just makes the html tag view helper redundant and it does not make fluid, fluid.
My suggestion is to help developers and not hinder them by sending them on work-arounds. Every work-around eliminated is surely a step in the right direction.
Updated by Claus Due over 8 years ago
- Status changed from New to Rejected
Sorry Claus I don't mean to grind your gears but the passive aggression came from your side, when you placed my name in quotes.
In case it wasn't clear, that's simply because I wasn't sure if your account was an actual user account or just some throw-away created to report this and a few other user stories. Most of us provide first and last name (not that I'm requiring it of you) and those that don't, often look like virtual accounts to me. I see now that you're "that" Dave so the quotes are gone.
Anyway, we need to finish this off:
Whether or not you see my use case,
I fully see your use case, I just don't agree about your proposed method of solving it. I've argued quite a lot at this point as to why but you still owe me a reaction to the fact that this proposed solution reverses a logic that's currently used in hundreds if not thousands of use cases (every existing tag based ViewHelper argument). You should also evaluate the fact that this requires special documentation; documentation, which already exists for the alternative I suggested.
It's not that we're lazy. It's that the change you propose is not as simple as it seems, nor is it a frequent problem (you can take this issue as example - two years with barely any reaction, including from other users). This is why I ask you if you honestly think that extensive work should be done on providing you with this feature, or if you should use the perfectly valid alternatives we've provided for you exactly for this reason?
(basically we shouldn't be spending this much time debating it as it looks extremely low priority also to yourself?)
the need to control which attributes should be rendered by a view helper that outputs a html tag is still a reasonable request and use case.
It is, very much. But it's not logical to me that you would declare a "remove these attributes" functionality more reasonable than my advise to "avoid using the method that adds those attributes".
Your work-around is not making it easier for the developer, as it is forcing them to reconstruct a tag.
Is your proposed solution making it easier, as it forces the developer to read and remember new documentation and use an additional property, that is unique to tag based ViewHelpers and follows a logic that exists in this place and this place only?
That's why I call for reasonable evaluation now. My proposed solution is objectively more predictable and requires less background knowledge. What background knowledge it does require is also extremely useful in every other similar case.
We have a view helper to construct such a tag. Why not use it.
In this case: because it produces output you do not desire and not using it will let you avoid that output!
Such a solution just makes the html tag view helper redundant and it does not make fluid, fluid.
It's not redundant, it just doesn't fit every conceivable use case and was not intended to fit every use case (for example, it doesn't support srcset). It does however fit the more prevalent use case - it works for the 85%, to use a popular reference.
And I've been trying to tell you now for sentence after sentence that yes, Fluid is also inline syntax used in combination with HTML - it's designed to work that way, too! so the fact that the tag based variant of some ViewHelper doesn't exactly fit your use case shouldn't motivate you to invent new, reversed features. It should motivate you to use the equally valid alternative syntax.
Fluid is not just tag-based syntax. It can do so much more if you just start loving the inline syntax a bit more.
My suggestion is to help developers and not hinder them by sending them on work-arounds. Every work-around eliminated is surely a step in the right direction.
You mentioned that, yes. But you did not seem to notice that I dealt with this expectation earlier. I have argued why this proposed feature is more of a workaround than the alternative. That's a conclusion I arrived to by objective means:
1. Reversed logic; having to define what you don't want. Zero existing similar usages in Fluid and third-party libraries.
2. Demands new, acquired knowledge. Developer must read and understand what this parameter does and when to use it. That is, if he doesn't just use the alternative solution as a natural thing.
3. Demands new documentation before said knowledge can be acquired by developers. Has to be closely described because it's reversed logic.
4. Has only a single current use case: this one, which is clearly an edge case.
5. Has alternative solution that should be a natural part of every last Fluid-using developer's repertoire: manual tag and inline syntax.
6. Even though the use case is accepted and acknowledged, parts 1-5 make it much more reasonable to simply reject this, pointing to the valid alternative and trying to convince you that your request is not reasonable.
Just use the alternative, Dave. It's not a workaround, it's a more controllable way of doing the very thing you try to do.
You may also find #62940 relevant as it lets you use "0" as height and width and thus avoid rendering the attributes (but your use case is still an edge case: explicitly wanting resizing but not wanting dimensions after that resizing is performed). And you may also find #57417 interesting.
At this point I think we've exhausted the logic. Your last reply looks much like a rehash of the previous one (as does mine, of course) so it seems we're at an end here. What you should take away from this discussion is that your suggestion has been very carefully weighed and considered, in fact so carefully that now you have the equivalent of a two-page evaluation from one of the developers most experienced with the Fluid API. And the answer after all those reasons is: no, we won't create this.
Sorry. Now let's move on, okay? ;)
Updated by Dave no-lastname-given over 8 years ago
Sorry Claus I don't mean to grind your gears but the passive aggression came from your side, when you placed my name in quotes.
Whether or not you see my use case, the need to control which attributes should be rendered by a view helper that outputs a html tag is still a reasonable request and use case. Your work-around is not making it easier for the developer, as it is forcing them to reconstruct a tag. We have a view helper to construct such a tag. Why not use it. Such a solution just makes the html tag view helper redundant and it does not make fluid, fluid.
My suggestion is to help developers and not hinder them by sending them on work-arounds. Every work-around eliminated is surely a step in the right direction.
Updated by Dave no-lastname-given over 8 years ago
Look I am sorry your lengthy arguments do not convince me.
The advantage of the image view helper is clear. You can feed it an image object and alt and title attributes will be automatically added, but unfortunately so will the width and height. The suggested alternative "work-around" which is what it is, creates more effort. Which is a shame.
As for the length of your response and efforts required, or whether it is an edge case is irrelevant. This is an open source project whether you bother to look at something or not is totally on your own leg, there is no such thing as time wasting in open source development, either you see you can contribute or you do nothing. Maybe someone else might want to tackle the issue if it scratches an itch. As #57417 shows I am not the only one having this as an issue, though when I wrote this feature request sourceCollections were not available. I would send a patch myself if I agreed to the contributors agreement, which I don't as I find giving unrestricted copyright and patent rights to the Typo3 Organization not in the spirit of open source. The GPL v3 does not need contributor agreements. So you will see very little code/documentation from me on this project, only suggestions which I give on my own free will.
The validity of this request stands, and the issue IMHO opinion needs to be kept open.
Rejecting it because you do not see a value or do not want to do it is premature.
By the way do not get me started on the in-usability of inline syntax. On simple tasks it is ok, as soon as you need to do something more complex you go into brace spaghetti and it becomes unreadable. Inline syntax should be kept to a minimum or avoided completely. My professional opinion that fluid is kludge still stands until it ceases to be.
Updated by Claus Due over 8 years ago
Look I am sorry your lengthy arguments do not convince me.
I tried. You're welcome to bring this up with other contributors if you feel I'm incorrect in my decision but please refer to this issue if/when you do!
Updated by Benni Mack about 4 years ago
- Sprint Focus changed from PRC to Needs Decision