NetBeans To Include Some PrimeFaces CRUD Of Their Own

Kay Wrobel — Wed, 23 Oct 2013 14:42:08 -0000

A few months ago, I was contacted by a NetBeans team member regarding the CRUD generator and possibly contributing to the NetBeans project. The idea that was pitched was to create a public API that would make integrating code generators such as this easier and less dependent on the NetBeans implementation. That is of course since many parts of the generator depend on internal non-API modules from NetBeans, and more importantly some depend on the implementation version. That means, the CRUD generator is not portable between NetBeans version and not even within a release as things might change during updates.

Naturally, I like the idea and signed a Third-Party Contributor Agreement with Oracle. A few more months have passed now without hearing anything from said developer. So I asked for a quick status update. In reply, I was told that current resources are still spent on squashing bugs and issues in NetBeans, but that they already had modified their own JSF Pages generator to accomodate PrimeFaces. And so, the next major release of NetBeans (8.0) will contain PrimeFaces CRUD functionality built-in, inspired by this project.

At this point, I am quite curious as to the level of NetBeans' adoption of the PrimeFaces pages this generator creates. Particularly, since I recently added the ability to segregate the include files into separate folders. If the CRUD application NetBeans will generate is on par or even better than the one generated by this module, I may decide to put this project to rest. I don't want to, but it wouldn't make sense to have to pieces of code doing the same thing. And keeping up with the various NetBeans versions is a real pain, especially when things break due to internal API changes on their end.

So what do you think? Should this project continue, despite the fact that NetBeans will introduce their own PrimeFaces CRUD? Let me know in the comments section.

I'd like to take this opportunity to thank all of you developers out there who tried this module and found it useful for your projects.

Composite Key Highlights More Issues

Kay Wrobel — Wed, 06 Feb 2013 18:09:59 -0000

Hands in the air if your legacy database has at least one table with a composite key. Really? That many? Ok. Hands in the air if your legacy database has at least one composite key where a portion of it references another table's composite primary key. Oh yeah?

Well! Welcome to the club of old-timers that are still working daily with tried and true databases that have grown over decades of development, born in the seventies and eighties where composite keys were ubiquitous. Many thanks to hierarchical database systems that were then migrated to relational databases when they came around. I'm looking at you, Mr. ISAM and Mr. DB2 living in the world of MVS/ESA (If you recognize these, you are at least as old as I am).

And who has not used Natural Keys in their database design? Right? I mean, surrogate keys were kind of frowned upon because they really didn't add much value to the table other than eat up more space for the field and additional indexes that had to be created for those fields that uniquely identify the records. Storage was scarce and expensive then.

At this point I should probably open the polls for you to take a wild guess at my age. Hint: I started programming at age 17 and encountered aforementioned hierachical database system in my first work place. Go figure.

What does this have to do with this project you're looking at right now? Well, if you're like me, you might be involved in some medium or even larger scale evaluation of transporting your good ole' legacy system from the stone age into the modern age without sacrificing the underlying database design that has been so tried and true. Not to mention the Gigabytes of data it is housing. And now you've stumbled upon this code generator in NetBeans that generates JSF pages for you? Or maybe even this code generator that spits out PrimeFaces pages? Well then, go ahead and generate pages for your ole' legacy database then. See how it will fail!

Sorry for all the drama, suspense and sarcasm here, but I have once again run into a bug I believe, and its part of NetBeans' original JSF Pages from Entity Classes and/or the Entity Classes From Database wizards. Take a moment a read through the bug I filed with NetBeans. Walk through the test case as described there and then tell me right there that this is not a bug. Seriously, please contact me if I'm completely off on this one.

Now, if you read through all posts, I have managed to alleviate the problem by modifying one of the methods entity class that is responsible for setting the foreign entity object. And that is where I added lines for also setting the primary key fields of the @Embeddable key. This solves the problem quite nicely. But, it requires hand editing every entity class that is in this predicament. Now, if the foreign entity also has a composite key, this statement gets more complex as you have to set the field values of multiple key fields. Again, it is possible, but you need to know which key field of table A maps to which key field in table B. In fact, you don't need to know that, but the CRUD generator needs to know that.

