Hiya all,
I wanted to see what people thought on trying to get the core codebase to start using data attributes to register custom code for Umbraco, rather than updating .config files or adding DB entries.
For example I would love to have my own custom 404 handler and put a data attribute on the class for it to be automatically picked up by Umbraco, rather than putting the dll in the bin along with updating the 404handflers.config file.
So what do we all think as developers, is this something we want/need so we have a less dependency on config files & DB entries or is there still a need for these files ?
My own feeling: relying solely on attributes can be tricky because you can't see what's going to be used just by looking at one place. OTOH I don't like the config files. So I'd rather go with the "register in code" ie create an application handler and explicitely do whatever you have to do in there. The same way we're telling people to register / remove / change the IContentFinder or anything else via the resolvers.
The tricky part with registering features (e.g. NotFoundHandlers/IContentFinder) in code is knowing the order of execution. While it's possible to insert a component before another known component, it is difficult to visualise the sort order - as you would in a config file.
OK I think this is more of a problem for package devs personally to try and avoid these conflicts.
However my next suggestion then is to have a debug page for Umbraco /umbraco/debug
IContentFinders
WarrensContentFinder
LeesContentFinder
Umbraco Macro Parameters
.... etc ....
In which it lists out all the items it has loaded into the application as a list and the order they were put in, so you have a visual way to know what is running, where & when.
About the order: deep within Umbraco.Core there's a "weight" attribute that I created because I thought we could have resolvers that automatically sort out the instances they create by "weight" (the order of sequences having the same weight being unspecified). Shannon wasn't very fond of that trick... and I think it's internal at the moment, and not used. Thoughts?
@Warren +1000 for the "status page", that's something I have had in mind for a long time, it should be part of the developer section, some sort of dashboard that would report plenty of internal details (especially, how the resolvers resolve, etc).
As mentioned, attributes are awesome until you want to know what's going on or want to disable a feature. A status page would be great (and even more discoverable than config files), but then it needs to be accompanied with a way to also disable (or re-prioritize) a feature without deleting the assembly. And while all this would be fantastic it's a lot of work compared to a good old config file. Not saying it wouldn't be cool to get it done, just that it won't be something we'll have resources for at the HQ (but we'd love pull requests - then you could just argue that it should be consistent across all plugins and then you're back at a pretty big task).
@Niels I am not denying it's a BIG task, but it's something I am keen to hope and try and tackle with a pull request one baby step at a time. To get a small but continuous progress on it, I think over time it will be possible to get this done.
@Lee how would I go about integrating with MiniProfiler?
@All I think I may clone/fork the repo and start off with a simple dashboard or debug page to show information about the Umbraco installation and then take the work from there.
Then with a next step goal for it to be able to disable/enable items easily with a click of a button perhaps (but may be out of my scope of coding skills)
If anyone wants to help out or join me with this goal of trying to say goodbye to the config file & DB entries once and for all, it would be fantastic.
@Lee currently struggling to find resources on how to extend MiniProfiler for now I think I will create either a separate .aspx page or Dashboard usercontrol for the developer section in the meantime and then port it over to MiniProfiler at a later date when I can find some resources on it.
Data Attributes rather than .config
Hiya all,
I wanted to see what people thought on trying to get the core codebase to start using data attributes to register custom code for Umbraco, rather than updating .config files or adding DB entries.
For example I would love to have my own custom 404 handler and put a data attribute on the class for it to be automatically picked up by Umbraco, rather than putting the dll in the bin along with updating the 404handflers.config file.
So what do we all think as developers, is this something we want/need so we have a less dependency on config files & DB entries or is there still a need for these files ?
Let's chat & discuss this.
Cheers
Warren
My own feeling: relying solely on attributes can be tricky because you can't see what's going to be used just by looking at one place. OTOH I don't like the config files. So I'd rather go with the "register in code" ie create an application handler and explicitely do whatever you have to do in there. The same way we're telling people to register / remove / change the IContentFinder or anything else via the resolvers.
Thoughts?
Stephan
The tricky part with registering features (e.g. NotFoundHandlers/IContentFinder) in code is knowing the order of execution. While it's possible to insert a component before another known component, it is difficult to visualise the sort order - as you would in a config file.
Could it not be possible with an int on the attribute as some kind of sort order perhaps?
Thoughts?
Warren
Yup, but then how to handle conflicting order values?
e.g. take 2 handlers
and
Which one should run first? It could be done by sort order then alphabetical - but even that might not be desired. (Tricky, I know)
OK I think this is more of a problem for package devs personally to try and avoid these conflicts.
However my next suggestion then is to have a debug page for Umbraco
/umbraco/debug
IContentFinders
Umbraco Macro Parameters
.... etc ....
In which it lists out all the items it has loaded into the application as a list and the order they were put in, so you have a visual way to know what is running, where & when.
What do you think?
About the order: deep within Umbraco.Core there's a "weight" attribute that I created because I thought we could have resolvers that automatically sort out the instances they create by "weight" (the order of sequences having the same weight being unspecified). Shannon wasn't very fond of that trick... and I think it's internal at the moment, and not used. Thoughts?
@Warren +1000 for the "status page", that's something I have had in mind for a long time, it should be part of the developer section, some sort of dashboard that would report plenty of internal details (especially, how the resolvers resolve, etc).
As mentioned, attributes are awesome until you want to know what's going on or want to disable a feature. A status page would be great (and even more discoverable than config files), but then it needs to be accompanied with a way to also disable (or re-prioritize) a feature without deleting the assembly. And while all this would be fantastic it's a lot of work compared to a good old config file. Not saying it wouldn't be cool to get it done, just that it won't be something we'll have resources for at the HQ (but we'd love pull requests - then you could just argue that it should be consistent across all plugins and then you're back at a pretty big task).
@Warren - a report status/debug page would be great. Maybe hook into MiniProfiler?
@Niels I am not denying it's a BIG task, but it's something I am keen to hope and try and tackle with a pull request one baby step at a time. To get a small but continuous progress on it, I think over time it will be possible to get this done.
@Lee how would I go about integrating with MiniProfiler?
@All I think I may clone/fork the repo and start off with a simple dashboard or debug page to show information about the Umbraco installation and then take the work from there.
Then with a next step goal for it to be able to disable/enable items easily with a click of a button perhaps (but may be out of my scope of coding skills)
If anyone wants to help out or join me with this goal of trying to say goodbye to the config file & DB entries once and for all, it would be fantastic.
Thanks
Warren :)
@Warren re: MiniProfiler - no idea, I haven't looked at it yet - but know that it's doable.
@Lee currently struggling to find resources on how to extend MiniProfiler for now I think I will create either a separate .aspx page or Dashboard usercontrol for the developer section in the meantime and then port it over to MiniProfiler at a later date when I can find some resources on it.
is working on a reply...