xamarin/Xamarin.Forms

Shouldn't be able to reference sub-namespaces with Xaml

Open

#5,704 opened on Mar 27, 2019

View on GitHubContributor guide
 (2 comments) (0 reactions) (1 assignee)C# (1,926 forks)batch import
a/Xaml </>e/3 :clock3:help wantedin-progressinactivet/bug :bug:up-for-grabs

Repository metrics

Stars
 (5,644 stars)
PR merge metrics
 (No merged PRs in 30d)

Description

Description

(from @TimBarham): Consider an app that has an Buttons namespace, and a Buttons.Flat namespace. There's a RoundedFlatButton type in the Buttons.Flat namespace, but it is referenced in XAML as if it was in the Buttons namespace:

<ContentPage ... xmlns:buttons="clr-namespace:Buttons">
    ...
    <buttons:Flat.RoundedFlatButton Text="A Button" />
    ...
</ContentPage>

That element is referring to the RoundedFlatButton type in the Buttons.Flat namespace. But such a usage is not valid XAML. Forms seems to handle this fine, but it should be interpreted as a property element, not an object element (only property elements can contain a period). Our intellisense (and the XET XAML parser) reject this (the specific error is that there is no RoundedFlatButton attached property found on type Flat).

Steps to Reproduce

Expected Behavior

Actual Behavior

Basic Information

  • Version with issue:
  • Last known good version:
  • IDE:
  • Platform Target Frameworks:
    • iOS:
    • Android:
    • UWP:
  • Android Support Library Version:
  • Nuget Packages:
  • Affected Devices:

Screenshots

Reproduction Link

Contributor guide

Research direction
Investigate the XAML parser in Xamarin.Forms to understand how type references are resolved, specifically for dotted names like 'Flat.RoundedFlatButton'. The parser should treat such references as property elements rather than object elements when the namespace contains a sub namespace. Look for where type resolution happens and add validation to reject invalid references.
Tech stack
csharp
Domain
mobile
Issue type
Bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
2
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
C#XAMLXamarin.Forms
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
50