Tapestry Palette

Drag & Drop Tapestry Component Editing

Help Wanted - March 29, 2005

Would you like to contribute to the Tapestry Palette, get to grips with the Eclipse plugin architecture and help make learning and developing with Tapestry even easier?

Well, I need help, I've been developing Tapestry Palette during some of my downtime over the past 6 months and I'm pretty happy with the feature set it has now. It is very usable but it needs a lot of "fit and finish" before I would be happy taking the alpha label off the releases. Upcoming developments of Tapestry, Spindle & Eclipse are going to stretch my ability to keep the palette up to date by myself, and I'll be settling into some longer term contracts this year which will also take a toll.

So if you like the palette and can help out, contact me at: michaelh_at_mjhenderson.com (you know what I mean). Meanwhile, here is a rough sketch of where I would like to go with the Tapestry Palette. You may have your own ideas.

In the short term I am going to restrict myself to bug-fixing but here are some of the items that need to get done in the medium term:

1. Support Tapestry 3.2 DTD
   The palette will not work with the 3.2 release until Spindle does but the code is structured so that I can implement the handling of drag and drop editing based upon the Tapestry version number so it can be completed in advance and tested in unit-tests.
2. Support Eclipse 3.1
   I am currently testing only with Eclipse 3.01 on 3 platforms, Linux, Mac OS X and Win XP. The product needs to be built and tested for Eclipse 3.1 so that it is ready to go when the full release is announced.
3. Unit Testing
   I know, I know. I should have written them while I was writing the code. Drag and drop, especially the range-tracking code, the text parsing code for looking up used jwcid values and items like the jwcid generation should be testable outside of Eclipse, and if they are not, then we can refactor them so that they are.

For the longer term I would like to see the following enhancements to the palette:

• Component Preview
  A design time preview of a page, smart enough to use stylesheets, etc. to give a WYSIWYG preview of a page or component.
• Enhanced drag and drop edit validation
  In it's current state the palette does minimal validation but it should be possible to develop a per-component strategy of validation so that for instance a When component must be inside a Choose component, or a ValidField is inside a Form component. Perhaps a class name convention to allow component developers to provide an interface implementation to validate the placement of a component.
• More drag and drop
  Drag an image onto a specification to add an asset, Drag a Java class to add a bean, New draggable items in the palette to represent component parameters, properties, assets and beans, just drag an icon onto the specification to add the appropriate declaration.
• Improved remote library support
  Right now the libraries are downloaded and added to WEB-INF/lib in every Eclipse project. The palette should adopt a maven-like approach to download libraries to a local folder once and use the local copy when installing into subsequent projects. The palette should attempt to detect library version conflict when downloading and should detect new versions of libraries and dependencies in supplier XML files and offer an upgrade option to the user. A central supplier registry, consulted by the palette would remove the need for users to enter the URLs of XML files into the preferences page.
• Show Tapestry pages in component libraries.
  Library developers may also ship page components with their libraries. These are not supported in the palette right now. They would not be draggable but would be visible and described in the inspector.

Immediate work:

• Improve drag and drop
  The palette won't let you drag a component onto an empty line in the template. Range tracking can be messed up by unmatched HTML tags like <br/> (<br> works).
• Inspector layout
  The various inspectors displayed in the palette have poor resize behavior - the items in the inspector do not resize when the palette is widened.
• Logging
  Implementation of Eclipse logging will allow the plugin to report errors to the Eclipse Error Log and to the Eclipse Console.
• Refactoring
  The plugin has a new architecture that delegates drop editing behavior to an object supplied by a factory object. The factory object differs according to the type of object being dragged. The component drag and drop is not completely refactored to this new architecture. Once it is the core code will be much cleaner. The inspector display code has lots of duplication and could easily be refactored into common classes.
• Integrated Help
  I'm writing some help documents for this site, but we should ship help integrated into the Eclipse Help architecture.