I am new to vaadin and JPA containers.
I've read both tutorials here:
https://vaadin.com/book/-/page/jpacontainer.usage.html
and here:
https://vaadin.com/download/jpacontainer-tutorial/#__RefHeading__3056_1659804707
And neither makes sense to me.
Can anyone out there break this stuff down for me in layman's terms:
This is how you make a container.
Then you put this grid in the container.
Then the container is sent to the database like this.
If we can start with one simple CRUD grid that saves someone's name, for example, I think I would be able to build off of that.
But these tutorials bring in so many new classes, terms, and methods at once, I can't make any sense of it.
Thanks in advance!
If you want to use JPA with Vaadin, there are much better ways to do that than to use JPAContainer. Build a facade (e.g. an EJB) like you would do with other Java apps and bind the entities and basic lists of entities with Vaadin components.
See my rant about this for more details.
Related
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.
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
I'm new to Grails and web development. I started doing a project on Schedule management website stuff. I came across the Service concept that is provided by Grails. I understood the concept, but still I have confusion on when to use services.
For example, I need to implement a search module, where the manager can search for a user to find his schedules. In this case it will be good to implement it as a controller or as a service?
So,
When and where should I use Service?
To add to Grooveek's answer;
It is also nice to use Services to keep your Controllers nice and clean.
So Views just render data to the screen, Domain objects store state, Controllers route the user around the application, and Services perform the work.
I don't have enough reputation to comment on an answer or vote up so I have to provide an answer that really should be a comment. Anyways...
+1 on #tim_yates answer. Gotta love thin controllers. 2 things that I would add to the description of a controller:
Would be to translate parameters from the browser before hitting a service (e.g. Date, number, etc.)
Would be to translate data returned from services into something consumable for the views.
For me, ideally, services would never deal with translating a String parameter to it's inherent type. Or deal with building a model to be displayed on a view.
What and where I should use Service?
When you want your controller do to something that may be reused by other controllers
In our application we're doing a functional separation of service. We have a CorePersistanceService, which provides method to create, delete, update and manipulate Core Domain Classes (core for us).
I think persistance services are a good way to reuse GORM code throughout Grails code. You can create method in domain classes, but I don't like that, it's way less maintanable I think
We have a PDFService class for our PDF creation, a SolrService which connect to Solr, a Statisticservice that gather all our methods which collects statictics on our datas
Services in Grails are a manner to gather methods around a particular functional theme, in order to give possibility to reuse them in controllers (I forgot to mention our SecurityService, which is a pretty good Cross-Applications Example)
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.
I recently started reading about ASP.net MVC and after getting excited about the concept, i started to migrate all my webform project to MVC but i am having a hard time keeping my controller skinny even after following all the good advices out there (or maybe i just don't get it ... ).
The website i deal with has Articles, Videos, Quotes ... and each of these entities have categories, comments, images that can be associated with it. I am using Linq to sql for database operations and for each of these Entities, i have a Repository, and for each repository, i create a service to be used in the controller.
so i have -
ArticleRepository
ArticleCategoryRepository
ArticleCommentRepository
and the corresponding service
ArticleService
ArticleCategoryService ...
you see the picture.
The problem i have is that i have one controller for article,category and comment because i thought that having ArticleController handle all of that might make sense, but now i have to pass all of the services needed to the Controller constructor. So i would like to know what it is that i am doing wrong. Are my services not designed properly? should i create Bigger service to encapsulate smaller services and use them in my controller? or should i have an articleCategory Controller and an articleComment Controller?
A page viewed by the user is made of all of that, thee article to be viewed,the comments associated with it, a listing of the categories to witch it applies ... how can i efficiently break down the controller to keep it "skinny" and solve my headache?
Thank you!
I hope my question is not too long to be read ...
This is the side effect of following the Single Responsibility Pattern. If each class is designed for only one purpose, then you're going to end up with a lot of classes. This is a good thing. Don't be afraid of it. It will make your life a lot easier in the long run when it comes to swapping out components as well as debugging which components of your system aren't working.
Personally, I prefer putting more of my domain logic in the actual domain entities (e.g. article.AddComment(comment) instead of articleCommentService.AddComment(article, comment)), but your approach is perfectly fine as well.
I think you are headed in the right direction. The question is how to instantiate your services? I'm no MVC.NET guru, but have done plenty of service oriented Java projects and exactly the pattern you are discussing.
In Java land we would usually use Spring to inject singleton beans.
1) You can do the same thing in .NET, using dependency injection frameworks.
2) You can instantiate services as needed in the method, if they are lightweight enough.
3) You can create static service members in each controller as long as you write them to be threadsafe, to reduce object churn. This is the approach I use in many cases.
4) You can even create a simple, global service factory that all controllers access, which could simply be a class of singletons.
Do some Googling on .NET dependency injection as well.