I'm all new to magellan, and as an attempt to learn it, I've built a custom view engine for supporting windows forms as specified in the documentation at codeplex.
But how to register this new ViewEngine? There it is given,
ViewEngines.Engines.Add(new FormsViewEngine(new DefaultViewActivator()));
But what I can see is that, ViewEngines is not a Static Class and moreover it does not have a Engines Property. I know I'm missing something, but what is it?
So, How to register my ViewEngine to Magellan? Where and When should I register it?
PS: I'm using the latest update of magellan.
You are correct, the view engines are now configured on the ControllerRouteCatalog.
One of the goals in Magellan 2.0 was to reduce the number of static locators.
Seems like things have changed a bit. A few search for references of ViewEngine Class in the Magellan source gave the answer.
Now ViewEngines just provide default collection and no more handles ViewEngine registrations. I managed to create my own ViewEngineCollection and pass it to the contructor of ControllerRouteCatalog.
My bad, I should have done that before. Thanks anyway.
Related
I am trying to represent environment variables in the Salesforce codebase and came across Custom Metadata Types. So based on which Sandbox I am in, I want to vary the baseURL of an external service that I am hitting from my apex class. I want to avoid hard coding anything in the class, and hence trying to find out an environment variable like solution.
How would you represent the URL as a custom metadata type? Also, how can I access it in the class? What happens when a qa sandbox is refreshed from prod? Do they custom metadata type records get overridden?
How are you calling that external service? If it's truly a base url you might be better of using "named credential" for it. It'll abstract the base url away for you, include authentication or certificate if you have to present any...
Failing that - custom metadata might be a poor choice. They're kind of dictionary objects, you can add more (but not from apex) but if you deploy stuff using Git/Ant/SFDX CLI rather than changesets it'd become bit pain, you'd need different custom metadata value for sandbox vs prod. Kinda defeats the purpose.
You might be better off using custom setting instead (hierarchy is enabled by default, list you'd have to flip a checkbox in setup. List is useful if you need key-value kind of pairs, similar to custom metadata): https://salesforce.stackexchange.com/questions/74049/what-is-the-difference-between-custom-settings-and-custom-metadata-types
And you can modify them with Apex too. Which means that in ideal world you could have a "postcopy" class running as soon as sandbox is refreshed that overwrites the custom setting with the non-prod value. For named credential I don't think you can pull it off, you'd need a mini deployment that changes it or manual step (have you seen https://salesforce.stackexchange.com/q/955/799 ?)
In my cakePHP app I am implementing Miles Johson's Forum Plugin (http://milesj.me/code/cakephp/forum).
It creates a model named Profile in the plugin. I already have a model named Profile in my normal app, and as a result am getting a lot of errors when I use the forum. Combining the two models into one doesn't seem like a good option because they are used for very different purposes.
Is there an easy way to change model names in a plugin without hours of searching for every instance of "Profile" or "Forum.Profile" and changing it to "ForumProfile" and "Forum.ForumProfile"?
Thanks!
You could try to add another connection to your database.php, something like 'forums' and configure it to use a prefix 'forums_'. In the ForumsAppModel override the constructor and use your forums connection and prefix. You'll need to prefix all you forum tables with 'forums_'.
I do not understand why the forum plugin was not directly done with prefixes for the tables and everything.
What are the consequences if you switch a model's base class from db.Model to db.PolyModel (You decide you want to add polymorphism) after it already has entities stored in the datastore?
Also, is there any reason not to always create your models as PolyModels, so subclassing is never an issue?
As for you for your first question, it doesn't seem like an issue, since changing modal base class is a documented way to remove properties by Google.
I believe that PolyModel has some hidden cost when accessing the properties, this is why you should start with Model and switch only if necessary.
After upgrading to 2.0 many "hacks" like accessing protected attributes are not possible anymore.
For example (AssetHelper):
$scripts = $this->View->_scripts;
//pack and return combined scripts
The helper fatal errors, of course.
Does anyone know how to access those attributes in 2.0 without creating too much overhead in the process?
Are the AssetHelper and other such classes outdated if they try to access the View from inside a Helper?
The new way of accessing the View from a Helper in 2.0 is $this->_View which is protected. You can see it on the Helper API page.
I looked at the AssetHelper on Github and it is outdated. It still retrieves the view from the ClassRegistry instead of the new method. It also accesses the __scripts attribute of the old 1.3 View class which wasn't actually "private". I think you're correct that the change to real visibility declarations has broken this use.
Just brainstorming, but I wonder if you could make your own View class that has a getter for the _scripts attribute like $this->_View->getScripts(). I know that in 2.0 they added a slick ability to alias core classes; while I think this is restricted to helpers, components and behaviors it's something to think about.
Hope that helps.
Project Structure
I have a silverlight project SLProj, that references a silverlight class library project called ServiceClients. ServiceClients has two wcf service references, Svc1.svc and Svc2.svc. Both Svc1.svc and Svc2.svc are in two different WCF projects which use the same set of DataContracts which are again in a different class library project called MyDataContracts.dll.
Problem description
Now in my ServiceClients project I get an ambiguous reference issue when I need to use a datacontract class which is present in both the service references. If this were a winforms or webforms project, I could reference the MyDataContracts.dll and reuse the common types. But since, this MyDataContracts.dll was built using a non silverlight class library, it can't be referenced in the silverlight project
Workaround...
I am not sure if this below is the best method to go about taking care of this issue. Can anybody let me know if there is a cleaner way to solve this problem, or is this the best way we have so far?
create a single service reference.
click the 'show all files' button in the solution explorer
drill into the service reference and find Reference.svcmap and open it
find the MetadataSources section
add a second line to include the address to your second service. for example:
MetadataSource Address="http://address1.svc" Protocol="http" SourceId="1"
MetadataSource Address="http://address2.svc" Protocol="http" SourceId="2"
save, close, and update service reference.
Use Automapper
Map the DataContracts with AutoMapper.
You will have to invest some time in understanding AutoMapper and reworking your application. Also AutoMapper adds overhead because all data objects will be mapped. But first you will have a clean solution without hacks and second you gain a decoupled and simple data object layer just for your client. Once done you can forget the mapping but you stay flexible for future changes.
If you never have worked with Automapper it's important to play around with it before starting. Automapper is special and needs some time to familiarise with it.
So there. These are the rough steps:
1. Create a subdirectory and sub-namespace Data and copy the DataContracts. Remove the attributes and properties your client doesn't need because these mapped classes live only in your client. You can also change some types or flatten some complex properties.
2. Create an AutoMapperInit.cs like described at Automapper (read the Getting Started Guide). Use the conflicting references like this:
using ref1 = YourProjectServiceReference1;
using ref2 = YourProjectServiceReference2;
3. Wrap the service client like this:
Example GetExample() {
return AutoMapper.Map<ref1.Example, Example>(ref1.YourService.GetExample());
}
The wrapper also needs the same using directives as in step 2.
4. In this wrapper add a static initializer like this (assuming your wrapper class is called Wrapper):
static Wrapper() {
AutoMapperInit.CreateMaps();
}
5. Omit service references in the client and use using YourClient.Data;, the namespace you created in step 1.
Your client is now decoupled from the service and you don't have conflicts anymore.
Disclaimer: I am not affiliated with AutoMapper. I just used it in a project with a similar problem and am happy with it and wanted to share my experience.
Your workaround is actually quite OK. We've used it in several projects like this with 3 service references. It is actually a workaround for the IDE which for some reason only allows to select one service to create a service reference at a time.
Another thing you could try-out is to multi-target your shared contract to .NET and Silverlight, using the same codebase. Details on how to do such thing is described in http://10rem.net/blog/2009/07/13/sharing-entities-between-wcf-and-silverlight. Might be more work but feel less hacky.