Bug 226413 - Fold API enhancements
Fold API enhancements
Status: RESOLVED FIXED
Product: editor
Classification: Unclassified
Component: Code folding
7.4
PC Linux
: P2 (vote)
: 7.4
Assigned To: Svata Dedic
issues@editor
: API, API_REVIEW_FAST
: 216456 (view as bug list)
Depends on: 226111 226122 226368 226877
Blocks: 169234 142711 157468 157709 169660 206854 227366
  Show dependency treegraph
 
Reported: 2013-02-20 15:52 UTC by Svata Dedic
Modified: 2013-04-12 09:36 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Proposed changes (845.88 KB, patch)
2013-02-20 15:52 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 2013-02-20 15:52:10 UTC
Created attachment 131623 [details]
Proposed changes

This API change attempts to support several enhancements for extending fold types. It also adopts patterns found in fold providers (java, csl) to the base API, which should simplify the FoldManager implementations.

For more details/overview of the change, please see wiki: http://wiki.netbeans.org/CodeFoldingChanges201302

The attached changeset is cummulative with changes proposed for the issues dependent (changes in editor mime lookup, settings, ...).
Comment 1 Martin Janicek 2013-02-21 13:35:35 UTC
Svato, not sure if I understand everything correctly, but does this affect existing CSL clients somehow? I mean with the new API is there a better/new/easier way how to implement fold management for certain CSL languages different than implementing StructureScanner.fold() method?
Comment 2 Svata Dedic 2013-02-21 13:41:15 UTC
Sorry; I'll extend the wiki page with CSL explanation. API for CSL clients is NOT affected (formally), and if the CSL-based module remains unchanged, nothing happens.

But if a FoldType is registered (using the new APIs) with 'code' property that match the CSL fold type (key in map returned by SS.fold()) - that FoldType will be used to construct folds.

So if a CSL-based language registers its FoldTypes, UI for auto-folding will appear for that language, the placeholder text (in FoldTemplate) can be defined, and ContentReader (for variable placeholder text) can be registered.

The "good" news is that the diff contains already adjustments for PHP and HTML. JS should be easy, too.
Comment 3 Martin Janicek 2013-02-21 15:04:26 UTC
(In reply to comment #2)
> Sorry; I'll extend the wiki page with CSL explanation. API for CSL clients is
> NOT affected (formally), and if the CSL-based module remains unchanged, nothing
> happens.

Awesome, thanks..

> But if a FoldType is registered (using the new APIs) with 'code' property that
> match the CSL fold type (key in map returned by SS.fold()) - that FoldType will
> be used to construct folds.
> 
> So if a CSL-based language registers its FoldTypes, UI for auto-folding will
> appear for that language, the placeholder text (in FoldTemplate) can be
> defined, and ContentReader (for variable placeholder text) can be registered.
> 
> The "good" news is that the diff contains already adjustments for PHP and HTML.
> JS should be easy, too.

Thanks for the explanation, it looks great from the CSL client perspective. Just one detail.

MJ01: Could we make the FoldTypeProvider.getValues() method parametrized? I imagine something like this:

public Collection<FoldType> getValues(Class<? extends FoldType> type);

..with such change we could avoid type checks in FoldTypeProvider implementations (e.g. in PHPFoldingProvider we could just return TYPES instead of "return type == FoldType.class ? TYPES : null;")

As an impact we would have to make FoldRegistry enumType property parametrized as well, but that's just a cosmetic change.
Comment 4 Svata Dedic 2013-02-21 20:20:18 UTC
Re. MJ01: good catch. The method
Collection getValues(Class t);
is what remains from generalized concept of extensible enums. I suspect that for purposes of CSL, more such enums will be defined (i.e. modifiers, element kinds), and there could be an uniform mechanism EnumValueProvider; I wanted to allow multiple enums to be served from one implementation class, that's why the Class parameter is there, and the method  is not generified.
It could prevent module owners from writing 2-3 classes similar to each other, each serving a different enum. At this point, though it is a speculative generalization = not a good API. I didn't find a reasonable alternative how to bridge FoldTypeProviders to the supposed generic ext.enumeration; please suggest ;)
Comment 5 Svata Dedic 2013-03-12 13:02:28 UTC
Implemented in changeset http://hg.netbeans.org/jet-main/rev/2826899460ad

Implied changes in individual languages will follow in a separate changeset.
Comment 6 Svata Dedic 2013-03-12 15:47:09 UTC
CSL support in http://hg.netbeans.org/jet-main/rev/2201d4aea94e
Java support in http://hg.netbeans.org/jet-main/rev/cd37962eaf3c
Comment 7 Quality Engineering 2013-03-13 02:10:20 UTC
Integrated into 'main-golden', will be available in build *201303122300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/c1b657407e68
User: Svata Dedic <sdedic@netbeans.org>
Log: #226413, #226368: Folds UI separated to a new module. editor.lib partially cleaned up from folding code.
Comment 8 Quality Engineering 2013-03-14 02:08:07 UTC
Integrated into 'main-golden', will be available in build *201303132300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/2826899460ad
User: Svata Dedic <sdedic@netbeans.org>
Log: #226413: Fold API enhancements implemented
Comment 9 markiewb 2013-03-17 00:06:57 UTC
*** Bug 216456 has been marked as a duplicate of this bug. ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo