XJC and the visitor pattern

[Christian Schulte]

Hello,

I would like XJC to add visitor support to schema derived classes.
Looking at jaxb2-commons and hyperjaxb3 I could not find a plugin
supporting this. Does such a plugin exist ?

Thanks.

--
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Wolfgang Laun-2]

On Mon, Oct 26, 2009 at 5:58 PM, Christian Schulte <cs@...> wrote:

Hello,

I would like XJC to add visitor support to schema derived classes.
Looking at jaxb2-commons and hyperjaxb3 I could not find a plugin
supporting this. Does such a plugin exist ?

 

Not specifically.

There is one for general purpose code injection. Adding the "accept" to any number of complexType definitions in the schema is probably abhorrent, depending on the nature of your schema.

A simple XSLT might take care of inserting the required annotation in all required places.

-W

 

Thanks.

--
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Christian Schulte]

Wolfgang Laun schrieb:

> On Mon, Oct 26, 2009 at 5:58 PM, Christian Schulte <cs@...> wrote:
>
>> Hello,
>>
>> I would like XJC to add visitor support to schema derived classes.
>> Looking at jaxb2-commons and hyperjaxb3 I could not find a plugin
>> supporting this. Does such a plugin exist ?
>>
>>
> Not specifically.
>
> There is one for general purpose code injection. Adding the "accept" to any
> number of complexType definitions in the schema is probably abhorrent,
> depending on the nature of your schema.
>
> A simple XSLT might take care of inserting the required annotation in all
> required places.
>
> -W

Maybe the visitor pattern isn't the correct solution to what I am trying
to solve. I thought about something like the following:

interface Visitor
{
  accept(A a);
  accept(B b);
  // One accept method for each schema derived class.
}

class A
{
  List<B> getB()

  accept(Visitor v)
  {
    v.accept(this); // Can be done with XSLT.

    for(B b : getB()) // Cannot be done with XSLT, I think.
    {
      v.accept(b);
    }
  }
}

So that whenever the schema changes structurally, the visitor would not
have to be changed. The problem is adding the accept methods to the
classes. The body of those methods will change whenever the schema
changes and I thought about some XJC plugin which could handle that. Any
ideas ?

--
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Aleksei Valikov]

Hi,

> I would like XJC to add visitor support to schema derived classes.
> Looking at jaxb2-commons and hyperjaxb3 I could not find a plugin
> supporting this. Does such a plugin exist ?

I don't know of such plugin, but I think writing it makes sense.
Would you mind putting together few code examples - as you expect ths
visitor pattern to be implemented? We can discuss the design and I can
overtake the implementation.

Bye,
/lexi

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Christian Schulte]

Aleksei Valikov schrieb:

> Hi,
>
>> I would like XJC to add visitor support to schema derived classes.
>> Looking at jaxb2-commons and hyperjaxb3 I could not find a plugin
>> supporting this. Does such a plugin exist ?
>
> I don't know of such plugin, but I think writing it makes sense.
> Would you mind putting together few code examples - as you expect ths
> visitor pattern to be implemented? We can discuss the design and I can
> overtake the implementation.
>
> Bye,
> /lexi
>

Comparing the two java examples given at [0] and [1], I am not quite
sure how those accept methods would need to be implemented (and if
that's at all what I am looking for). If all there is to implement in
those accept methods is a line of code like 'visitor.visit(this)',
things should be really easy. If the accept method additionally iterates
all referenced objects, things could become quite complex. I am a bit
confused about that pattern now, I admit.

[0] http://de.wikipedia.org/wiki/Visitor
[1] http://en.wikipedia.org/wiki/Visitor_pattern

--
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Aleksei Valikov]

Hi,

> Comparing the two java examples given at [0] and [1], I am not quite
> sure how those accept methods would need to be implemented (and if
> that's at all what I am looking for). If all there is to implement in
> those accept methods is a line of code like 'visitor.visit(this)',
> things should be really easy. If the accept method additionally iterates
> all referenced objects, things could become quite complex. I am a bit
> confused about that pattern now, I admit.
>
> [0] http://de.wikipedia.org/wiki/Visitor
> [1] http://en.wikipedia.org/wiki/Visitor_pattern

I don't think classic visitor is suitable since you'll end up with one
method per class in JAXB context and that can be quite long. Another
thing is that it is often helpful to traverse a tree in depth, classic
visitor would require a lot of programming to do that.

So I'm currently thinking of something like

public interface Visitor
{
  public void visitParent(Object parent);
  public void visitChild(Object parent, String fieldName, Object value);
}

and classes implement the Visitable interface:

public interface Visitable
{
  public void accept(Visitor visitor);
}

In the accept method all the schema-derived classes first call
visitParent and then iterate over fields, calling visitChild method.
Other possibilities are to use some kind of "locator" in place of
parent and fieldName.

What is your task, by the way?

Bye.
/lexi

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Christian Schulte]

Aleksei Valikov schrieb:
>
> What is your task, by the way?

I am currently looking for an elegant solution to validate schema
derived classes in a way that any validation errors can be collected,
processed and presented to a user. I cannot use schema validation for
this since those exception messages are quite meaningless from a users
perspective and the ValidationEvent interface does not provide enough
information to transform it to something more meaningful. So I was
thinking of something which simply passes every object in a given graph
to some callback interface. Ideally having something else generate an
abstract base implementation containing the validation logic from the
schema (facets, uses, etc.) so that the schema constraints could be reused.

Your visitor interface looks quite promising already. I wonder if it
would be possible to get it more typesafe so that an implementor ideally
would not need to do any instance of tests. That's quite the kind of
complexity I am trying to hide.

--
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Aleksei Valikov]

Hi,

>> What is your task, by the way?
>
> I am currently looking for an elegant solution to validate schema
> derived classes in a way that any validation errors can be collected,
> processed and presented to a user. I cannot use schema validation for
> this since those exception messages are quite meaningless from a users
> perspective and the ValidationEvent interface does not provide enough
> information to transform it to something more meaningful. So I was
> thinking of something which simply passes every object in a given graph
> to some callback interface. Ideally having something else generate an
> abstract base implementation containing the validation logic from the
> schema (facets, uses, etc.) so that the schema constraints could be reused.

I have solved such task for JAXB1, check the
https://jaxbvalidation.dev.java.net/ project. I have to say the task
is very very complex and I'm hesitating for years now to start the
implementation for JAXB2.

In any case, now I understand better what your requirements are. I
think it's better to start from the other end - to consider how these
callback interfaces should look like. In the first approach I would
expect something like:

public class MyObjectValidator implements Validator<MyObject>
{
  public void validate(ValidatorFactory factory, ObjectLocator
locator, ValidationEventHandler handler, MyObject value)
  { // validate value and send validation events to the handler}
}

Validator implementations may be registered with the validator factory
- or read by this factory, for instance, from annotations. When
validator is validating a complex object, it may request the factory
to create validators for its fields.

In this case you don't need the visitor pattern at all, you need to
generate validators which would allow subclassing and re-registration
in the validator factory.

I'd also check JSR-303 and Hibernate Validator. This may be a way to go.

Bye.
/lexi

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...