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.
|Summary:||[umbrella] cleanup/redesign of openide.text package|
|Product:||platform||Reporter:||David Konecny <dkonecny>|
|Issue Type:||TASK||Exception Reporter:|
|Bug Depends on:||7067, 15920, 16905, 17919, 21233, 23157, 25762, 17081, 19928, 20951, 22444, 33165|
Description David Konecny 2002-03-20 15:26:58 UTC
Recently I saw a few bugs for text package with comments like "this fixed caused regression ....". I worked on text package for a while and I can just confirm that it _is_ very fragile, the order of calls must be kept otherwise something will fail, but it is not known which these calls are, etc. Unfortunately I cannot provide more details, just this general feeling. I would consider some refactorings/cleanup in this area if the resources are available. Let me know if I could help you somehow.
Comment 1 Marian Mirilovic 2002-12-06 17:17:49 UTC
reassigne to David K., new owner of editor
Comment 2 David Konecny 2003-02-27 16:55:36 UTC
Making this issue umbrella for potential cleanup/redesign of text package. This is just organisational effort - no resources committed at the moment. I would like to make this issue dependant on several other issues which should be considered as part of the cleanup.
Comment 3 _ tboudreau 2005-03-01 09:49:34 UTC
A minor thought re performance - I've been recently writing a tutorial that covers DataEditorSupport. DataEditorSupport has to be the strangest class in NetBeans, possibly anywhere - it implements a bunch of interfaces, but doesn't...and the subclasser has to figure that out. But we'll leave that alone for now... DataEditorSupport does everything through its <code>getEnv()</code> method. CloneableEditorSupport.Env requires at least one, typically two (if you are lazy and split PCLs and VetoablePCLs) listener lists. It would all be very nice if it were created on demand, but the CloneableEditorSupport.Env must be passed to DataEditorSupport's superclass constructor - which means the whole thing must be created just to see if a file could be edited, when it will only be used if a user actually opens it in the editor. I'm not sure we'd get a lot of gain out of making DataEditorSupport a little more lazy - I don't know who's using it - but it might be worth measuring - you shouldn't need to allocate all that stuff just to satisfy a request for OpenCookie or EditCookie - right now it looks like you do unless you implement everything yourself.
Comment 4 Antonin Nebuzelsky 2008-04-17 15:15:31 UTC
Reassigning to new module owner mslama.