But let's step back here for a second. The solution for me is to modify an entity. Stop right there. The CRUD generator does not generate those entities. That would be the *Entity Classes from Database` wizard's job. Unfortunately, I cannot modify any of the templates associated with that wizard. So that right there is a show stopper for me. After all, you are likely evaluating this wizard because you might have a huge database with lots and lots of master files that fit the bill for CRUD operation. But then you have to hand edit all those entity classes? No way.

Ok, so let me throw this idea out right here. There is another way this cat could be skinned. (No, I would never do that; I own two cats and they're alive still.) I am thinking of adding the necessary code to the individual Entity Controller class. Here is the idea; actually I've tried it and it works, too. I would like to add a valueChangeListener attribute to the <p:selectOneMenu> tag that is responsible for the drop-down of the externally referenced key. I would point it to a new valueChangeListener method inside the managed bean. E.g.:

EntityBController.java:

   public void entityAChanged(ValueChangeEvent e) {
       EntityA entityA = (EntityA) e.getNewValue();
       // Now also set the primary key fields here.
       current.getEntityBPK().setEntityAId(entityA.getEntityAPK().getId());
   }

entityB/Create.xhtml:

   <h:selectOneMenu id="entityA" value="#{entityBController.selected.entityA}"
                    title="#{bundle.CreateEntityBTitle_entityA}"
                    required="true" requiredMessage="#{bundle.CreateEntityBRequiredMessage_entityA}"
                    valueChangeListener="#{entityBController.entityAChanged}">
       <f:selectItems value="#{entityAController.itemsAvailableSelectOne}"/>
   </h:selectOneMenu>

This could work in the CRUD generator. I just need to be able to find out which @JoinColumn annotations a field has as these reveal the exact mapping.

Hey, thank for reading all this. I'm really just documenting my though process here, but I believe sharing these thoughts can also benefit others.

Motivation For Search Label Artifacts, GeneratedValue And ReturnType

Kay Wrobel — Sat, 26 Jan 2013 09:08:35 -0000

It's been a while since my last entry. A lot has happened since the initial release. I've learned a lot about the innards of the JSF pages wizard and how it gathers some of its information. And I found that it was also seriously lacking in many regards, which many people using it may have found out along the road. For example, there was a serious problem with auto-generated fields, at least for me. The Create.xhtml would not detect that a field was auto-generated and so would actually include the field as an input field with required="true", which would cause the JSF form to stop and not let the user proceed with an empty field. But that would be required to actually trigger the generation of a value inside the database. So I actually played around with the meta information that I can pass along to the templates, and generatedValue is one of the new features. The Create.xhtml template actually now suppresses an auto-generated field entirely.

Another shortcoming, in my opinion, was the lack of knowing inside the template what kind of data a field returns. For example, I wanted to generate a selectBooleanCheckBox if the entity field was of type Boolean and found out that I had no way of knowing that during the FreeMarker expansion process. So I added a new data point called returnType which is the fully qualified Java return type of an entity field. This opens up the possibility of maybe using other widgets in the future. I am thinking of generating a tag for a date-time picker if the return type is a date field. So that is coming up in a future release, but developers can already take advantage of that feature and modify their templates accordingly.

One of my biggest gripes I had with the original JSF pages wizard was how foreign keys were handled in drop-down lists and such. Drop-downs would always show this ugly, generated string that comes out of the toString() method of an entity. Since PrimeFaces drop-downs actually allow you to specify itemValue and itemLabel attributes, I found that it was time to be somewhat smart about this in a generator. What I wanted to accomplish is to provide the templates with a means to identify a foreign entity's display field based on a few terms the user can provide. In many of my own projects I found that the display field would either be description or name or something that includes these terms. Having the ability to search for those fields and then let the template automatically use those for the itemLabel attribute would be a nice touch and could again cut down on how much code a developer would have to modify after code generation was done.

Introducing the entityDescriptor.getRelationLabelName(String searchLabels) method. This method will take a string of comma-separated terms and loop through a foreign entity's list of field names to find a property that contains any of these terms. The templates are now all wired to incorporate this method call if the relationship is one-to-many or many-to-many. The String is being passed through to the templates via the new value searchLabels. To avoid the chance of calling getRelationLabelName multiple times, I also use FreeMarker's user variable feature via the <#assign> tag. I've tested this with the Derby SAMPLE database and the PRODUCT table. The list, view, create and edit dialogs now consistently translate the foreign key values to e.g. Cables for prodCode of "CS" or some manufacturer's name for the manufacturerid. I admit, that I am very satisfied with the result so far and hope that other developers find this a useful feature.

Source Code Uploaded

Kay Wrobel — Thu, 17 Jan 2013 20:41:26 -0000

I've taken the step of initializing a Git repository in my NetBeans project and committed all files to SourceForge. So all files are live right now. While testing, I also ran into a few issues that required documenting. See the Tickets section for a list. I'm happy that it was so easy to connect NetBeans with my SourceForge Git repo. Amazing! Didn't even have to touch the command line.

Anyway, I'm inviting everybody to take a look at the code this wizard spits out. Any way we can make it better, please leave suggestions in the discussion area. Also, it would be really nice if the default drop-down lists and fields that point to a foreign entity wouldn't just show the toString of the entity, which is really ugly. If only I could specify some default fields to be used for drop-down lists.

Going Public - A Much Needed PrimeFaces CRUD Generator for NetBeans

Kay Wrobel — Thu, 17 Jan 2013 08:44:46 -0000

NetBeans is a very cool and sophisticated development environment for Java developers and supports many nice features. One of the cooler tools that I found useful ever since its conception is the "JSF From Entity Classes" wizard. It generates an entire web application simply by selecting Entity Classes, and the application is deployable and usable out of the box. That is, until AJAX and many nice AJAX-capable widget libraries hit the scene, not the least of which is PrimeFaces by Prime Teknoloji.

Netbeans has been providing support for PrimeFaces since at least version 7.2 right from within the new Web Application wizard where users can pick from PrimeFaces, RichFaces and IceFaces. However what was apparently lacking was proper support for the actual widgets these libraries provide. So the JSF from Entity Classes wizard still produces JSF pages one for each entity and action, whereas I had envisioned something that is more like a native GUI app with menus and pop-up dialogs. That is when I stumbled across Emre Simtay's blog entry and his sample app. That's exactly what I had in mind for a basic CRUD operation in PrimeFaces.

So with new knowledge found and greatly inspired, I set out to find a way to use the facilities NetBeans has to offer and let the Wizard produce PrimeFaceified pages I quickly found that simply modifying the templates was not enough. I needed a few more pages, had a different structure for the JSF backing beans, which I now abtracted similar to the Entity Facade patter the wizard already created. Ultimately, I downloaded Netbeans 7.2.1 source code distribution and started analyzing and eventually modifying code. Problem was: the code was part of a core plugin: JSF Support.

Thanks to the Netbeans developer list and in particular Geertjan Wielenga who helped me set up a module shell for this project, I was able to produce a new wizard that looks exactly like the original, but uses my modified code to spit out PrimeFaces JSF pages. Thank you Geertjan and Emre for being such an inspiration.

I should note that the current code as of this writing is still in development and testing phase, as for example there is currently no CRU(D)elete option which I had removed from Emre's original design because I felt that deleting records is really not such a good idea in general. But I am will most likely add this back into the wizard and maybe make it an option. Or maybe I will make an option for each function on the wizard to make it more flexible. Just a thought here.

Enough said, this is also my first ever project and I decided to share it right here on SourceForge those interested to check it out.

I will provide some basic instructions for getting the wizard to run in your IDE, which currently requires you to open this module in NetBeans compile and run it which opens up a new instance of NetBeans where the wizard is then available. The module hassome dependencies that currently prevent it from being installed as an NBM plugin. Until I figure out a way around those dependeny restrictions, this is the way it has to be.

Please, feel free to comment on this project, give feedback and let me know how you like it, how useful you think it is and we'll see where this project will be heading in future.

For now, enjoy!

Recent posts to blog

NetBeans To Include Some PrimeFaces CRUD Of Their Own

Composite Key Highlights More Issues

Motivation For Search Label Artifacts, GeneratedValue And ReturnType

Source Code Uploaded

Going Public - A Much Needed PrimeFaces CRUD Generator for NetBeans