Extend facelet-taglib schema
- Dominant language
- Java
- Stars
- 127
- Forks
- 59
- Avg merge
- 23h
- Merged PRs (30d)
- 7
Description
The Facelet taglib XML file has a number of limitations and it might be a good idea to improve the format.
Currently when a component inherits from another component, each and every attribute of the parent component has to be copied into the tag declaration in the taglib file. This makes taglib files very verbose and makes it hard to see which attribute the new tag introduces. A solution to this would be adding a way to declare that a tag inherits from another tag.
For instance:
```
form
org.example.Form
Whether to include all URL (GET) request parameters in the action URI.
includeRequestParams
false
boolean
```
Components in JSF can introduce an (EL) variable for their children to consume, e.g. like the var attribute of a datatable. This can however not be declared in a taglib, so tools have to have hardcoded knowledge of which tag does what with which attribute. This means tools lack behind new tags from a certain component library and only well known component libraries are supported. It would be great if it could be declared that an attribute represents the name of an introduced (EL) variable.
For instance:
```
Name of a request-scope attribute under which the model data for the
row selected by the current value of the "rowIndex" property
(i.e. also the current value of the "rowData" property) will be exposed.
var
false
java.lang.String
request
value
true
```
In the above example var is declared to be an "output variable", that has as its type the type of the "collection element" that's bound to the value attribute. E.g. if value is bound to a List, then the type of var is Foo. Other options would be setting a fixed type or referring directly to the type of another attribute.
Another issue is that attributes often have a default and an allowed range of values. This now has to be communicated in the description of an attribute and that description has to be kept in sync with the actual code. Tools sometimes have hardcoded knowledge of the allowed values (for auto-completion and warning flagging) for some attribute, but this too can be out of sync with newer releases of a component lib and doesn't support lesser known or internal components.
It would help a lot of this could be declared in a taglib file as well. E.g.:
```
The ordering type.
type
false
java.lang.String
lt, lte, gt, gte
lt
```
Some JSF components, like e.g. datatable support multiple types for a given attribute. It might be an improvement if these types could be enumerated in the attribute's declaration, e.g.
```
The current value of this component.
value
false
javax.faces.model.DataModel
java.util.List
java.lang.Object[]
java.sql.ResultSet
javax.servlet.jsp.jstl.sql.Result
java.util.Collection
java.lang.Object
```
I'm sure there might be some other areas where taglib files can be improved besides the use cases mentioned above.
Contributor guide
Research direction
Start with the Facelet taglib XML format described in the issue and review how existing tag and attribute declarations are represented. Define the schema changes needed for tag inheritance, output variables, allowed and default values, and multiple attribute types; done means these cases can be declared and consumed consistently by tools.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- tooling, web-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100