-
Notifications
You must be signed in to change notification settings - Fork 6
Razor file blocks for the SirTrevor namespace #21
Comments
Makes total sense to discuss this. Thanks for bringing this up! :) If we're going the route to be more feature complete and dev friendly (outside the frontenders et al.) it's probably an idea to go with an integrated assembly, wrapping everything up into one package. Could save us from update nightmares in the future as well (old files, and so on). Can't we provide a wrapper App_Code-Helper-File for the time being that uses the new DLL? |
Changing the Razor file so that calls to the helper functions are passed on to matching methods in the DLL isn't a problem. I took me only a few minutes to rewrite, so another commit coming up soon ;) Keeping the filename |
As far as I know there is unfortunatly no way to have a custom extension I tried to find our how If we can't figure out (maybe Shannon, Jeavon or the others can point uns into the right direction?) how to do that - what would be your proposed namespace naming? Everything I come up with feels akward, honestly... ;) |
Heretical: Is a breaking change an option? |
The package is still in beta, so breaking changes may be expected. But we can of course try to keep it to a minimum or even avoid it at all. From what I can tell I played around with a few ways to accomplish what we want. Currently I see the following options:
Since the classes in the DLL hasn't been released yet, this will not create any breaking changes. Regarding what namespace to use, I know that Warren Buckley has used the
It's getting late here, so I hope I haven't rambled too much. To play well with existing installations I think the first option is the best, and it will require very little work. |
Deleting a file could be done with the post-install old-school ascx; "if "Should work(tm)" |
Yes, Lee Kelleher has used the I think it's smart to add the helper part to the `Umbraco.Web.Mvc``namespace. Haven't thought about that... Did you try and test? :) |
My experience with package actions is very limited, so I don't know whether something like that is possible. Another way to handle it may simply be to let users know in the upgrade guidelines that they should uninstall the existing package first, then install the new one. I think we still need the entire I have tested and confirmed that creating a class in the |
If people need to uninstall, the datatype gets an new GUID, right? So they will need to reassign the datatype everywhere - or did that behaviour change? :) Yes, we'll still need to keep the |
You may be right about the datatype and a new GUID. I have had some bad experiences with datatypes in the past, so I have avoided creating datatypes on install in my own packages (mostly internal packages). But I haven't tested whether it is something that Umbraco has fixed. |
I did some further testing/research. Which namespaces that are available in Razor files is determined by two Web.config files:
This is an example of the Razor-related section in <host factoryType="System.Web.Mvc.MvcWebRazorHostFactory, System.Web.Mvc, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<pages pageBaseType="System.Web.Mvc.WebViewPage">
<namespaces>
<add namespace="System.Web.Mvc" />
<add namespace="System.Web.Mvc.Ajax" />
<add namespace="System.Web.Mvc.Html" />
<add namespace="System.Web.Routing" />
<add namespace="Umbraco.Web" />
<add namespace="Umbraco.Core" />
<add namespace="Umbraco.Core.Models" />
<add namespace="Umbraco.Web.Mvc" />
<add namespace="Microsoft.Web.Helpers" />
<add namespace="umbraco" />
<add namespace="Examine" />
</namespaces>
</pages>
</system.web.webPages.razor> So we can add our own namespaces here, and classes in that namespace will automatically be available in Razor files located in this directory (as well as sub directories). <host factoryType="System.Web.Mvc.MvcWebRazorHostFactory, System.Web.Mvc, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<pages pageBaseType="System.Web.Mvc.WebViewPage">
<namespaces>
<add namespace="System.Web.Mvc" />
<add namespace="System.Web.Mvc.Ajax" />
<add namespace="System.Web.Mvc.Html" />
<add namespace="System.Web.Routing" />
<add namespace="Umbraco.Web" />
<add namespace="Umbraco.Core" />
<add namespace="Umbraco.Core.Models" />
<add namespace="Umbraco.Web.Mvc" />
<add namespace="Microsoft.Web.Helpers" />
<add namespace="umbraco" />
<add namespace="Examine" />
<add namespace="SirTrevor.Razor" />
</namespaces>
</pages>
</system.web.webPages.razor> I have a created a package action that will add this namespace on installation, and of course remove it again if the user chooses to uninstall the package. The package action also removes the I have tested this on a local 7.1.4 where it works like a charm. It doesn't rely on any new Umbraco logic, so it should work on all 7.x installations. Once we have sorted out the branch issue, I can commit this to the 0.8 branch. I'm not totally sure at the moment how to handle the same if we introduce a NuGet package. Hopefully NuGet can help us do an XML transformation on both install and uninstall. It is important to remove the namespace again since it will cause an exception in Razor files if the namespace can't be found. |
The file
SirTrevor.cshtml
in the App_Code folder will result in an auto-generated class having the full name ofASP.SirTrevor
(since all Razor files are created in theASP
namespace).So for our own Razor files, having a reference to a class called
SirTrevor
will mean that we can't reference classes in theSirTrevor
namespace (as we're using in the DLL). At least not like this:However something the code below will work, but prefixing all references with
global::
is not very user-friendly:I'm not totally sure on how to proceed with this, so here goes my thoughts:
SirTrevor.DataValue.SirTrevorDataValue
would be moved toSomething.SirTrevor.DataValue.SirTrevorDataValue
and so forth. Since my changes with the DLL hasn't been released yet, this shouldn't break any code in existing installs.SirTrevor.cshtml
file from the App_Code folder. The two helper functions can easily be moved to a helper class in the DLL, but I'm pretty sure that this will cause a breaking change for people who already have installed the package and used the example MVC view.Option 1 will have the least impact on existing installs being upgraded, but option 2 will give a clean package without any unnecessary files that could/should be in the DLL.
Hope this makes sense ;)
The text was updated successfully, but these errors were encountered: