It appears that Microsoft has done away with the MarkupExtension class in Windows Store Apps altogether. This means that there's no x:Static any more (among other things). Is there any replacement for it at all ? If not, why ? What's the new technique for providing static members in XAML (e.g. as ConverterParameters in Bindings) ?
Related
This question is likely a particular XAML application. XAML is a custom markup to instantiate objects and, as such, define custom applications. Note that, it serves to both declare WPF user interfaces and WWF workflows. It would also help to specify, e.g., a custom source-code change detection solution. To avoid getting in deeper in unnecessary details. I need to design a custom XAML-based model that, like the one for WPF and the one for WWF do, allows me to declare a custom application on top of XAML, without having to create a WPF or WWF project. Is this sort of third-part XAML-like provider possible to build?
<Approach>
<PrimitiveExample
OriginalType={Type syntax:LiteralSyntax}
ModifiedType={Type syntax:LiteralSyntax}
Propagation.Matched={Binding MatchedPropagationCommand}>
...
</PrimitiveExample>
...
<Approach/>
Let us see it this way. Is there a way to get a stand-alone XAML file that works as follows?
a) There will be a project item, e.g., named "Stand-alone XAML".
b) I create a new "Stand-alone XAML" item named, e.g., "Solution.sccd", and I add it to a console application, class library, or many other projects. This because it will be a sort of smart .config.
c) I can set up a root instance in "Solution.sccd" (likely containing a lot of nested instances) - this is natural for XAML.
d) When declaring instances in "Solution.sccd", I can use features like attached properties, binding, and many other smart features or markup extensions that can be used with WPF or WWF, but this will not be a WPF or WWF project.
e) I can instantiate the declared root instance, e.g., with simple code line like "var rootObject = XAMLInstanceCreator.Create(Solution.sccd)", and use that object.
Does this make sense now?
Regards, Guillermo.
I don't really like the idea of injecting localizer, what's wrong with the classic approach of having a class with static properties generated? It's much easier to use than injecting IStringLocalizer everywhere I want to localize.
I understand that using this interface allows us to swap the implementation to localize using something other than resources but if we only want to use resources, is it worth the trouble?
Short answer is, ease of use and speedup of development time.
A shared class with static properties requires to pre-define all localized strings in advance.
But in case of using IStringLocalizer you don't have to pre-define the localized strings, you just type plain texts during development, and later on you can define the localized versions in the resource files.
additionally, it will much easier to manage localization with IStringLocalizer if you have a team working on the same project.
If I compare Typhoon with one of the common IOC container spring in java i could not find two important freatures in the documentation.
How to annotate #autowired?
How to annotate #Scope? Especially distinglish between SCOPE_SINGLETON and SCOPE_PROTOTYPE.
More about spring here:
http://docs.spring.io/spring/docs/4.0.0.RELEASE/spring-framework-reference/html/beans.html#beans-standard-annotations
Typhoon supports the prototype and singleton scopes along with two other scopes designed specifically for mobile and desktop applications.
In a server-side application, the server may be supporting any of the application's use-cases at a given time. Therefore it makes sense for those components to have the singleton scope. In a mobile application, while there are background services its more common to service one use case at a time. And there are memory, CPU and batter constraints.
Therefore the default scope with Typhoon is TyphoonScopeObjectGraph, which means that references to other components while resolving eg a top-level controller will be shared. In this way an object graph can be loaded up and then disposed of when done.
There's also the following:
TyphoonScopeSingleton
TyphoonScopePrototype
TyphoonScopeWeakSingleton
Auto-wiring macros vs native style assembly:
Unfortunately, Objective-C has only limited run-time support for "annotations" using macros. So the option was to use either a compile-time pre-processor, which has some drawbacks, or to work around the limitations and force it in using a quirky style. We decided that its best (for now) to use Macros only for simple convention-over-configuration cases.
For more control we strongly recommend using the native style of assembly. This allows the following:
Modularize an application's configuration, so that the architecture tells a story.
IDE code-completion and refactoring works without any additional plugins.
Components can be resolved at runtime using the assembly interface, using Objective-C's AOP-like dynamism.
To set the scope using the native style:
- (id)rootController
{
return [TyphoonDefinition withClass:[RootViewController class]
configuration:^(TyphoonDefinition* definition)
{
definition.scope = TyphoonScopeSingleton;
}];
}
I'm creating a framework for iOS with this tool and I want to manage the visibility of my classes. Of course, I put my headers in corrects sections in my Build Phases > Copy Headers .
But when I add my framework in a new project, I still can access to classes (and their functions) stored in the Private section. I want my class "public" in my framework but "private" outside.
Is it possible ?
Thanks.
Tom
In the Objective-C runtime, everything is in the same global namespace. You can hide things by not including them in public headers, but they're still there and can be discovered and accessed using the lower level runtime APIs.
Is it better to use friend or public forms in vb.net? What are the advantages of each?
I notice when you import a vb6 project, the forms come in as friend, but when you add a new form in vb.net it is public. I have not seen any difference in the way they work, though, so I must be missing something.
In my opinion, I would use Friend (aka internal in C#) even though the default is public. I would also use private for controls on the form even though I think VB defaults to protected. In general, think of type/member access as if it were your wife's boobs. Keep them hidden from others up unless there's some benefit to exposing them (like getting out of a speeding ticket or making a shared library of common dialogs, etc.)
One drawback with making things internal is that you have to do some extra work to make them public to your unit tests. See the InternalsVisibleToAttribute for details.
VB6 did not support exporting forms from a class library. The natural mapping for converted code therefore is Friend. However, VB.NET has no such problems. Using Public is fine, assuming any exposed types in public method arguments is Public as well. Easy to find, the compiler will tell you.
If the form is Public it can be accessed from outside the current assembly (.exe). If it's Friend then it's only accessible from within the assembly. The same access level rules apply to Forms as other VB.NET classes.
I can't think of a common Winforms situation where you would need public Forms because they're usually in the same assembly making friend good enough. Unless you had forms scattered through different assemblies and they needed to reference one another.
Maybe the Microsoft team that wrote the import tool decided on Friend because all the forms came from the same classic project, whereas the Visual Studio (New Item) team decided on Public because the .NET way deals more with modularized projects. It might just be as simple as that.