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.
Related
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
Im really new to Grails and I try to understand how it works. I did some tutorials and wrote a sample application with a mysql database connection. Ive got three tables and therefor three domain-classes and three controller using def scaffold = true. So the views are generated automatically. Now I can add and remove and ... the data in my tables. Thats working.
But now I dont know how to go on. I mean, creating those tables and filling them is nice and its nice that this is possible so fast, but... Now I really want develope an application! Normally I work with Spring Framework, Spring Security, Spring MVC and so on to generate web applications. There, everything is logical. I have the requests comming in, the mapping to controllers, classes which work on the requests, answers given back, jsps rendered.... logical!
In Grails, I dont even know where to start for a real application! All tutorials I find show the same: Setting up those tables and being able to fill them, nice, nice - but after that?
Where do I save the "main.gsp". Do I need a controller for it? How does the application at start up redirect to "main.gsp".
Where can I define the "real logic" - I want to develope something like a "questions with multiple answers - try to select the correct answers"-application. Well, I must admit, I really dont know where to start. And I don't see the use of the Controllers and the possibility to add Data to my tables in my application. Thats for admins but not for users.
Could anyone give me an hint how to go on? Or maybe someone knows a good tutorial which is not about "setting up domain classes, controllers with scaffold, adding data to your database" - I dont see so much sense in it.
Thanks for your help! :-)
[EDIT] Thanks for the answers! Services, that was exactly what I was looking for. I guess I simply must get more familiar with it. The tutorials were just confusing me, but now I understand better!
If you are familiar with Spring and Spring MVC, the concepts in grails should be no surprise to you. Grails actually uses Spring MVC under the covers.
Grails can auto-generate Domain classes, controllers and views as you have tried in tutorials. This is to give you a starting point for your application. This is often enough for those textbook tutorials. For real applications though, you may not always have 1 domain class to 1 controller to 1 set of views. You might not always be doing CRUD operations on that domain. For this, you need to dig a bit deeper into Grails. You can do everything you previously have done in Spring MVC in Grails!
Here are some links to help you get going.
If you are trying to understand the 'flow' better. How requests get mapped to controllers/views, check out the UrlMappings.groovy in your config directory. Docs on that are located here: URLMappings
If you are trying to understand controllers better, check out this: Controllers. Keep in mind that your controller do not need to work on domain models. That is simply the default convention. They work similar to a Spring MVC controller.
Models are simple in Grails. Typically the controllers just return a map of the items you want to return. In Spring MVC, you often create a Model object, most times in Grails you will return something like [name: bean1, name2: bean2]. This allows you to easily get those two beans in the vies.
Start with 'Grails In Action'. The first chapter would give you details about the CRUD Sample app creation , but on reading further you would understand the grails flow better. Services are to be used for the logic, Controllers are used for delegation. You dont need explicit xml mapping as is done in Struts, Spring because everything here works on Convention.
Here is info on controllers: Controllers
Also you can use the same manual to find information on other stuff. For example about where to put business logic you should read in The Service Layer chapter.
Read Beginning Groovy, Grails and Griffon by Vishal Layka, Christopher M. Judd, Joseph Faisal Nusairat and Jim Shingler. They are building a real web application throughout the book with models, database access, authentication, css, templates and layouts, and many other things.
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
If I know Rails, what new ideas/patterns would I learn if I looked at Grails?
I have no intention to move to Grails and no need for a Java stack, but if there are neat ideas I could learn from Grails I'd like to learn them.
Grails has taken totally different direction. It is very hard to compare Grails and Rails.
Grails is not framework. It is stack of frameworks. You can find all the features you find in plain Spring, Hibernate, Quartz, Compass, Sitemesh frameworks. So at the end you get all the best from all these frameworks with convention-over-configuration.
However, I really want to mention about very interesting idea introduced in Grails about modulizing the application into plugins. Plugin in Grails is minimized independent project. Separating application logics into plugins allows to share your code to community and keep application in separate modules which results in easier testing and easier development.
Grails has at least two patterns I'm aware of that I believe do not exist in Rails:
Command objects (and auto binding request params to them)
Conversation based request handling using web flows
I'm just starting to learn Rails. I created an empty Rails app. And instead of writing a Controller, I want to put all of my Controller logic in my Views instead of in separate Controller classes.
To do this, should I use .erb files or .rhtml files and what's the difference?
First of all, they are virtually the same thing but you should use the new standard naming format of .html.erb
Second of all, stop what you are doing and reconsider everything!!!!!
The whole point of MVC is to separate logic from display and vice versa. Most of your logic should be in your models and the controller should just facilitate grabbing that logic and passing it to your views.
You should not do anything in your views other than display the data.
"A client has asked me to build and install a custom shelving system. I'm at the point where I need to nail it, but I'm not sure what to use to pound the nails in.
Should I use an old shoe or a glass bottle?
In your case I'd go for the glass bottle.
In the new rails 3.0 .rhtml files will be unsupported. .html.erb is the new standard.
I understand that you have a small app and standards don't really apply to you, but that is the whole point of MVC. The logic should go into the controller/model and the view is strictly for presentation.
The simple answer to your question is no. No you shouldn't put controller logic in the views. If you don't need controllers then you probably don't need rails. I know that's not the answer you want, but frankly you are wrong, pure and simple. If you want to learn the Rails framework, then what you have been told here is correct and to do it your way would simply then mean either unlearning what you just did or it would mean becoming a bad developer.
That's the way it is, the rest is now up to you.
Yes, you are correct in that the creators of rails never stated that you should not use rails for smaller apps, but they have stated over and over the importance of the controller.
I created an empty Rails app. And instead of writing a Controller, I want to put all of my Controller logic in my Views instead of in separate Controller classes.
Just out of curiosity, what type of logic are you considering putting into your views? If it is presentation logic then that is one thing but if it is business rules, loading data from a database, xml file, web service/rest based then you are violating the core principles of rails. Ever heard of ASP (Classic Active Server Pages)? Frameworks have evolved beyond that to overcome the shortcomings and pitfalls like ASP to allow you not to mix presentation and code. If you jam it all together, how will you unit test your code? Another key principle of rails that is why it is built into the framework itself unlike other web frameworks.
I want to learn how to use the "standard" Ruby framework
In your responses you keep mentioning you want to learn the standard Ruby framework? If this is the case why don't you use irb then? Rails is not part of the standard Ruby framework. In fact you will probably learn a lot more about Ruby using irb then you will Rails. Once you have familiarized yourself with Ruby then take on rails.
I agree with the others and if you are going to take the time to learn a framework, then learn it right and as the creator intended, otherwise you are missing the point and you will not see why rails is such a good web framework to begin with. What you are hoping to accomplish can be done in a number of web technologies: ASP, ASP.Net, PHP, JSP, Perl, but you choose to learn Ruby and rails therefore do not do it the same as you could in any of the other web technologies.
Adhering to MVC is the way to proceed to build an application.
If you are uncertain why Controller is needed then do the research. I have
faced maintaining code where the scrips are embedded in the presentation layer.
It is farcical to begin any engineering effort without a thorough understanding
of the correct, time tested methodology. It is like trying to build a house
using no foundation or blueprint.
Nothing, really. It’s just a change of philosophy between Rails 1 and Rails 2. Before Rails 2, you had file.rhtml, file.rxml and file.rjs. In Rails, that changed to file.content_type.template_engine. So with file.html.erb, the content type is html and the template engine is ERb. rxml is now xml.builder and rjs should now (mostly) be js.rjs
In the new rails 3.0 .rhtml files will be unsupported. .html.erb is the new standard.