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.
comment from ludo: The class name element could also be parametrizable, so that I can pass a String parameter to the object repesenting the palette. This way the class would be known at compile time, but based on this parameter, we could dbd and drop what we want. Fro jMaki we cannot use static snippet since we need validation and add more than the snippet code when DnD. We need a class. Having a class per palette entry is a bit too heavy and not extensible dynamically.
For jMaki integration into the NetBeans 6.5 IDE, we need this enhancement to be implemented. Currently have an ugly workaround to generate a class at runtime that inherits from a common class that has all the behaviour and we use introspection from the classname to get the extra information about the specifc widget. It would be much better to be able to define a palette like: ]<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE editor_palette_item PUBLIC "-//NetBeans//Editor Palette Item 1.2//EN" "http://www.netbeans.org/dtds/editor-palette-item-1_2.dtd"> <editor_palette_item version="1.2"> <class name="org.netbeans.modules.sun.jmaki.palette.GenericjMakiPaletteItem" arg="templates.dojo.accordion"/> <icon16 urlvalue="org/netbeans/modules/sun/jmaki/palette/resources/jmaki16.jpg"/> <icon32 urlvalue="org/netbeans/modules/sun/jmaki/palette/resources/jmaki32.jpg"/> <description localizing-bundle="templates.dojo.accordion.Bundle" display-name-key="NAME_templates.dojo.accordion" tooltip-key="HINT_templates.dojo.accordion"/> </editor_palette_item> And the GenericjMakiPaletteItem class would have a public constructor taking a String as a parameter. The palette framework would call this public constructor using the arg parameter defined in the xml file. This is critical to do for NetBeans 6.5 in order to cleanup ugly hacks used by the jMaki mnodule. This will also remove the usage of moduleInstall calls necessary as a side effect of the missing capability. Thanks for considering a fix for 6.5
this is probably a duplicate of 68752 how about adding an optional "method" attribute to <class> that would identify static factory method of that class accepting FileObject of the palette item in SFS. then the FileObject can have as many attributes as you want and they would be accessible withing the factory method. ludo, would that work for you?
Could work (need to think more,maybe an example can help), but this adds a bit of complexity (need to have a FileObject, so need to have it created). Maybe both solutions, assuming there is a user case for the FileOjbect. My use case is simple: I have a uuid for each widget, and from that I can deduce what I need. No need for a FileObject there.
how about this then?: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE editor_palette_item PUBLIC "-//NetBeans//Editor Palette Item 1.2//EN" "http://www.netbeans.org/dtds/editor-palette-item-1_2.dtd"> <editor_palette_item version="1.2"> <class name="org.netbeans.modules.sun.jmaki.palette.JMakiPaletteItemFactory" method="createItem"/> <icon16 urlvalue="org/netbeans/modules/sun/jmaki/palette/resources/jmaki16.jpg"/> <icon32 urlvalue="org/netbeans/modules/sun/jmaki/palette/resources/jmaki32.jpg"/> <description localizing-bundle="templates.dojo.accordion.Bundle" display-name-key="NAME_templates.dojo.accordion" tooltip-key="HINT_templates.dojo.accordion"/> <arg name="uuid" value="somevalue"/> <arg name="someotherarg" value="someothervalue"/> </editor_palette_item> class JMakiPaletteItemFactory { public static ActiveEditorDrop createItem(Map<String,String> args) { String uuid = args.get("uuid"); //create item } }
Would work. I still have a (new) concern --sorry about that, but this is why reviews are for-- , regarding the display name and the description: could it be possible to get it via the new arg mechanism? This way, it does not force to have a predefine bundle in the classpath (maybe the name is not know by a bundle in the module classloader.) Same for the icons: they could be returned via the class either via predefined args or predefined method. This way, the single entry point for a palette entry would be a class that can calcute the icon, name, and other things based on the uuid If we can do that, then all my issues regarding classloader are solved. Otherwise, I will still have to hack some classloader to returned dynamically calculated names or icons.
well, there are <display-name> and <tooltip> elements if you don't want to use resource bundle for them. no workaround for icons though. however, after reading your requirements i think you might be better off with defining an arbitrary hierarchy of nodes and bypassing xml layer completely. or is there a requirement to have a palette folder in xml layer?
Maybe, do you have a pointer for me to see how it can be done? I am not an expert in this area.
it's quite simple: create a root node whose children will be palette categories. the children of categories nodes are palette items. icons and labels come from Node's display name and icons. palette items must have ActiveEditorDrop in their Lookup. pass the root node to palettefactory when creating palette controller.
Does not work yet for me with a test. Here is the code I am using, I see the 2 palette items on my palette (Entry 1 and Entry 2) See the lookup. But when I DnD a palette entry on my php test file, I do not see the println on my console... So I must be missing something... package org.netbeans.modules.sun.jmaki.palette; import javax.swing.text.JTextComponent; import org.openide.nodes.AbstractNode; import org.openide.nodes.Children; import org.openide.nodes.Node; import org.openide.text.ActiveEditorDrop; import org.openide.util.Lookup; import org.openide.util.lookup.Lookups; /** * * @author ludo */ public class RootNode extends AbstractNode { public static final class DojoNodes extends AbstractNode { public DojoNodes() { super(new PaletteChildren()); setDisplayName("DOJO Palette"); //NOI18N setName(getClass().getName()); } } public static final class DojoNode extends AbstractNode { public DojoNode(String name, Lookup l) { super(Children.LEAF, l); setDisplayName(name); //NOI18N setName("" + this); } } public RootNode() { super(new ContainerChildren()); } public static class ContainerChildren extends Children.Keys { @Override protected void addNotify() { Node n[] = { new DojoNodes() }; setKeys(n); } @Override protected void removeNotify() { setKeys(java.util.Collections.EMPTY_SET); } protected Node[] createNodes(Object obj) { return new Node[]{(Node) obj}; } } public static class PaletteChildren extends Children.Keys { @Override protected void addNotify() { Node n[] = new Node[2]; Object o1[] = {new MyDropImpl()}; Object o2[] = {new MyDropImpl()}; n[0] = new DojoNode("Entry 1", Lookups.fixed(o1)); n[1] = new DojoNode("Entry 2", Lookups.fixed(o2)); setKeys(n); } @Override protected void removeNotify() { setKeys(java.util.Collections.EMPTY_SET); } protected Node[] createNodes(Object obj) { return new Node[]{(Node) obj}; } } static public class MyDropImpl implements ActiveEditorDrop { public boolean handleTransfer(JTextComponent targetComponent) { System.out.println("Should be printed when dropping a snippet in a php file=" + this); return true; } } }
sorry, i forgot to mention you need to override the following methods in your item node: @Override public Transferable clipboardCopy() throws IOException { ExTransferable t = ExTransferable.create( super.clipboardCopy() ); Lookup lookup = getLookup(); ActiveEditorDrop drop = (ActiveEditorDrop) lookup.lookup(ActiveEditorDrop.class); ActiveEditorDropTransferable s = new ActiveEditorDropTransferable(drop); t.put(s); return t; } @Override public Transferable drag() throws IOException { return clipboardCopy(); } private static class ActiveEditorDropTransferable extends ExTransferable.Single { private ActiveEditorDrop drop; ActiveEditorDropTransferable(ActiveEditorDrop drop) { super(ActiveEditorDrop.FLAVOR); this.drop = drop; } public Object getData () { return drop; } }
it works, so no need for api change. But keep the bug open since the doc is completely nonexistent for nodes in Palette. What a waste of my time!!! Nothing in blogs, nothing in javadoc, nothing via google search , nothing in arch document, nothing I could understand in palette source code, only this bug report to understand how to use a NetBeans api...
see 'palette content' usecase: http://bits.netbeans.org/dev/javadoc/org-netbeans-spi-palette/overview-summary.html
Let's close this issue if the docs include the needed info. If not, Stando, put this usecase explanation there and close this.
One more question, not really described in the use case documentation: How Do I add palette items defined as nodes to an existing JSP palette defined as a folder ("JSPPalette") Not sure how to mix and match nodes and palette items defined as folders/files. In other work, I have a rootnode that has a set of children categories I need to add to the JSP palette. For PHP it works (maybe because the PHP editor defines a palette in its layer, but not for JSP) Thanks for the help, I cannot find the solution via the documentation
maybe the jsp loader is not correct. I see this in the log: WARNING [org.openide.loaders]: Should override getLookup() in class org.netbeans.modules.web.core.jsploader.JspDataObject, e.g.: [MultiDataObject.this.]getCookieSet().getLookup() my jmaki layer for jsp is like: <folder name="Editors"> <folder name="text"> <folder name="x-jsp"> <file name="org-netbeans-spi-palette-PaletteFactory.instance"> <attr name="instanceOf" stringvalue="org.netbeans.spi.palette.PaletteController"/> <attr name="instanceCreate" methodvalue="org.netbeans.modules.sun.jmaki.spi.MyLayerPaletteFactory.createPaletteJSP"/> </file> but JSP editor has a funky way to define the palette that I cannot extend via nodes only static xml files under JPSPalette folder... I m stuck for jmaki jsp palette extension via nodes...
i don't think there's an easy way to merge Node-based and layer-based palettes. how did you merge your items into PHP palette?
almost same code with php. The differences I see is that by default the php palette defined by the php module is empty and also registered in the layer file. For jsp the palette is not empty and registered the OLD way in the topcomponent editor. Maybe we need to modify the JSP module to define the palette factory in the layer? In any case, I am stuck again (not for php, but for jsp) The apis should allow for getting a palette by its name, get its root node, and add a node to the root node, no? I do not want to hack the physical file system as I did before, since the entries still show up when you disable the module.
The curent jMaki plugin used a hack (loophole) on the nb classloader private mehods which is gone now in 6.5 and there is no way to adapt a new hack (a variable is now final). What is means is that I am stuck for jMaki in Nb 6.5: 1/ cannot continue to use a hack (impossible now) 2/ cannot find a way to use the Palette APIs to extend via Nodes the JSP and HTML palette. So bottom line, either the palette module has a solution, or we modify the JSP and HTML palettes or I cannot ship a jMaki plugin for NetBeans 6.5
see https://ajax.dev.java.net/issues/show_bug.cgi?id=360 that shows the old hack cannot work any more and it cannot be adapted either.
palette module has no solution besides implementing this enhancement which is a bit too late for 6.5 i guess. but if modifying html and jsp palettes to be declared in mime-type section helps then i vote for it. it's harmless and easy change...
so help me there a bit. 1/ we could move the jsp palette registration in the layer 2/ it would still use a string name and not a node ("JSPPalette" name folder is an interface maybe used elswehere) 3/ my code would need to do something to lookup this palette (what? Maybe call the factory create again since the create code is such that a first call do a create and second call just returns the singleton 3/ from palettemanager, what do I do to get the 'virtual root node' of this palette? Lookup the DataFolder, and ask for the DataNode? how? (introspection to access private/hidden fields?) 4/ Assuming I can get this root node, is there a way to either replace it, or extend the list of childrens with my new nodes, without creating new apis in the JSP editor module?
Created attachment 66664 [details] an example of palette merge
ludo, i've attached an example module showing a possible solution for palette merging. i think it's best to merge palette's on XML layer level so you need to define your palette there. but you don't have to follow editor palette item DTD. you can create an arbitrary XML structure with any data you need and parse it as you like. or perhaps you'll be able to use your current palette nodes when creating node delegates in PaletteItemDataObject. then you wouldn't need any content in xml files. the example has some source files copied from form designer module and extends HTML editor's palette. let me know if this solution is acceptable for you.
Will try, but I do not want to use a static layer.xml since the feature we have is to be able to add palette entries from a jMaki library (zip file) dynamically without creating a new nbm that would have this layer... Let me read the proposition.
"I do not want to use a static layer.xml" - see http://bits.netbeans.org/dev/javadoc/org-openide-filesystems/apichanges.html#add-content-to-sfs
very cool. I am almost done, now even with a memoryfilesystem to store the palette data files but not on disk... Thnks
*** Issue 143035 has been marked as a duplicate of this issue. ***
I am still experiencing some issues with the DnD of a palette item. Depending on the files (php, html) or whether it is open or not when the IDE starts, sometimes when I DnD a jMaki palette using the new mechanism, the insert point caret in the editor does not move to where I drop the item. The insertion point is wherever the cursor was before the start of the DnD operation. What should I look for?
Well, to my previous comment, this can be reproduce without jMaki: P2 filed: http://www.netbeans.org/issues/show_bug.cgi?id=143368
not such a big issue anymore - lowering to P3