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) {}
}
---
<node someString="foo" someNumber="42"/>
---

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?

Not yet. And I can't imagine any common use case and implementation for
such things.

Hello Peter,

Not yet. And I can't imagine any common use case and implementation
for such things.

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.

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,

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.

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.

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.

What do you mean by fall-back?

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.

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,

When I wrote about nice functionality, it was exactly Spring2 that I
was thinking of. And will continue to do so.

>> 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.
>>

What do you mean by fall-back?

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.
>>

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.

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

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.

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.
>>

I assume you mean namespaces that are shipped as part of Spring?

No, I mean user namespaces as well.

Hello Peter,

>> I assume you mean namespaces that are shipped as part of Spring?
>>

No, I mean user namespaces as well.

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

-provide references from attribute name to setter method

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

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 :)

I don't understand the difference between this and registering usual
PsiReferenceProvider on XmlTag and XmlAttributeValue.