8000 Add a Palette helper to support working with PaletteManipulator by Toflar · Pull Request #8302 · contao/contao · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Add a Palette helper to support working with PaletteManipulator #8302

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

Open
wants to merge 14 commits into
base: 5.x
Choose a base branch
from

Conversation

Toflar
Copy link
Member
@Toflar Toflar commented Apr 25, 2025

I wanted to create this PR for years, now I finally did it. I very often find myself modifying palettes in the palette_callback but the PaletteManipulator lacks the options to create an instance based on a string and you also cannot ask if there's a legend or a field present. So I always have to resort to str_contains() which can of course fail if fields start with the same prefix etc.
So finally, here we go 😅

@Toflar Toflar added the feature label Apr 25, 2025
@Toflar Toflar added this to the 5.6 milestone Apr 25, 2025
@Toflar Toflar self-assigned this Apr 25, 2025
@Toflar Toflar requested a review from leofeyer as a code owner April 25, 2025 08:45
@Toflar Toflar requested a review from a team April 25, 2025 08:45
@aschempp
Copy link
Member
aschempp commented Apr 25, 2025

I'm not sure this is a good idea. The PaletteManipulator current does not know about existing palettes, it only knows about changes you want to apply, which you can then apply to different palettes. In the current implementation I see two issues:

  1. you can fromString and then apply it to a random palette somewhere, which makes no sense
  2. hasLegend and hasField only works if you previously fromStringed a palette, which is 99% not the case

Checking for the existance of a field should be rather simple, maybe we could just provide helpers for that if really necessary?
\in_array('field', StringUtil::trimsplit(',;', $palette))
or a legend (might also need to check for :hide/:collapsed)
\in_array('{legend}', StringUtil::trimsplit(',;', $palette))

8000
@Toflar
Copy link
Member Author
Toflar commented Apr 25, 2025

Yeah, this is exactly what I want? If I have an existing palette and want to apply this to another, I can do now. Why would I not want this? I have grid configuration that consists of 10 fields (dynamically, sometimes it's 5 depending on the type) and then I want to add that to an existing palette. Works perfectly like this.

@aschempp
Copy link
Member

Yeah, this is exactly what I want? If I have an existing palette and want to apply this to another

What do you mean by apply this to another?

@fritzmg
Copy link
Contributor
fritzmg commented Apr 25, 2025
  1. you can fromString and then apply it to a random palette somewhere, which makes no sense

Why does that make no sense? For a new content element I basically always copy & paste the one from headline and adjust it afterwards. This way I can do that via the PaletteManipulator.

@aschempp
Copy link
Member

Why does that make no sense? For a new content element I basically always copy & paste the one from headline and adjust it afterwards. This way I can do that via the PaletteManipulator.

You want a class to parse a string and rebuild it with new fields instead of just writing a string into your DCA? 😮

@fritzmg
Copy link
Contributor
fritzmg commented Apr 25, 2025

You want a class to parse a string and rebuild it with new fields instead of just writing a string into your DCA? 😮

Yes 👍

@Toflar
Copy link
Member Author
Toflar commented Apr 25, 2025

Yes of course! This is the whole purpose of the palette_callback:

#[AsCallback('tl_content', 'config.onpalette')]
public function onPaletteCallback(string $palette, DataContainer $dc): string
{
       $pm = PaletteManipulator::fromString($palette);

       if ($pm->hasField('my_field')) {
           $pm->addField('field_one,field_two,field_three', 'my_field');
       }

       return $pm->applyToString($palette);
}

@Toflar
Copy link
Member Author
Toflar commented Apr 25, 2025

Now you can even simplify this to

#[AsCallback('tl_content', 'config.onpalette')]
public function onPaletteCallback(string $palette, DataContainer $dc): string
{
       $pm = PaletteManipulator::fromString($palette);

       if ($pm->hasField('my_field')) {
           $pm->addField('field_one,field_two,field_three', 'my_field');
       }

       return $pm->asString();
}

fritzmg
fritzmg previously approved these changes Apr 25, 2025
m-vo
m-vo previously approved these changes Apr 25, 2025
zoglo
zoglo previously approved these changes Apr 25, 2025
@leofeyer leofeyer added the up for discussion Issues and PRs which will be discussed in our monthly calls. label Apr 28, 2025
@leofeyer
Copy link
Member
leofeyer commented May 8, 2025

As discussed in the call, @aschempp will think again to see if he can come up with a better solution, but otherwise we'll merge the PR as it is.

@leofeyer leofeyer removed the up for discussion Issues and PRs which will be discussed in our monthly calls. label May 8, 2025
@ausi
Copy link
Member
ausi commented May 9, 2025

How about adding a class Palette that internally stores the result of the current PaletteManipulator::explode() method?

$pm = new PaletteManipulator();
$palette = Palette::fromString($paletteString);

if ($palette->hasField('my_field')) {
   $pm->addField('field_one,field_two,field_three', 'my_field');
}

return $pm->applyToPalette($palette)->toString();

The parsing logic could then be moved to the Palette class and be used by the PaletteManipulator.

Just a suggestion ☺️

@Toflar
Copy link
Member Author
Toflar commented May 9, 2025

I thought about that too, would that be okay for you @aschempp?

@Toflar Toflar dismissed stale reviews from zoglo, m-vo, and fritzmg via 04f7619 May 9, 2025 06:58
@Toflar Toflar force-pushed the feature/palette-manipulator-extension branch from 04f7619 to 2d8e79f Compare May 9, 2025 06:59
@Toflar
Copy link
Member Author
Toflar commented May 9, 2025

Gave this a try in 2d8e79f. Now the PaletteManipulator remains basically untouched.

The only little strange thing is that you have to call applyToString() with your Palette object because applyToPalette() is already taken for a DCA reference. But imho that's totally acceptable.

ausi
ausi previously approved these changes May 9, 2025
@aschempp
Copy link
Member

I thought about that too, would that be okay for you @aschempp?

I was actually thinking about this PR just now and poking around in some code, coming up with the Palette object myself. Then I wanted to check what you did, and realize @ausi suggested this as well 😅

I do however think that the config array of the Palette should be internal. PaletteManipulator should only "record" a list of changes that can then be applied to any Palette instance. So the private applyField, applyLegend etc. methods should probably move to the Palette class (and accept the exact arguments that are in the changes of PaletteManipulator.

Let me know if you want me to contribute 🙃

@Toflar
Copy link
Member Author
Toflar commented May 12, 2025

Let me know if you want me to contribute 🙃

Yes please :)

@aschempp
Copy link
Member

see Toflar#19

Toflar added 3 commits May 20, 2025 14:10
# Conflicts:
#	core-bundle/src/DataContainer/PaletteManipulator.php
@Toflar Toflar requested a review from ausi May 20, 2025 12:30
@Toflar
Copy link
Member Author
Toflar commented May 20, 2025

PR ready for review again.

aschempp
aschempp previously approved these changes May 22, 2025
@Toflar Toflar requested a review from aschempp May 22, 2025 07:48
@Toflar Toflar changed the title Add more helper methods to PaletteManipulator Add a Palette helper to support working with PaletteManipulator May 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants
0