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 247926 - Separate template creation from loaders
Summary: Separate template creation from loaders
Alias: None
Product: platform
Classification: Unclassified
Component: Data Systems (show other bugs)
Version: 8.1
Hardware: PC Linux
: P2 normal (vote)
Assignee: Svata Dedic
Depends on:
Blocks: 248418
  Show dependency tree
Reported: 2014-10-14 14:14 UTC by Svata Dedic
Modified: 2017-04-08 03:06 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Proposed changes (121.35 KB, patch)
2014-10-14 14:14 UTC, Svata Dedic
Details | Diff
Updated changes (295.90 KB, patch)
2014-10-27 13:32 UTC, Svata Dedic
Details | Diff
Revised patch (Y11) + dependencies solved. (1.11 KB, patch)
2014-11-11 08:48 UTC, Svata Dedic
Details | Diff
Correct diff v3 (280.95 KB, patch)
2014-11-11 09:02 UTC, Svata Dedic
Details | Diff
template v4 (284.19 KB, patch)
2014-11-11 14:57 UTC, Svata Dedic
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Svata Dedic 2014-10-14 14:14:24 UTC
Created attachment 149897 [details]
Proposed changes

Template file creation is now included in openide.loaders module, but it only barely depends on loaders infrastructure. Since the feature is usable for a system without Data Systems library, it could be separated into its own module.

The patch shows a new openide.filesystems.templates module, with utility API class that allows to create a file based on template. Existing features, template handlers and attribute providers are preserved.

1/ CreateFromTemplateAttributeProvider is deprecated in favour of (new) CreateFromAttribute interface, which works with FileObjects rather than DataObjects. Datasystems module provides a compatibility bridge for old attribute providers.

2/ CreateFromTemplateHandler in DataSystems API is deprecated in favour of CreateFromTemplateHandler in netbeans.api.templates package

3/ TemplateProcessor is split into two parts; the part in filesystems.template handles the creation of the template file with the proper contents. The part in Datasystems API handles the wizardIterator attribute -- template wizard directly depends on openide.dialogs and other stuff from openide.loaders

4/ Existing DataObject/Entry code is updated to use TemplateUtils.
Comment 1 Svata Dedic 2014-10-14 14:21:25 UTC
Important note: 

the template code does *not* use org.openide.text.IndentEngine API. It is long deprecated in favour of org.netbeans.modules.editor.indent.api package.

The backward compatibility is half-working right from the introduction of the indent.api package: there's a bridge in editor module, which adapts new Indent API calls for old clients in a form of (deprecated) IndentEngine. However there's no forward bridge, so new clients that work with indent.api package CAN NOT use indenters implemented against the (deprecated) openide.text IndentEngine.
*IndentEngine is deprecated since 10/2008* (6 years).

For some cases, the indentation still worked, since a lot of code was not updated, so it still used (deprecated) openide.text APIs, most notably Data Systems implementation (create from template) and Java source (create from template). This is now changed, so create from template may STOP working if the indenter for the template file MIME type is implemented against openide.text IndentEngine.
Comment 2 Jaroslav Tulach 2014-10-14 15:08:06 UTC
Y01 Don't introduce new openide.* module. Use org.netbeans.api.templates, that is what we always wanted to do.

Y02 The usecases in arch.xml are insufficient. If nothing else, please copy the usecases from openide.loaders (and update the old ones) - I believe template handling is the only described usecases in openide.loaders/arch.xml

Y03 I don't understand why you are creating the new CreateXYZ interfaces, but maybe the answer will be clear after Y02 is addressed.
Comment 3 Svata Dedic 2014-10-14 17:09:27 UTC
re. Y03: CreateFromTemplateAttributeProvider references DataObject (template) and DataFolder (target folder). I cannot use this one. 
I need not to create a new CreateFromTemplateHandler, strictly speaking. The existing one can be migrated from to the new module, so org.netbeans.api.templates would contain  CreateFromTemplateHandler in the org.openide.loaders package. If it is better from the API design point of view, I'll change the code.
Comment 4 Jaroslav Tulach 2014-10-15 10:24:05 UTC
(In reply to Svata Dedic from comment #3)
> re. Y03: I cannot use this one. 
> I need not to create...

Do what you want, but please provide an alternative (possibly enriched) to
so I know what you are trying to do (requested as Y02).
Comment 5 Svata Dedic 2014-10-27 13:32:35 UTC
Created attachment 150133 [details]
Updated changes

Please review the 2nd version; Y01-2 are addressed. I'm not sure if use-cases are sufficient to address Y03.

Note that this version has a completely different API - the change was based on a offline suggestion to provide a Builder-like interface rather than bazillion-parameter utility method (thanks, Jardo).
Comment 6 Jaroslav Tulach 2014-11-03 12:45:12 UTC
Y11 If possible, stick with FileBuilder (or TemplateBuilder?) and hide TemplateUtils.

Y12 IndentWriter depends on Swing's Document. Was not the goal to get rid of Swing interfaces? Why not modify reformat to work on something else than document?
Comment 7 Svata Dedic 2014-11-03 14:02:29 UTC
Y11: OK

Y12: I supposed that dependency on Swing APIs could be acceptable (at least it is for the intended non-GUI processing). Making indent API document-independent is a nice idea, but this dependency IMHO does not directly surface on the template API level. It does, indirectly, by depending on editor.document API. I would recommend to leave the dependency as it is, and plan for the indent API change in the future.
Comment 8 Jaroslav Tulach 2014-11-03 14:16:35 UTC
Re. Y12: I see. OK.
Comment 9 Jaroslav Tulach 2014-11-05 09:38:14 UTC
Keeping just API_REVIEW_FAST. When one week timeout occurs, go on and integrate.
Comment 10 Svata Dedic 2014-11-11 08:48:47 UTC
Created attachment 150414 [details]
Revised patch (Y11) + dependencies solved.

I realized that I made a beginner's mistake: introduced a dependency from platform to editor cluster. Based on some brainstorming, I've introduced a friend API - a special script engine. Plus addressed Y11 (TemplateUtils are gone).
Comment 11 Svata Dedic 2014-11-11 09:02:36 UTC
Created attachment 150416 [details]
Correct diff v3
Comment 12 Jaroslav Tulach 2014-11-11 11:46:07 UTC
Y21 It would be better to not have broken links in Javadoc. For example "any module to intercept calls to {@link DataObject#createFromTemplate}" is unlikely to render correctly, as templates will no longer have a dependency on DataObject, right?

Y22 Isn't it better to replace FREE_FILE_EXTENSION constant with a boolean getter on CreateDescription?

Otherwise probably OK.
Comment 13 Svata Dedic 2014-11-11 14:57:57 UTC
Created attachment 150433 [details]
template v4

Y21,22 addressed. I've documented the property parameters (freeFileExtension, preformatted) as they are used by template providers already.
Comment 14 Quality Engineering 2014-11-21 03:50:57 UTC
Integrated into 'main-silver', will be available in build *201411210001* on (upload may still be in progress)

User: Svata Dedic <>
Log: #247926: separated template creation from loaders
Comment 15 Quality Engineering 2017-04-08 03:06:01 UTC
Integrated into 'main-silver', will be available in build *201704080002* on (upload may still be in progress)

User: Alexander Simon <>
Log: Fixed Bug #247926 Separate template creation from loaders