After having a discussion with @leekelleher (and noticing the problem elsewhere), we thought it would be a good idea for there to be, as standard, reserved directory within a default umbraco install, that package developers can use to store related assets.
On a few of my packages, I have created a sub folder within the Umbraco folder, but this isn't the best option as it may get overwritten during upgrade, or removed / renamed for security. Other options I've seen are to drop assets in the standard folders, but personally I don't like this either, as it makes controls and files available within the UI.
My sugestion then, is for a standard directory ("extensions", "plugins", "packages" or some other name) to be created, that is included in the umbracoReservedUrls app setting by default.
This should be quite a simple convention to implement, and would love it if we could get it into the next version.
Same as Matt, for a few of my packages I've created used a sub-folder in the main /umbraco folder - which goes against my feelings of "don't touch core files" - as it could make upgrades a nightmare.
I do believe there should be a root-level folder for package assets - with each package having a sub-folder in there.
Although for the uComponents (data-type) project, we are taking an alternative approach, by embedding resources in the DLL - then accessing them via WebResource. Which is fine for .NET development.
Going forward we really need to get around to working out some standard for how plugins are installed into Umbraco.
I'm of the opinion that nothing should go into the /umbraco or /umbraco_client folders and they should be volatile, you can destroy them at any point and nothing will be lost.
It'd be nice if there was some kind of a /UmbracoPlugins folder that we could install into alternatively.
That said I do like the uComponents idea of embedding everything as resources. It's not always possible to do everything as a resource, but doing as much as you can (CSS, JavaScript, Images, etc) is a really great idea as it means that there is a lot less files for users to have to worry about.
Hiya, As a package developer some of my stuff is simple and install plain old XSLT files, but in cases of say CWS & Dictionary Translator, I have things installed in various places.
I think in CWS if I remember I install website assets/images into the /media folder asd I know it has write access, however I agree a more common place for where files should live would be brilliant (obviously exlcuding those that need to live in XSLT folder etc...)
Aaron when you talk about an embedded resource, what do you mean and how would I go about doing it?
I'm kind of in 2 minds about embeded resources to be honest. On the one hand, yes, it means there are a lot less files to install, but on the other, I can't help but feel it's a lot more closed off. True, you could download the source, modify it, and recompile, but there is also something to be said about the files being available to modify if you so choose.
I guess it's down to developer preference at the moment, but I think a dedicated folder is something we are all going to need (as you say, not everything can be an embeded resource).
Yeah, I worry about any filesize bloat when using embedded resources... but, if you need the various CSS, JavaScript and images, then it all amounts to the same file-size on disk, right?
Still curious about other overheads by using embedded resources... but the idea of dropping in a single DLL and everything run from there is such a nice concept (especially for what we're doing on uComponents).
Going back to the original topic... maybe a prefix, like "umbraco_client", how's about "umbraco_plugins"? (Can't decide between "plugins" or "packages").
@Lee - I guess as "most" items that are dropped in there, would come from packages, "umbraco_packages" would be the most logical. I think it gets unnecessarily complicated, if you start using terms that aren't really used elswhere (I understand the reasoning, but I think the simpler, and more logical the better).
@Soeren - Not as far as I can see. At the end of the day, it's just a folder. But it needs to be a standard name and needs to be in the umbracoReservedUrls app setting.
However in 4.5 if you create a package a folder called "created-packages" get created in the "media" folder. Which I presume is due to the write permissions I talked about before.
It would be good to hear from more people from the core on this, to get a more definitive answer.
+1 on this, I've just put my bits in a dedicated folder in the /umbraco folder (as all my packages have been back office extensions), but I'm always wary about that not being the best place to store them.
Man, this is a good topic. #h5yr Matt for starting it!
I vote for the "packages" folder being a umbraco standard.
About the resources i think the 1 dll is not that good. Lets say you make a jQuery based package and maybe it would be nice for the developer that installed it to see what is in the file and maybe change it a little. That could be done in 2 min. But if he needs Visual Studio to make the changes and first download the source he will be spending the first 15 min doing that. And not all frontend developers have Visual Studio. So i go for the not embedded version of packages
@Matt - There's a big difference between open source and having the source files as part of the 'installer'. There's nothing to say that you can't have an open source project which has the CSS/ JavaScript as embedded resources, in fact, that's my preference for shipping open source components.
By having released versions 'locked down' it's easier to diagnose errors as you know that people haven't changed stuff themselves which may have broken things.
@Warren - CWS is a bit of a different case to most other packages though, so I think that trying to apply the same standards to it would be a bit silly. It writes to the media folder so that an Upload data type is configured like expected, etc.
@Lee - Are you guys using ClientDependency for uComponents? That'd be the best way to do the CSS and JavaScript and you wont have to worry about performance ;)
@Slace - I wasn't saying it was any less "open source", it was more along the lines of what Anders was saying. If you aren't a full blown .NET developer, and all you want to do is tweak some CSS/JS/Image that is part of the component, is it wrong to force them to modify it via VS?. I can see arguments from both sides, and am not saying either is right or wrong, but I do think it would be wrong to force package developers to use one over the other.
Anywho, all I want is a folder, the rest is up to you =)
I was most way through writing that post when I thought I was addressing some of your points which is why I ended up addressing it to you :P. It was a more generalized statement.
One of the things that came out of the retreat was what this thread may ultimately evolve into is some standards and guidelines around package development and deployment.
Now that we are talking about best practice for packages and where to place them. Is there already a best practice for managing files related to the package. Where does javascript files go? In the project subfolder in the new "package" folder or else where? Would be great to have a complete wiki page about "Best practice for package developers" so everybody has the same way to do it, as of now almost everyone have their own way of doing things :)
If we can get this new folder agreed, you'd have a couple of options really. You could go the route @lee/@aaron have mentioned which is to embed the assets in your DLL, in which case they don't need to be filed anywhere. Or, you would just store them in the "umbraco_packages" folder in a sub folder for your package.
If like @warren's CWS though, you may just want to save them in the existing folders, as CWS is more of a starting point for a website, so those assets make sence to be in the standard folders.
I'm sure there will be a number of blog posts and a wiki page soon, but I think the key to all of these is this standard "umbraco_packages" folder.
@Matt - its a great start to have the "packages" folder. But would be great to have best practice for all the file storing if you dont embed them in the dll so people can easily find files if they want to change something in your package.
And ofcourse CWS is way different from normal packages so i agree that it should be in the normal umbraco structure
i think the name "umbraco_packages" is kind of wrong isnt it? Ofcourse its an umbraco package when you make it for umbraco :) so i think it should be named "packages", but just my opinion :p
I see your structure and think that good - but as @Matt showed i think usercontrols should be in a UserControls folder. But Scripts, Css and Images is okay i think.
Sorry Guys jut seen this post. There is already a default package folder it's called it's the /Umbraco/plugins folder. Per Ploug Hansen mentioned that during a Dutch Meetup last year. All HQ products are installed in the same folder.
@Jeroen
I always store my packages in the plugins folders and create a subfolder for aspx pages. So in my situation it would be:
I think it would still be better to have one outside the umbraco folder, as that folder can change so it means you'd have to make sure you never hard coded that path and instead used GlobalSettings.Path, which is tricky if you need the path in something other than .NET.
Create a reserved directory for 3rd party package files
Hi Guys,
After having a discussion with @leekelleher (and noticing the problem elsewhere), we thought it would be a good idea for there to be, as standard, reserved directory within a default umbraco install, that package developers can use to store related assets.
On a few of my packages, I have created a sub folder within the Umbraco folder, but this isn't the best option as it may get overwritten during upgrade, or removed / renamed for security. Other options I've seen are to drop assets in the standard folders, but personally I don't like this either, as it makes controls and files available within the UI.
My sugestion then, is for a standard directory ("extensions", "plugins", "packages" or some other name) to be created, that is included in the umbracoReservedUrls app setting by default.
This should be quite a simple convention to implement, and would love it if we could get it into the next version.
What does everyone think?
Matt
For a little background info, there was recently a topic on 'where to place asmx files' - which raised the same questions.
http://our.umbraco.org/forum/developers/extending-umbraco/10174-where-to-place-my-asmx-web-service
Same as Matt, for a few of my packages I've created used a sub-folder in the main /umbraco folder - which goes against my feelings of "don't touch core files" - as it could make upgrades a nightmare.
I do believe there should be a root-level folder for package assets - with each package having a sub-folder in there.
Although for the uComponents (data-type) project, we are taking an alternative approach, by embedding resources in the DLL - then accessing them via WebResource. Which is fine for .NET development.
Cheers, Lee.
Going forward we really need to get around to working out some standard for how plugins are installed into Umbraco.
I'm of the opinion that nothing should go into the /umbraco or /umbraco_client folders and they should be volatile, you can destroy them at any point and nothing will be lost.
It'd be nice if there was some kind of a /UmbracoPlugins folder that we could install into alternatively.
That said I do like the uComponents idea of embedding everything as resources. It's not always possible to do everything as a resource, but doing as much as you can (CSS, JavaScript, Images, etc) is a really great idea as it means that there is a lot less files for users to have to worry about.
Hiya,
As a package developer some of my stuff is simple and install plain old XSLT files, but in cases of say CWS & Dictionary Translator, I have things installed in various places.
I think in CWS if I remember I install website assets/images into the /media folder asd I know it has write access, however I agree a more common place for where files should live would be brilliant (obviously exlcuding those that need to live in XSLT folder etc...)
Aaron when you talk about an embedded resource, what do you mean and how would I go about doing it?
Warren :)
I'm kind of in 2 minds about embeded resources to be honest. On the one hand, yes, it means there are a lot less files to install, but on the other, I can't help but feel it's a lot more closed off. True, you could download the source, modify it, and recompile, but there is also something to be said about the files being available to modify if you so choose.
I guess it's down to developer preference at the moment, but I think a dedicated folder is something we are all going to need (as you say, not everything can be an embeded resource).
Matt
Yeah, I worry about any filesize bloat when using embedded resources... but, if you need the various CSS, JavaScript and images, then it all amounts to the same file-size on disk, right?
Still curious about other overheads by using embedded resources... but the idea of dropping in a single DLL and everything run from there is such a nice concept (especially for what we're doing on uComponents).
@Warren: a little background on embedded resources for ASP.NET: http://support.microsoft.com/kb/910445
Going back to the original topic... maybe a prefix, like "umbraco_client", how's about "umbraco_plugins"? (Can't decide between "plugins" or "packages").
Cheers, Lee.
@Lee - I guess as "most" items that are dropped in there, would come from packages, "umbraco_packages" would be the most logical. I think it gets unnecessarily complicated, if you start using terms that aren't really used elswhere (I understand the reasoning, but I think the simpler, and more logical the better).
Matt
I can't really see any downside by having a "Packages" root directory. Are there any?
/SoerenS
@Soeren - Not as far as I can see. At the end of the day, it's just a folder. But it needs to be a standard name and needs to be in the umbracoReservedUrls app setting.
Matt
I agree with using something named "packages".
However in 4.5 if you create a package a folder called "created-packages" get created in the "media" folder. Which I presume is due to the write permissions I talked about before.
It would be good to hear from more people from the core on this, to get a more definitive answer.
Warren :)
+1 on this, I've just put my bits in a dedicated folder in the /umbraco folder (as all my packages have been back office extensions), but I'm always wary about that not being the best place to store them.
Man, this is a good topic. #h5yr Matt for starting it!
I vote for the "packages" folder being a umbraco standard.
About the resources i think the 1 dll is not that good. Lets say you make a jQuery based package and maybe it would be nice for the developer that installed it to see what is in the file and maybe change it a little. That could be done in 2 min. But if he needs Visual Studio to make the changes and first download the source he will be spending the first 15 min doing that. And not all frontend developers have Visual Studio. So i go for the not embedded version of packages
@Matt - There's a big difference between open source and having the source files as part of the 'installer'. There's nothing to say that you can't have an open source project which has the CSS/ JavaScript as embedded resources, in fact, that's my preference for shipping open source components.
By having released versions 'locked down' it's easier to diagnose errors as you know that people haven't changed stuff themselves which may have broken things.
@Warren - CWS is a bit of a different case to most other packages though, so I think that trying to apply the same standards to it would be a bit silly. It writes to the media folder so that an Upload data type is configured like expected, etc.
@Lee - Are you guys using ClientDependency for uComponents? That'd be the best way to do the CSS and JavaScript and you wont have to worry about performance ;)
Yes, we're using ClientDependency for uComponents. It's working out really well!
@Slace - I wasn't saying it was any less "open source", it was more along the lines of what Anders was saying. If you aren't a full blown .NET developer, and all you want to do is tweak some CSS/JS/Image that is part of the component, is it wrong to force them to modify it via VS?. I can see arguments from both sides, and am not saying either is right or wrong, but I do think it would be wrong to force package developers to use one over the other.
Anywho, all I want is a folder, the rest is up to you =)
Matt
I think we all agree that there is a time & place for using embedded resources. I don't think anyone is suggesting that it should be the defacto way.
For me, Umbraco is all about flexibility... so yeah, a folder for package devs to "put their shit" is the way to go.
Cheers, Lee.
I was most way through writing that post when I thought I was addressing some of your points which is why I ended up addressing it to you :P. It was a more generalized statement.
One of the things that came out of the retreat was what this thread may ultimately evolve into is some standards and guidelines around package development and deployment.
And a folder is a good start though ;)
Now that we are talking about best practice for packages and where to place them. Is there already a best practice for managing files related to the package. Where does javascript files go? In the project subfolder in the new "package" folder or else where? Would be great to have a complete wiki page about "Best practice for package developers" so everybody has the same way to do it, as of now almost everyone have their own way of doing things :)
Hey Anders
If we can get this new folder agreed, you'd have a couple of options really. You could go the route @lee/@aaron have mentioned which is to embed the assets in your DLL, in which case they don't need to be filed anywhere. Or, you would just store them in the "umbraco_packages" folder in a sub folder for your package.
Root
- Css
- Scripts
- ...
- Umbraco
- Umbraco_client
- Umbraco_packages
- YourPackage
- Js
- Css
- UserControls
-- ...
If like @warren's CWS though, you may just want to save them in the existing folders, as CWS is more of a starting point for a website, so those assets make sence to be in the standard folders.
I'm sure there will be a number of blog posts and a wiki page soon, but I think the key to all of these is this standard "umbraco_packages" folder.
Matt
@Matt - its a great start to have the "packages" folder. But would be great to have best practice for all the file storing if you dont embed them in the dll so people can easily find files if they want to change something in your package.
And ofcourse CWS is way different from normal packages so i agree that it should be in the normal umbraco structure
For now, going with "umbraco_packages" as the folder name, using my Robots.txt Editor as an example...
Cheers, Lee.
i think the name "umbraco_packages" is kind of wrong isnt it? Ofcourse its an umbraco package when you make it for umbraco :) so i think it should be named "packages", but just my opinion :p
I see your structure and think that good - but as @Matt showed i think usercontrols should be in a UserControls folder. But Scripts, Css and Images is okay i think.
I'm building a package which contains some .aspx pages (for in the openmodal popup). What would be the best directory to store these files?
Jeroen
Sorry Guys jut seen this post. There is already a default package folder it's called it's the /Umbraco/plugins folder. Per Ploug Hansen mentioned that during a Dutch Meetup last year. All HQ products are installed in the same folder.
@Jeroen
I always store my packages in the plugins folders and create a subfolder for aspx pages. So in my situation it would be:
/umbraco/plugins/[my package name]/pages
Cheers,
Richard
Hi Richard,
Cool, thanks for the clarification.
I think it would still be better to have one outside the umbraco folder, as that folder can change so it means you'd have to make sure you never hard coded that path and instead used GlobalSettings.Path, which is tricky if you need the path in something other than .NET.
Matt
Hi Richard,
Thanks for the tip! I'll be using that folder. It's already in the umbracoReservedPaths which is also good :).
Jeroen
is working on a reply...