Where Parsley is heading
When a method like Invoice.customer() is renamed to Invoice.buyer(), template keypaths that traverse through that type should update too — e.g. $selectedInvoice.customer.name → $selectedInvoice.buyer.name. The current binding key rename only handles the first segment (the component’s own keys); this would extend it to any segment in a keypath chain.
Requires type resolution through the keypath chain — resolving each segment to its Java type, then matching the renamed method against that type. The validation engine already does this for error checking, but bridging it with the refactoring layer across all templates in the workspace is a significant piece of work.
Find References on an element type like WOConditional currently only finds templates that reference it by class name. Templates using a tag shortcut like <wo:if> are not found, even though if resolves to WOConditional. Once the tag shortcut mechanism is cleaned up, Find References should resolve shortcuts to their target types and include those matches.
Eclipse’s “Find References” now shows template binding references for a component’s own keys (first segment only). The next level would find references to a method or field through keypath chains in any template — e.g. searching for Customer.name() should find $selectedCustomer.name in other components’ templates.
Same underlying requirement as deep keypath segment renaming: type-resolving every segment in every keypath across all templates in the workspace. Could share the same infrastructure once built.
Component renaming works but undo fails. The undo entry recorded by Eclipse's refactoring framework conflicts with the resource-level renames added by our LTK participant. Needs investigation into LTK's undo/redo machinery.
A navigable view of "this component uses these sub-components" — useful for understanding unfamiliar codebases and spotting circular dependencies.
Convert an entire template between WOD-reference syntax and inline binding syntax in one step. Single-tag conversion works in both directions — Cmd+2, W (inline → WOD) and Cmd+2, I (WOD → inline). The remaining piece is batch conversion (all tags in a file at once).
When converting WOD declarations to inline tags, use short tag names for well-known elements — e.g. <wo:if> instead of <wo:WOConditional>, <wo:str> instead of <wo:WOString>. Requires a mapping from element types to preferred short names, which could live in the component API model or as a user-configurable registry.
A major evolution of the .api file format to describe the full component contract. Binding type checking (go beyond “this binding doesn’t exist” to “this binding expects a String, you’re passing an NSArray”), binding directionality (get/set/both), deprecated bindings, default values, value constraints, required vs. optional bindings, per-binding documentation, component descriptions, content model, and more. This feeds into almost every other roadmap item.
Support for additional tag namespaces beyond wo:. The html: namespace for dynamic HTML tags with binding-valued attributes, and expanded p: parser control directives.
A Chromium-based preview tab in the component editor that renders the template as you edit, in two tiers:
Tier 1 (static): Transform <wo:*> tags into preview-friendly HTML — placeholders for dynamic values, labeled borders for conditionals and repetitions, resolved images from webserver-resources, real project CSS. Unknown components render their children in a labeled box. Components can declare custom preview HTML via the .api file’s preview attribute.
Tier 2 (live): When the app is running locally, the preview points the Chromium browser at localhost. Combined with DCEVM hot-reload, editing a binding updates the preview in real time — the Bindings Inspector becomes a live property editor. The static preview serves as fallback when the app isn’t running.
Extract the core editor intelligence — parsing, validation, completion, refactoring — into a standalone library with no Eclipse dependencies, then wrap it in an LSP server. This makes Parsley’s template tooling available in VS Code, IntelliJ, Emacs, and any editor that speaks LSP.
The current codebase is coupled to Eclipse APIs (JDT for type resolution, IResource for file access, LTK for refactoring). Decoupling requires abstraction layers for type lookup, file system access, and project model queries. The recent move to immutable POJOs (ApiSnapshot, VisibleBinding) is a step in this direction.
Internal modernization. Not user-visible, but improves maintainability and long-term health of the codebase.
The codebase was written for Java 1.4–5 and never updated. Opportunities include: enhanced for-each loops (replacing Enumeration/Iterator while-loops), generics (eliminating raw types and manual casting), try-with-resources for streams, diamond operator, StringBuilder over StringBuffer, lambdas for anonymous inner classes, and text blocks for multi-line strings.
The plugin was extracted from WOLips (~18 plugins merged into one). While significant cleanup has been done, vestiges remain: unused fields, no-op methods, and code paths that only made sense in the original multi-plugin architecture.
Several internal APIs use null as a control-flow mechanism, with the same method returning null for multiple unrelated scenarios. These should be clarified with proper typing, Optional, or early validation.