I want to make a small change to how the text on panels is displayed in an Umbraco grid.
I've found I can make the change to nestedcontent.controllers.js in just a few lines, and this works.
However, if/when we upgrade Umbraco this change may be lost.
What are the best practices? Alternative ways of changing Umbraco behavior?
Let try to answer this briefly... if you are talking about the back-end that is.
What are the best practices? Alternative ways of changing Umbraco behavior?
Angular & Plugins
Best way by far is to write plug-ins. Plug-ins can be in the first place property editors. But it could also be used to interfere with the complete backend. But you can go much further.
Almost everything can be extended, custom dashboards, custom sections, custom trees, ... you name it and it probably is possible to extend in the backend.
Everything is powered by angular. Nothing stops you from doing very funky stuff. Packages like Nexu intercept every angular http call and then run their own logic.
From .net Code
A lot of the umbraco logic (like the complete request pipeline) can be replaced by your own implementation. Nothing stops you from run your own UrlProvider.
And what about the events (doing things after somethings happens). E.g. after a save.
Best practices
I think a best practice is to leave umbraco as is. Do not change it if you don't really need to. Use all extension points where you can.
And use the default Umbraco stuff. Don't reinvent the wheel. Use things which already exists in Umbraco. It will give you the possiblity to build better websites for content editors, and faster for the users.
Looks like it's a package specific file (Nested Content)? You could download the package file, unzip it and make the change before re-zipping it and keep the zip file in a safe place? ;-) Or, if it's a change that everyone could benefit from, make a pull request on Github?
I say make the change, and whilst you're at it put in a Pull Request for the project author to change it permanently.
Here's why I wouldn't worry about the Umbraco upgrades overwriting it:
Upgrades in Umbraco aren't automatic, unless you're using the cloud version. So this means you make a choice to upgrade. When doing any sort of development it is always a good idea to have your code checked into a source control of some sort. I like SVN or GitHub personally.
When upgrading an Umbraco site, I always make sure I have checked in all of my files to source control. If you do this, when it comes to doing the upgrade, you can see if the file has changed, and on the line where you made your change, you can revert that line back to what you had it at.
I hope this makes sense.
Related
My client does not like the Metronic UI provided in the ASPNETZERO template. He is looking into getting something custom designed by a UI/UX designer or purchasing another UI template. I wanted to find out if anyone else has done this change with ASPNETZERO and I wanted to ask some questions around this process.
Have you completely removed Metronic template from ASPNETZERO
and used another UI template?
What challenges did you run into?
How much effort did it take?
Any tips, tricks and advice that you can share on making this change would be much appreciated!
I haven't done such a change myself, but as a user and UI/UX student, here are some tips:
Have you completely removed Metronic template from ASPNETZERO and used another UI template?
If you're completely replacing the UI with another template, you can easily remove Metronic UI. That's the great thing about ASP.NET Zero (and the underlying ABP)'s n-layered architecture.
What challenges did you run into?
Make sure that the UI template that the designer gives can actually be used with the data that you want to display from view models. Tip 1: Request that the designer considers the models.
How much effort did it take?
It will take a lot of effort binding the UI back to the view models and some models may change since a UX designer may propose a different flow. Tip 2: Request that the designer uses some form of view model, or template strings like {Name} for the hard-coded values in his design.
Tip 3: Factor in time for ajax configuration, since the designer may only provide static screens.
Good luck!
Update
Do you know all the files/folders I need to alter/remove or change in the ASPNETZERO solution?
The particular files depend on what you actually modify. The designer should provide you with *.html and *.css files, maybe even *.js files. For the most part, you can leave the current *.css and *.js files (under wwwroot) alone. *.cshtml files (under Views) are safe to alter.
I've been searching all day for an answer to my problem, and don't seem to be able to find an answer.
I'm trying to implement a CRUD web application using Grails, with the IntelliIDEA IDE. Whereas with JSF i could use primefaces which allowed me to do this with general ease, i am disappointed to see, or at least seems to be that way, that the framework is a step backwards when it comes to development of html pages.
All i want is to have a table that is populated from data that is coming from a controller, and whenever i add a record it is also displayed in this table. I want to be able to edit any record on this table and also remove records. It would be awesome if there could be a component like primefaces datatables that allows me to do this easily, without having to use JavaScript. I've taken a look to the Dojo plugin, but it's so outdated and incomprehensible to me that i have discarded this option, mainly because there is no documentation on the site on how to use it with Grails, specifically.
Also, i do not want to use scaffolding. I am trying to learn how to do this from scratch, and it is of my understanding that it doesn't work too well with domains with many to many relationship, for example.
In a nutshell, what I am looking for is the best way to make a CRUD application on Grails that doesn't involve the use of scaffolding.
I would suggest you to go through "Grails in Action" book and follow the creation of web application "Quote of the Day" and "Hubbub", don't use scaffolding instead create your own views and controller using documentation provided.
This will help you to understand basic CRUD operations in Grails.
And also looking into documentation http://grails.github.io/grails-doc/latest/guide/theWebLayer.html
See if this can help you.
You are aware that the scaffolding also can generate code for you to learn from and continue your work from there (i.e. it doesn't have to happen magically behind the curtains). I would say that is the typical means of starting out with Grails and CRUD.
Otherwise, no Dojo probably won't help you out a lot. Maybe have a look at some other plugin, for instance the Easygrid plugin? It is based on Javascript though, which most solutions do.
The "Grails in Action" recommendation is probably your best bet for the long-term, learning it from the pro's rather than learning-by-doing/top-to-bottom CRUD-style.
I'm developing a site in umbraco, and integrating uBlogsy (blog) in it.
But the problem is, uBlogsy offers its own look n feel. However i want to have my existing website design in Blogging part as well.
here is the link for the same :
http://our.umbraco.org/projects/starter-kits/ublogsy
I've done that manually. but its a time taking process.
Does any one knows, how can i do that? is there any automation available for the same?
Or if there exists any better blog than uBlogsy offering same feature and functionality?
Thanks in advance.
uBlogsy is the de-facto blog package for umbraco so i'd be surprised if you find anything better (the community is encouraged to build upon the best instead of spin up many sub-par competitors, but i digress).
I've done that manually. but its a time taking process.
^^This sounds like you have modified the cshtml markup and css from the package. This is indeed the way to go.
There isn't really any plug-in theming that i'm aware of and it sounds like this is what you're looking for, right?
I've used uBlogsy many times on past projects and usually don't keep anthonys files for template views but rather start with fresh markup to match my wire-comps. Since his files are included - they make a great example for how-to access the data.
Sorry it's probably not what you're looking to hear. But i think it ultimately gives greater control and better result to get hands-on.
This may sound like a dumb question on the surface, but why does the Hot Towel SPA Template include Breeze at all?
I've been spending the last few days learning Hot Towel and its dependencies, and as far as I can tell, nothing in the template actually uses Breeze. Perhaps that is going to change with some future release?
Sure, Breeze is a good library. But it's bound to CRUD methodology and requires you design your ApiControllers a particular way. (Metadata, SaveChanges, etc.) see here
It also guides you to Entity Framework. While this is more of a soft-dependency, since Breeze also shows a sample without it, it still guides you down a similar pattern of implementation using a modified repository pattern.
If you are using a NoSQL datastore, or CQRS patterns instead of CRUD, then Breeze becomes very difficult to use. There are alternative libraries for data access that work well in this style, such as AmplifyJS.
But the rest of Hot Towel is excellent! I especially like Durandal. So the question begs, if the template isn't actually doing any data access - why include any data access component at all? It would be better to ship it without Breeze, and if the end-user wants to use Breeze, or Amplify, or whatever - then so be it. The rest of Hot Towel would continue to shine as a great SPA implementation.
Matt - Good question. Since I created it I guess I should answer :)
When I built the template I had a focus on providing enough to get folks going with the right tools, and just enough starter code to guide the way. I did not want anyone ripping out code. I'm not a fan of templates that start you down a path and make you remove tons of files and code and change direction. Those are samples.
Samples are good. In fact, samples can be excellent (like the other templates, which I feel are more like samples). Those serve another purpose: to show how you can do things.
Back to the Hot Towel template ...if I include code that uses Breeze, I would be tempted to add a datacontext.js and a model.js on the client. They would contain data access code and code to extend the models on the client. Then I would be tempted to add a controller, some server side models, an ORM and a database. Once there, I'd want to use the data in multiple screens, which leads me to more Knockout and caching with Breeze. Then I might be tempted to add editing, which would lead to change tracking. Soon I have a full blown app. Or more conservatively, I have a sample again. While these approaches would provide more guidance on how to put these together, they would not help you "get started" with a template where you can just start building and adding your own code. If I stop short of some of these features, it's still walking down a road that requires you to change how I did it.
As it stands today, HotTowel is pretty darn close to a template in the truest sense. You create a new project and you are off and adding your own code.
You could argue (and you may be) that Breeze shouldn't be in there since I don't use it in the template. Nor do I use moment.js, BTW. However, I argue that they are both excellent libraries that I would not want to build a CRUD based SPA without them. Breeze is flexible, as you suggest, so you don't have to walk a specific path.
The best way to understand the value of Breeze is to build an app that has its features but without Breeze. Then you can see how much code that takes and how involved it is. For one such example, see my intermediate level SPA course at Pluralsight where I do exactly this: http://jpapa.me/spaps
So you ask "why Breeze?" ... because I strongly recommend it for building a SPA.
Thanks for asking and good luck !
Thanks for asking the question.
John, as author of HT, has offered an answer. I, as a principal of the Breeze project, am inclined to agree with him :)
HotTowel generates a foundation for you to build upon. It is not the building itself.
It is a foundation intended for a specific kind of application, a CRUD application based on a specific set of cooperating JavaScript and ASP.NET technologies. Breeze is a contributor ... but not the only one. Knockout, with its MVVM design and 2-way data binding, is particularly well-suited to the data-entry tasks typical of CRUD apps.
Of course there are other kinds of SPAs. There's an important class of apps that mostly present information and accept little user input. Such apps don't benefit as much from data binding and the people who write them can get pretty hostile about data binding in general and KO in particular.
My point is that HT targets a particular class of application ... one that happens to be immensely successful at least when measured by sustained popularity. It delivers the goods for people who build those apps. It may not be the right starting place for other kinds of apps.
It is true that the easy road to Breeze runs through Web API, EF, and a relational database. Take those away, and you may writing more code on the server (and a little more on the client). That may be the perfect trade-off for you.
The authors of Breeze would like to make that path easier. I don't think BreezeJS makes it harder. I don't understand your statement "Breeze becomes very difficult to use." Have you tried it?
Your client can communicate with any HTTP resource in any manner you chose. It is pretty easy to use existing Web API controllers (albeit easier with Breeze Web API controllers). You can use amplify.js if you prefer (btw, you can tell Breeze to make AJAX calls with amplify). You don't even have to use the Breeze EntityManager to query and save data if you don't want to.
The rest of BreezeJS may still have value for you. There remains plenty of work to do after you've figured out how you'll retrieve and store data and whether you prefer Entity-ChangeSet style or Command/Query style.
You'll have to find answers to these questions:
How will you shape the raw JSON data into bindable objects?
How will you hold on to these objects and share them across multiple screens without making redundant round-trips to the server?
How will you navigate from one object to a related object as you do when binding an Address to a combobox of StatesAndProvinces?
How will you track changes?
How will you validate them?
How will you store some or all of the data in local storage when the app "tombstones"?
Breeze can help with these chores even if you don't want it to query and save for you.
And if you're answer remains "I'll do all of that myself, thank you" ... well, removing Breeze from your HotTowel project is as easy as:
Uninstall-Package breeze.webapi
When you start creating an application or site in ASP.NET MVC, what do you do before typing in that first line of code?
I'm personally fond of creating a new ASP.NET MVC Web Application project and then cleaning out controllers/views until I have what is essentially a blank project (i.e. it runs but doesn't offer functionality). Then I start working on my model and adding controllers/views as needed.
I've also read about starter kits and sample applications but I have not yet started actively working with any of them. However, in my reading I have seen authors suggest that it might be good to start off with an existing template and build on it.
I'm trying to determine if there are better ways of starting off a project such that time is saved and/or the resulting deliverable is of higher quality.
The other things I do (I also clear out the controller/views etc)
Put an IOC in place.
Put ELMAH into the project.
Then I grab a coffee and write my first test.
Kindness,
Dan
PS: At some point I shall get around to creating a template for this so I don't redo it everytime. As soon as I decide upon my favourite IOC. :-)
I usually clear out the Content folder as well and put in place a nice CSS reset file and/or a CSS framework like the 960 grid
Before starting any type of project you must know what you want to do. So take a sheet of paper and start writing on here:
The name of your application
Enumerate the features
Make a quick draft of the domain model (entities that you are going to have)
Try finding the ways (choosing a technology) you are going to do different stuff like: data access, validation (client and server side), logging, IoC, Security, Caching etc.
Do a quick draft of all the views you are going to have in your application
Identify any other problems you might need to solve/implement/develop and think how are you going to do that