I'm pretty new to PrimeFaces and I'd need to setup a basic CRUD User Interface. From the showcase I can see there is a built-in Datatable parameter named editable to enable editing. I wonder if there is any built-in feature to enable also Adding and Deleting items.
If not, what would be the simplest way to achieve it ? Maybe using a Dialog component to collect the new items ?
Thanks
The simplest way to get a CRUD would be to reverse engineer it. Create your tables in a database and in Netbeans 7 or 8 (I use 8) create
Entity classes from database
JSF pages from entity classes
During the second point you can choose between Primefaces and plain JSF. If you prefer, you could also skip the first point and code the entity classes yourself instead, and tell the server to create the tables on start.
This will get a full CRUD running, complete with theming, menustructure and templating, using primefaces, facelets, beans, custom entity converters, EJB's, entities and JPA.
I like most of the generated code quite well and there is a lot to learn from it as a beginner. The result is a full page for the list and dialogs (via ui:include's) for create, view and edit.
I'd think Eclipse has something similar.
Related
Good Morning,
as from the title, i'd like to create a proprietary database to be integrate in a Typo3 website.
I'd like to receive some advise on which is the best solution:
- is it possible to create tables directly from Typo3?
- is it better creating a database, for example with MySQL and then integrate
it?
In the second case, how coud that be done?
are there other options?
I hope this is not an already answered topic, in case, please send me to it ( i could not find so much information.
Thanks in advance.
If I understand your question correctly, you want to add a custom Extension to TYPO3, containing custom tables. From a content side, this is perceived as a "database", right?
TYPO3 has a framework for that called Extbase. You can "kickstart" a TYPO3 extension with the "Extension Builder" https://typo3.org/extensions/repository/view/extension_builder by entering the "Model" (the data structure) via GUI and then you get all tables etc. automatically set up.
After that (aside from general TYPO3 knowledge), there is some coding involved. In theory, it's possible to make a "round trip" back to the extension builder from the code, but I've never done that.
You need to know / learn the specificities of extbase / php, which is is based on some "convention over configuration" rules and has some additional tweaks to plain PHP (functional comments). Here's a great resource: http://www.extbase-book.org/.
With that, you have great flexibility and powerful tooling to build almost anything inside TYPO3.
From a TYPO3 view it is best if you are able to hold your data in the TYPO3 database. You need to create an extension to handle your data. In TYPO3 an extension can define it's own tables and with updates of the extension updates in the datastructure are handled automatically.
Since version 8 there is a new layer (doctrine) and so it is possible to define further databases for individual tables. With some restrictions you are able to even use different database (-systems) for different tables.
Anyway you could program your own database interface to get and store your data independent from any TYPO3 restrictions, but then you need to handle everything on your own.
Using the TYPO3 core API will help you in multiple ways to handle your data without programming everything anew.
Especially if you use extbase (and the EXT:extensionbuilder) you will get a complete BE data handling, FE-Plugins with Fluid templates to present your data, even data management from the FE could be generated for you just by defining the datastructure. Of course versioning, workspace and timed visibility support are also available if you use TYPO3 structures which includes some (mostly invisible) fields aside from uid, hidden, deleted.
I have created a J2EE project, Now I want to generate CRUD from MYSQL.
Here is one option that looks fine by using JSF Generating a JavaServer Faces 2.x CRUD Application from a Database.
My question is "Would this work with the existing code and navigation stuff?"
OR
Is there any other technique to generate CRUD code from MYSQL database automatically?
If you migrate to JSF, you'll have to replace all JSP pages with JSF pages; and all servlets with ManagedBeans. Navigation, and everything related to the view is handled by JSF too.
If you already have many pages and servlets coded, and your only motivation of using JSF is to generate CRUD automatically, then I suggest that you create CRUD manually using the same technology you are currently using. On the other hand, using a framework makes things much easier for web development, so it's not a bad idea to use one. Other than JSF, you could use Spring MVC.
With the new version of VS 2013 RTM and asp.net mvc 5.0, I’ve decided to try out a few things...
Needless to say, a lot has changed. For example, the new ASP.NET Identity is a replacement of the old Membership and (less old) SimpleMembership APIs.
In all previous applications I’ve built, I never had the chance to work with Membership or with SimpleMembership. I’ve always ended up creating my own Login() method which would convert a submitted ViewModel to a POCO (using automapper) which in turn, would use some sort of repository to lookup the user and password.
In return, I would obtain a User POCO that would later be converted (using automapper) to a smaller UserSession POCO. The smaller UserSession would be place in Session.
Of course, I would still use FormsAuthentication to create an Encrypted Ticket and use FormsAuthentication.SignOut() when the user wanted to logoff.
But I never fully took advantage of what Membership (or SimpleMembership) had to offer.
I never had my POCOs implement some sort of Interface nor did I have to add a reference to the Microsoft’s libraries inside my POCO class library. In other words, I never had a strong dependency on anything.
My question is the following:
With the examples I see, I keep seeing that the new ASP.NET Identity creates (via code first) some tables and fields. For example, the AspNetUsers table holds an Id field as a string. Of course, I’m sure there is a way to overcome this and will eventually see examples, but why would anyone NOT want to build pure POCO classes and have total control of what and how things are created?
Unless I’m confused (which has a high probability) can anyone explain why I would want to use the new ASP.NET Identity API (or more importantly, use the new Microsoft.AspNet.Identity.EntityFramework) to create my tables?
What are the Pros and Cons in wanting to use this as opposed to the POCO style of things?
Perhaps I should be asking this in a different question, but I’m also trying to understand how can I benefit the new claims-based Identity while using POCOs instead of Entities generated with ASP.NET Identity.
Feel free to point me in the right direction for clarifications.
you can create your own UserManager completely,wich i don't recommand unless you have a strong knowledge about how it works.you can wrap the existing UserManager and make you application rely on an interface or just use it directely and benefit from what microsoft has put in it.if you don't like EF you can create your own Store to use another Database. the new ASP.NET Identity is extensible enough,i agree that is kinda Hard if you want to take full controle and customize everything,but i recommand taking time to understand the most of it so you can choose when to use or not.most of time it's enough to use the existing UserManager.
You want the UserManager from Microsoft.AspNet.Identity to do your security part such your users do not have to trust that you can handle your security information correctly.
Identity.Framework is just a datastore for the Identity stuff, you could create your own store instead if you dont want EF. I have created one that just stores information directly in a xml file. But I always come back to using Identity because I dont want to deal with encrypting and making sure I am up to date with stuff in the security department.
I am using Netbeans IDE for my project, I have created a jframe class, and from the design view I put a panel, on which I have put a jlist.
I want to get the names of the databases from MySQL dynamically on to this jlist.
How can I do that?
Your JList is available as a variable inside your form class - just use, e.g.
jList1.getModel()....
and do what you want.
But there are database-viewing components for Swing, which will probably be easier than rolling your own database code (remember to close your PreparedStatements and ResultSets if you do).
First a bit about the environment:
We use a program called Clearview to manage service relationships with our customers, including call center and field service work. In order to better support clients and our field technicians we also developed a web site to provide access to the service records in Clearview and reporting. Over time our need to customize the behavior and add new features led to more and more things being tied to this website and it's database.
At this point we're dealing with things like a Company being defined partly in the Clearview database and partly in the website database. For good measure we're also starting to tie the scripting for our phone system into the same website, which will require talking to the phone system's own database as well.
All of this is set up and working... BUT we don't have a good data layer to work with it all. We moved to Linq to SQL and now have two DBMLs that we can use, along with some custom classes I wrote before I'd ever heard of Linq, along with some of the old style ADO datasets. So yeah, basically things are a mess.
What I want is a data layer that provides a single front end for our applications, and on the back end manages everything into the correct database.
I had heard something about Entity Framework allowing classes to be built from multiple sources, but it turns out there can only be one database. So the question is, how could I proceed with this?
I'm currently thinking of getting the Linq To SQL classes all set for each database, then manually writing Linq compatible front ends that tie those together. Seems like a lot of work, and given Linq's limitations (such as not being able to refresh) I'm not sure it's a good idea.
Could I do something with Entity Framework that would turn out better? Should I look into another tool? Am I crazy?
The Entity Framework does give a certain measure of database independence, insofar as you can build an entity model from one database, and then connect it to a different database by using a different entity connect string. However, as you say, it's still just one database, and, moreover, it's limited to databases which support the Entity Framework. Many do, but not all of them. You could use multiple entity models within a single application in order to combine multiple databases using the Entity Framework. There is some information on this on the ADO.NET team blog. However, the Entity Framework support for doing this is, at best, in an early stage.
My approach to this problem is to abstract my use of the Entity Framework behind the Repository pattern. The most immediate benefit of this, for me, is to make unit testing very simple; instead of trying to mock my Entity model, I simply substitute a mock repository which returns IQueryables. But the same pattern is also really good for combining multiple data sources, or data sources for which there is no Entity Framework provider, such as a non-data-services-aware Web service.
So I'm not going to say, "Don't use the Entity Framework." I like it, and use it, myself. In view of recent news from Microsoft, I believe it is a better choice than LINQ to SQL. But it will not, by itself, solve the problem you describe. Use the Repository pattern.
if you want to use tools like Linq2SQl or EF and don't want to have to manage multiple DBMLS (or whaetever its called in EF or other tools), you could create views in your website database, that reference back to the ClearView or Phone system's DB.
This allows you to decouple your web site from their database structure. I believe Linq2Sql and EF can use a view as the source for an Entity. If they can't look at nHibernate.
This will also let you have composite entities that are pulled from the various data sources. There are some limitations updating views in SQL Server; however, you can define your own Instead of trigger(s) on the view which can then do the actual insert update delete statements.
L2S works with views, perfectly, in my project. You only need to make a small trick:
1. Add a secondary DB table to the current DB as a view.
2. In Designer, add a primary key attribute to a id field on the view.
3. Only now, add an association to whatever other table you want in the original DB.
Now, you might see the view available for the navigation.