Skip to content

Initial implementation of the ToolkitSampleButtonAttribute#308

Draft
michael-hawker wants to merge 1 commit intomainfrom
toolkit-sample-button-attribute
Draft

Initial implementation of the ToolkitSampleButtonAttribute#308
michael-hawker wants to merge 1 commit intomainfrom
toolkit-sample-button-attribute

Conversation

@michael-hawker
Copy link
Member

Fixes #4

This allows sample dev to easily add attribute to a method on their sample page in order to create a UI command button that executes that code (e.g. adding/removing items from a collection)

Example:

    [ToolkitSampleButton(Title = "Add 5 Items")]
    private void Add5ItemsClick()
    {

Attribute takes a Title like others do for the label of the button. Doesn't support enabling/disabling of button with CanExecute, just execution for MVP.

Creates a separate list of items in the ToolkitSampleMetadata to record the method names. Currently uses reflection to bind to the method at runtime, so we need to investigate if better way... Main challenge is taking method name from registry (even with class instance and such) and binding to the constructed instance of the page's methods...

There may have been some complication/duplication here due to how our generators run in two different contexts...?

Note: Assisted by GitHub Copilot using Claude Opus 4.6

This allows sample dev to easily add attribute to a method on their sample page in order to create a UI command button that executes that code (e.g. adding/removing items from a collection)

Example:
```cs
    [ToolkitSampleButton(Title = "Add 5 Items")]
    private void Add5ItemsClick()
    {
```

Attribute takes a Title like others do for the label of the button. Doesn't support enabling/disabling of button with CanExecute, just execution for MVP.

Creates a separate list of items in the ToolkitSampleMetadata to record the method names.
Currently uses reflection to bind to the method at runtime, so we need to investigate if better way... Main challenge is taking method name from registry (even with class instance and such) and binding to the constructed instance of the page's methods...

There may have been some complication/duplication here due to how our generators run in two different contexts...?

Note: Assisted by GitHub Copilot using Claude Opus 4.6
<ColumnDefinition Width="Auto" />
</Grid.ColumnDefinitions>

<ScrollViewer x:Name="CommandsPanel"
Copy link
Member Author

Choose a reason for hiding this comment

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

Discussed that we maybe move this to be underneath the sample and then aligned to the right like a commandbar style sort of thing. Will see if @niels9001 has any suggestions. I think at least underneath may look a lot better for the page/doc view when inlined with the text for sure.

{
foreach (var button in Metadata.SampleButtons)
{
button.BindToInstance(sampleControlInstance);
Copy link
Member Author

Choose a reason for hiding this comment

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

Not sure how we can hook these together without the reflection encapsulated in here yet. Wanted to get it working first, will see if can adjust this aspect or not from here.

I would posit we maybe need more of a wrapping class where we create commands based off the information, but I think this is maybe different than the [RelayCommand] sort of MVVM Toolkit scenario, as we're trying to gather them all in a collection tied to the registry. That's static/string output at compile time.

@Arlodotexe let me know if you have thoughts, not sure if we can carve out any of Sergio's time to pick his brain on this; I know he's been pretty busy lately.

I do think this whole process/interface for sample devs though is super valuable to make it dirt-simple to have these more complex interactions.

/// encodes button data as assembly-level attributes that the head project can read.
/// </summary>
[AttributeUsage(AttributeTargets.Assembly, AllowMultiple = true)]
public class ToolkitSampleButtonDataAttribute : Attribute
Copy link
Member Author

Choose a reason for hiding this comment

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

This was added by the AI late in the process to try and get something to work between the assembly boundary between the registration generation and the sample app itself. It ended up working so I didn't question it, but I feel we have some duplication now, but I know we also have two generator workflows crammed into one based on our sample libraries/assemblies get processed...

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

Successfully merging this pull request may close these issues.

ToolkitSampleButtonAction Attribute

1 participant