There are a number of times, particularly with a modular app design where a CSS file may not necessarily reside within the same assembly as a Page/View consuming that CSS resource. There needs to be a decent way from XAML where we can load this resource.
cc: @jassmith @kzu
There are a few ways that this could probably be done:
Having something like a CSS Resource Location Handler that could be exported at the assembly level could be good to provide a global way of dealing with where to look for css files being referenced within a particular assembly or perhaps at an application level.
Changing source from a Uri to an object and determine if it's a Uri, StyleSheet, or a TextReader would offer a lot of flexibility as you could write custom Markup Extensions that could simply do the work of locating the resource and then either creating the StyleSheet or providing the TextReader to create the StyleSheet.
switch(Source)
{
case Uri uri:
return DoCurrent(uri);
case StyleSheet stylesheet:
return stylesheet;
case TextReader reader:
return StyleSheet.FromReader(reader);
default:
return throw new NotSupportedException();
}
Adding an Assembly Property to the StyleSheetExtension would provide a nice clean and more verbose way of providing context for the StyleSheetExtension to locate the resource.
<StyleSheet Source="theme/style.css" Assembly="MyAwesomeLibrary" />
There is nothing that works from XAML OOB AFAIK
We know about this limitation, and plan to expand the source uri parsing to include the assembly
a shorthand for
<StyleSheet Source="theme/style.css" Assembly="MyAwesomeLibrary" />
could be
<StyleSheet Source="theme/style.css;assembly=MyLibrary" />
as I don't really want to support the full pack://
uri spec for that
+1. Pack uris are awful.
Unless there's going to be another (or flexible?) Key=Value, I'd even remove the assembly=
prefix. So:
<StyleSheet Source="theme/style.css;MyLibrary" />
I'm personally a huge fan of flexibility. So for those who prefer more verbosity they might have
<StyleSheet Source="theme/style.css" Assembly="MyAwesomeLibrary" />
With the short-shorthand @kzu mentioned
<StyleSheet Source="theme/style.css;MyAwesomeLibrary" />
Will this also be valid for xaml only ResourceDictionary
?
<ResourceDictionary Source="theme/dark.xaml;DarkThemeLibrary"/>
@ahmedalejo that wouldn't make any sense since a XAML file represents a class which can already be referenced cross assembly vs a css file which is simply an embedded resource.
Daniel,
ResourceDictionaries are no longer required to have a code behind and/or an associated type. So it makes sense.
--
Stéphane
On 15 Jun 2018, at 22:18, Dan Siegel notifications@github.com wrote:
@ahmedalejo that wouldn't make any sense since a XAML file represents a class which can already be referenced cross assembly vs a css file which is simply an embedded resource.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or mute the thread.
@StephaneDelcroix personally I've long thought the requirement of having a code behind class is silly if I am not using it for anything... but whether we're talking about ResourceDictionaries or some other XAML file (page/view)... there really is no good reason why it should ever simply be an EmbeddedResource IMO. This could easily be handled at build where a XAML ResourceDictionary is compiled making keeping it very easy to work with... In any case ResourceDictionaries are way off topic for this issue.
Daniel,
In any case ResourceDictionaries are way off topic for this issue.
it has everything to do with this, has you can reference Merged ResourceDictionaries with the exact same Source syntax
There are plenty of standards around that should be followed. Eg http://www.faqs.org/rfcs/rfc1738.html
or https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml or http://www.ietf.org/rfc/rfc2396.txt.
We shouldn't dream up our own.
Most helpful comment
+1. Pack uris are awful.
Unless there's going to be another (or flexible?) Key=Value, I'd even remove the
assembly=
prefix. So: