This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 155214 - Wizard needed for db access
Summary: Wizard needed for db access
Status: NEW
Alias: None
Product: apisupport
Classification: Unclassified
Component: Templates (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker with 11 votes (vote)
Assignee: Martin Kozeny
URL:
Keywords:
Depends on: 146402
Blocks:
  Show dependency tree
 
Reported: 2008-12-11 11:18 UTC by Geertjan Wielenga
Modified: 2013-02-14 13:17 UTC (History)
7 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Geertjan Wielenga 2008-12-11 11:18:27 UTC
In the same way as a JSR 296 application, with a connection to a db, can be created via a project template, there should
be a template that does the same for the NetBeans Platform. It would be a NetBeans Platform application project template
called "Database CRUD Application", the template would let the user select a db connection, and then a JPA-based
application would be created, including best practices for such an application (i.e., maybe the application would be
created with more than one module, maybe JSR 295 would be used for beans binding).

The user should not have to reinvent the wheel (or use a tutorial or something) every time they want to implement this
completely standard requirement. Plus, having this template would be a BIG "selling point" for the NetBeans Platform.
Comment 1 Geertjan Wielenga 2009-01-17 14:05:13 UTC
Here's an example of what would need to be generated by this module (not very much):

http://netbeans.dzone.com/news/eclipselink-netbeans-platform

Basically, we need to take the existing JSR-296 Swing Framework CRUD generator and let it generate NetBeans Platform
code instead, similar to the code discussed in the blog entry above (that's a very simple case but at least gets the
user somewhere beyond zero).
Comment 2 mikiglvt 2009-01-18 00:15:59 UTC
Thanks for the quick report. Now that we are into it, I would also like to suggest making the Collection, Set or List choices for the JPA entities creation wizard 
a little bit more flexible. For example, by allowing to specify any class implementing the required interface (Collection?) in the project's classpath. For 
example, something I sometimes do is generate from NB IDE and then edit the code to use the ObservableList from Beans Binding. 

I'll be nice to be able to accomplish that from within the wizard itself. 
Comment 3 jasondrums 2011-12-08 19:22:05 UTC
I found out why the Persistence templates are not available under Netbeans Module projects. For those of you who want to know read on… Otherwise skip this lengthy email. 
 
It has to do with a RecommendedTemplates definition for each project and the templateCategory of the registered template wizard.
 
In my case the j2ee.persistence templates all have a templateCategory called out as “persistence”. If none where provided then they would have been shown for all types of projects. Furthermore, the recommended types for a NB module project do NOT include the “persistence” category which is why it excludes these templates for the module projects.
 
So it seems the easy fix would be to add “persistence” to the list of recommended types on the apisupport.ant project.
 
Extract from layer.xml file in j2ee.persistence package:
<filesystem>
    <folder name="Templates">
        <folder name="Persistence">
            <file name="Entity.java">
                <attr name="template" boolvalue="true"/>
                <attr name="position" intvalue="100"/>
                <attr name="instantiatingIterator" methodvalue="org.netbeans.modules.j2ee.persistence.wizard.entity.EntityWizard.create"/>
                <attr name="templateCategory" stringvalue="persistence"/>
                <attr name="templateWizardURL" urlvalue="nbresloc:/org/netbeans/modules/j2ee/persistence/ui/resources/EntityEJB.html"/>
                <attr name="SystemFileSystem.localizingBundle" stringvalue="org.netbeans.modules.j2ee.persistence.wizard.entity.Bundle"/>
                <attr name="SystemFileSystem.icon" urlvalue="nbresloc:/org/netbeans/modules/java/resources/class.gif"/>
            </file>
 
Extract from NbModuleProject.java in apisupport.ant package (note it doesn’t not contain “persistence”):
        private static final String[] RECOMMENDED_TYPES = {
            "java-classes",         // NOI18N
            "java-main-class",      // NOI18N
            "java-forms",           // NOI18N
            "java-beans",           // NOI18N
            "oasis-XML-catalogs",   // NOI18N
            "REST-clients",         // NOI18N
            "XML",                  // NOI18N
            "ant-script",           // NOI18N
            "ant-task",             // NOI18N
            "junit",                // NOI18N                    
            "simple-files",         // NOI18N
            UIUtil.TEMPLATE_CATEGORY,
        };
 
Extract from J2SEProject.java in java.j2seproject package:
        private static final String[] APPLICATION_TYPES = new String[] {
            "java-classes",         // NOI18N
            "java-main-class",      // NOI18N
            "java-forms",           // NOI18N
            "gui-java-application", // NOI18N
            "java-beans",           // NOI18N
            "persistence",          // NOI18N
            "oasis-XML-catalogs",   // NOI18N
            "XML",                  // NOI18N
            "ant-script",           // NOI18N
            "ant-task",             // NOI18N
            "web-service-clients",  // NOI18N
            "REST-clients",         // NOI18N
            "wsdl",                 // NOI18N
            // "servlet-types",     // NOI18N
            // "web-types",         // NOI18N
            "junit",                // NOI18N
            // "MIDP",              // NOI18N
            "simple-files"          // NOI18N
        };
 
And finally and extract from OpenProjectList.java in projectui package that shows how it relies on the pair of templateCategory and recommended types to determine whether they are listed in the New File Wizard:
    static boolean isRecommended (Project p, FileObject primaryFile) {
        if (getRecommendedTypes (p) == null || getRecommendedTypes (p).length == 0) {
            // if no recommendedTypes are supported (i.e. freeform) -> disaply all templates
            return true;
        }
        
        Object o = primaryFile.getAttribute ("templateCategory"); // NOI18N
        if (o != null) {
            assert o instanceof String : primaryFile + " attr templateCategory = " + o;
            boolean ok = false;
            for (String category : getCategories((String) o)) {
                if (Arrays.asList (getRecommendedTypes (p)).contains (category)) {
                    ok = true;
                    break;
                }
            }
            return ok;
        } else {
            // issue 44871, if attr 'templateCategorized' is not set => all is ok
            // no category set, ok display it
            return true;
        }
    }
 
    private static String[] getRecommendedTypes (Project project) {
        if (project == null) {
           return null;
        }
        RecommendedTemplates rt = project.getLookup().lookup(RecommendedTemplates.class);
        return rt == null ? null :rt.getRecommendedTypes();
    }
    
    private static List<String> getCategories (String source) {
        ArrayList<String> categories = new ArrayList<String> ();
        StringTokenizer cattok = new StringTokenizer (source, ","); // NOI18N
        while (cattok.hasMoreTokens ()) {
            categories.add (cattok.nextToken ().trim ());
        }
        return categories;
    }
Comment 4 Jesse Glick 2011-12-08 19:31:04 UTC
(In reply to comment #3)
> it seems the easy fix would be to add “persistence” to the list of
> recommended types on the apisupport.ant project.

Yes, the fix is trivial. The work is in testing that all of the templates in that category in fact work as advertised in NBM projects.
Comment 5 Jesse Glick 2011-12-08 19:32:51 UTC
Note that this issue as originally reported was for a template in the New Project wizard, though adding the Persistence category into the New File wizard for NBM projects would be a sensible related change.
Comment 6 Jiri Rechtacek 2011-12-09 07:14:26 UTC
I think it's a task for j2ee/persistence rather than db.
Comment 7 Sergey Petrov 2011-12-09 15:18:40 UTC
To enable persistence for specific project type it's not enough just to add persistence category, corresponding project should implement some persistence providers, listeners etc (scopelistener etc, it's easy to compare with j2se project for example to see what is implemented for persistence support). Not sure who should be responsible for the issue, at least there should be some cooperation with project owner to get proper resources location etc or even easier for project owner to implement everything.
Comment 8 Sergey Petrov 2011-12-09 15:23:07 UTC
agree it's not db task anyway
Comment 9 Jesse Glick 2011-12-09 16:08:59 UTC
Afraid as project owner I know nothing about the APIs involved; not even sure how to really test that they are working correctly if they were to be implemented. I see org.netbeans.modules.java.j2seproject.J2SEPersistenceProvider but this looks rather complicated; probably this should be factored into java.api.common for ease of reuse from other Ant-based project types? (org.netbeans.modules.web.project.WebPersistenceProvider looks very similar but they are not identical; it is unclear whether the differences are intrinsic, or just a result of bugs being fixed in one but not the other.)
Comment 10 Sergey Petrov 2011-12-09 20:32:08 UTC
One more persistence support implementation sample is maven.persistence module.

Can't say much regarding difference yet. It may have sense to refactor persistence providers implementation into one place as it seems to contain a lot of duplication.
Comment 11 Jesse Glick 2011-12-10 12:56:26 UTC
(In reply to comment #10)
> One more persistence support implementation sample is maven.persistence module.

Right, I intentionally skipped over that since it can be assumed to be a quite different implementation, whereas Ant-based projects typically have large commonalities in service implementations. In the case of the persistence services it looks like these were introduced - and blindly copied around - before java.api.common was in use.