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.
The Viusal CSS Editor has been separated out from Visual Web and will be integrated in to the web module shortly. Style Builder is currently part of this CSS Editor. This need to be separated out from this CSS Editor for the following reason. Style Builder is a general purpose CSS "style" String editor. It can be used at other places such as - CSS Style property Editor (currently code is duplicated) - Theme Editor for Web UI components If it is separated out, the client module could add the String which need to be visually built to the Style Builder and listen to the builder to get any visual modification made to that style string. Here is a suggestion to separate it out Create a SPI called public interface org.netbeans.spi.css.StyleBuilder{ public StyleBuilderPanel getStyleBuilderPanel(); } public interface org.netbeans.spi.css.StyleBuilderPanel{ public void setStyleString(); public String getStyleString(); public void addStyleChangedListener(Listener ); public void removeStyleChangedListener(Listener ); } The implementation of the above SPI could be in the CSS Editor itself The CSS Editor module could register the Implementation as meta-inf/services/org.netbeans.spi.css.StyleBuilder org.netbeans.module.css.StyleBuilderImpl The module that needs the StyleBuilder would get the StyleBuilder as org.netbeans.spi.css.StyleBuilder[] wsmExts = Lookup.lookup("org.netbeans.spi.css.StyleBuilder"); org.netbeans.spi.css.StyleBuilderPanel panel = wsmExts[0].getStyleBuilderPanel() somePanel.add(panel); panel.addListener(this);
why not simply: public final class org.netbeans.spi.css.support.StyleBuilderPanel { public StyleBuilderPanel getDefault(); public void setStyleString(); public String getStyleString(); public void addStyleChangedListener(Listener ); public void removeStyleChangedListener(Listener ); } I do not see any need to multiple implementations, registration and lookup now. The use case is to get to the one impl we have. Why fill the global lookup with garbage when there is only one implementation? If needed in future we can always add that later, make the class non final and/or override the getDefault, cannot we?
I am OK with such API, IMO Pavel's proposal with a final class and static getDefault() method is OK. I have just one question - do we always need just one shared instance of the SB in the time? The panel can be shown in an non-modal window... So the ?final? proposal: public final class org.netbeans.spi.css.support.StyleBuilderPanel extends JPanel { public static StyleBuilderPanel getDefault(); //returns shared instance public void setStyleString(String text); public String getStyleString(); public void addStyleChangedListener(StyleChangedListener l); public void removeStyleChangedListener(StyleChangedListener ); } public interface StyleChangedListener { public void styleChanged(); }
I'm OK with creating Singleton class. But the problem is, more than one Style Builder instance could exist at a time. For example, user can bring up a Style property Editor while Editing CSS or using Theme Builder. So we need the ability to create unique instance for each client. Instead of getDefault() we should have public static StyleBuilderPanel getInstance(); // get Unique instances
Marek, Winston, you are right that we may need multiple instances and therefore getInstance() is needed instead of getDefault(). Thanks for catching that.
Winston, can you please confirm you still need this API? I just want to be sure that I do not do something useless. Thanks
Yes, this is needed. The custom style property editor uses stylebuilder as the dialog. Currently the code is duplicated.
I have just commited the refactored version of css visual editor. I had to reimplement almost everything except the UI panels functionality. I have created two packages which should be made friend - public to your module to get the desired functionality: 1) org.netbeans.modules.css.visual.api - contains the StyleBuilderPanel with following public methods: public static StyleBuilderPanel createInstance() //creates a new instance of the SBP public void setContent(CssRuleContent content) //initializes the panels with the proper data. 2) org.netbeans.modules.css.model package which contains classes allowing clients to get an instance of css model built on top of swing document. The model is based on Schlieman's parser and allows you to get list of rules, their content and listen on changes. For more details please see the javadoc in the package classes. So ... I made it little more complicated, no Strings any more and instead of that some more data abstraction. Your workflow should be following: 1) create an instance of CssRuleContent - contains a list of CssRuleItem-s 2) get an instance of StyleBuilderPanel 3) add a listener to the CssRuleContent instance 4) show the panel 5) edit using the UI => events are fired to the CssRuleContent instance as you change the properties in the UI. I haven't made the packages public yet, I'll wait to your opinion first. Please review it ASAP so I can do possible changes before FF (I am on vacation next week so I have time by the end of this week). Thanks Winston.
So what needs to be the next step on this bug?
The whole communication including Winston's reservations about the API and model behavious has been done by private email unfortunatelly. Basically it is required to solve issue #105723 which is kind of blocker for Winston if I rememeber is correctly. The API is OK IMHO. Winston please comment. I plan to fix this along with isssue #105723 into beta1, but I was still putting them off since they may require longer time.
Just want to give you an FYI - Winston will be back from vacation Aug. 10.
OK, I belive I'll resolve the issue sooner.
Done additional changes towards Winston's requirements. Winston wrote: >The bug is -- I'm getting the event from CssRuleContent correctly when the content of the >StyleBuilderPanel is changed. But when I looked at the cssRuleContent.ruleItems(), it still >has the old ruleItems I set. Not the contents after I changed in the StyleBuilderPanel. This problem is now fixed by allowing the css model domain objects to mutate based on user input if the model is built on immutable source. This may sound confusing, but the point is that for css model based on a mutable document the changes done via UI are propagated to the document which then refreshes the model domain objects. For immutable source the model modifies its domain objects based on the user input. I belive this covers what you requested. I created a simple testing dummy application - a dialog displaying the stylebuilder + preview + textarea with list of rule items. There is also an action for opening such dialog, the action works on css files. I'll attach a diff so you can test it. One thing came to my mind when I played with the css stuff today - we created some api for the stylebuilder, but there isn't any possibility how you can get the preview panel based on flying saucer. I guess you also want this. If so, I need to enhance the API slightly. BTW, the code I just commited is not fully commeted and polished, though the change shoudn't happen regressions. Please take look at it and let me know how it fulfils your ideas. Thanks, Marek cvs server: scheduling file `CssRuleContext.java' for addition cvs server: use 'cvs commit' to add this file permanently RCS file: /cvs/web/css/src/org/netbeans/modules/css/visual/api/CssRuleContext.java,v done Checking in visual/api/CssRuleContext.java; /cvs/web/css/src/org/netbeans/modules/css/visual/api/CssRuleContext.java,v <-- CssRuleContext.java initial revision: 1.1 done Checking in visual/api/StyleBuilderPanel.java; /cvs/web/css/src/org/netbeans/modules/css/visual/api/StyleBuilderPanel.java,v <-- StyleBuilderPanel.java new revision: 1.4; previous revision: 1.3 done Checking in visual/ui/preview/CssPreviewTopComponent.java; /cvs/web/css/src/org/netbeans/modules/css/visual/ui/preview/CssPreviewTopComponent.java,v <-- CssPreviewTopComponent.java new revision: 1.7; previous revision: 1.6 done Checking in visual/ui/preview/CssPreviewable.java; /cvs/web/css/src/org/netbeans/modules/css/visual/ui/preview/CssPreviewable.java,v <-- CssPreviewable.java new revision: 1.2; previous revision: 1.1 done Checking in visual/ui/preview/CssPreviewPanel.java; /cvs/web/css/src/org/netbeans/modules/css/visual/ui/preview/CssPreviewPanel.java,v <-- CssPreviewPanel.java new revision: 1.2; previous revision: 1.1 done Checking in visual/ui/preview/CssPreviewGenerator.java; /cvs/web/css/src/org/netbeans/modules/css/visual/ui/preview/CssPreviewGenerator.java,v <-- CssPreviewGenerator.java new revision: 1.4; previous revision: 1.3 done Checking in editor/CssEditorSupport.java; /cvs/web/css/src/org/netbeans/modules/css/editor/CssEditorSupport.java,v <-- CssEditorSupport.java new revision: 1.9; previous revision: 1.8 done Checking in visual/ui/StyleBuilderTopComponent.java; /cvs/web/css/src/org/netbeans/modules/css/visual/ui/StyleBuilderTopComponent.java,v <-- StyleBuilderTopComponent.java new revision: 1.4; previous revision: 1.3 done Checking in visual/ui/MarginStyleEditor.java; /cvs/web/css/src/org/netbeans/modules/css/visual/ui/MarginStyleEditor.java,v <-- MarginStyleEditor.java new revision: 1.6; previous revision: 1.5 done Checking in visual/ui/StyleEditor.java; /cvs/web/css/src/org/netbeans/modules/css/visual/ui/StyleEditor.java,v <-- StyleEditor.java new revision: 1.6; previous revision: 1.5 done Checking in model/CssRuleContent.java; /cvs/web/css/src/org/netbeans/modules/css/model/CssRuleContent.java,v <-- CssRuleContent.java new revision: 1.7; previous revision: 1.6 done Checking in model/CssModel.java; /cvs/web/css/src/org/netbeans/modules/css/model/CssModel.java,v <-- CssModel.java new revision: 1.7; previous revision: 1.6 done Checking in model/CssRuleItem.java; /cvs/web/css/src/org/netbeans/modules/css/model/CssRuleItem.java,v <-- CssRuleItem.java new revision: 1.3; previous revision: 1.2 done
Created attachment 46799 [details] Diff for web/css module with an application for testing of StyleBuilderPanel working on css model backed by an immutable source
I will test and let you know. The preview in the custom CSS style property editor is the actual image of the component obtained from the Web form designer, so I may not be able to use the embeded flying saucer here. However, I'm glad you did this, because I was looking for ways to display the generated HTML along with the modified styles for the Component Theme Editor. This is certainly going to be very useful. Thanks a lot.
Wince, please let me know If you are going to use this API in netbeans 6.0. If so, I'll have to do a fasttrack review for the friend API since I added more API classes compared to what we agreen on with Pavel at the very begginning. If you won't use it in 6.0, I'll won't make it public and I'll also extend the API of a possibility to use the css preview component. I am lowering priority to P3 now since based on your last email it looks like you may not even use this API in 6.0. Please let me know so I can resolve this somehow. Thanks in advance!
Winston, not Wince - I am sorry...
Hi Marek, things are working fine. As I gather from QA, since this dialog need to be retested for every component (75 of them), they are hesitant to use it for NB 6.0. So, they are asking me to postpone it until NB 6.1. Since now it is my part to complete, you can convert this in to an RFE and assign it to me.
Yes, I can do it, but I first wanted to expose the CSS preview component in the API so you can then use it in 6.0. But we can put it off for 6.1. What do you think?
Sounds good. I may not be able to use it for ThemeBuilder until NB 6.1 anyway.
OK, converting to TASK, I'll add the CSS preview into the API in and finalize the API after 6.0.
Wince, do you still need the preview API? I would close this issue if not. Thanks.