Idea DOM API: support for dynamic attributes Follow
Let's say I'm working with an XML format where available attributes on a
given element depend on some context.
An example would be Ant tasks, where property setters can be invoked through
attributes on the task element.
For example:
---
class Baz {
public void setSomeString(String s) {}
public void setSomeNumber(Integer i) {}
}
---
]]>
---
I would want to:
-provide references from attribute name to setter method
-provide variants based on accessible setters
It there some support for this idiom in DOM API?
Thanks,
-tt
Please sign in to leave a comment.
Not yet. And I can't imagine any common use case and implementation for
such things.
Hello Peter,
I think my post was unclear. I don't expect DOM API to recognize "class"
attribute or anything like that.
Exactly what attributes are available, and how they resolve, would of course
depend on my plugin implementation, using some pluggable interface.
Do I understand correct that you want DOM model to be specified not at
compile-time by interfaces and annotations, but at runtime via some
other interface? Need to think about it. Maybe. Would be a nice
functionality.
Hello Peter,
I do not know all parts that together make up the DOM model, but I think
the answer is 'yes'.
(my understanding is that DOM API can be broken down in two parts: resolving/reference
providing, and a 'parser facade' through interfaces, is there more?)
Note that original post is only about a limited scope feature: attributes
(atribute name) that are not known a-priori (at compile time).
To make things interesting, a more complicated example from a spring 2.0
configuration:
---
]]>
---
Looking at the current implementation of the spring facet in IDEA 7.0M1,
in above example
1) "id" attribute is supported/resolve in typical XML DOM fashion
(com.intellij.spring.model.xml.BasicSpringBean#getId)
2) "p:bar" / "p:helper-ref" are currently not resolved/supported in any way.
(IDEADEV-14263)
Perhaps they could be - that would be a usecase for the functionality
discussed in this thread
3) "myns:baz" - spring allows 'namespace handlers' to add arbitrary attributes
on some specific elements.
These should continue to be resolved using the built-in DTD/XSD support.
So an additional complication of what I'm asking for is that it should be
possible to have some amount of "dynamism", but have the possibility to fall-back
to the existing DTD/XSD support.
In above exampe, it would be nice to plug in something like an "attribute
resolver/provider" for attributes from the "http://www.springframework.org/schema/p"
namespace, but not for any other namespace.
When I wrote about nice functionality, it was exactly Spring2 that I was
thinking of. And will continue to do so.
What do you mean by fall-back?
It would be nice to plug-in for all custom namespaces that are valid in
Spring2. And we'll do it, at least for some simple cases.
Hello Peter,
>> So an additional complication of what I'm asking for is that it
>> should be possible to have some amount of "dynamism", but have the
>> possibility to fall-back to the existing DTD/XSD support.
>>
I mean if such a (hypothetical) "DynamicAttributesProvider" is queried for
possible attributes - and this provider returns "I do not have any suggestions"
- then attribute suggestions from DTD or XSD should be presented. In other
words, such a provider of dynamic attributes should not be "authorative",
rather it should "contribute". It should not override DTD/XSD attribute completion.
>> In above exampe, it would be nice to plug in something like an
>> "attribute resolver/provider" for attributes from the
>> "http://www.springframework.org/schema/p" namespace, but not for any
>> other namespace.
>>
I assume you mean namespaces that are shipped as part of Spring?
One complexity of the Spring 2.0 XSD-based format (from tooling perspective)
is that it's possible to extend it with custom namespaces (IDEA-12489).
It's also very safe to assume that Spring team itself will be publishing
new namespaces after Selena release. (for example as part of Spring 2.1)
An aspect of this extension mechanism related to this discussion is that
spring includes a tooling schema. Namespace handler authors can annotate
their schema using tool annotations - for example to indicate that an attribute
must reference a bean of a given type.
It should be possible to support this - and this sounds a bit like "runtime
DOM model".
Taras
Of course.
>> It would be nice to plug-in for all custom namespaces that are valid
>> in Spring2. And we'll do it, at least for some simple cases.
>>
No, I mean user namespaces as well.
Hello Peter,
>> I assume you mean namespaces that are shipped as part of Spring?
>>
If you mean the latter, you'll at least have to:
-load/call namespace handler classes from project classpath
(there is at lease one precedent: TagExtraInfo-based completion in JSP editor)
-provide some translation between spring native model and IDEA one
How concrete are the plans for this infrastructure? I've been playing with
the tooling support inside spring recently, and probably can contribute some
ideas here. Or at least I can contribute problem scenarios which you'll have
to solve :)
Taras
Possible solution: if IDE can't find the reference using schema / DTD then it get DynamicXmlAttributeProvider and calls its resolve method.
IDE should provide the method for registering these providers, and Taras will register SpringDynamicReferenceProvider, and I'll register TapestryDymanicReferenceProvider :)
>> -provide references from attribute name to setter method
I don't understand the difference between this and registering usual
PsiReferenceProvider on XmlTag and XmlAttributeValue.