The Java RIA Framework

Pierre,

I think I get the general idea (using constants for component values), but I think I don't understand the EventTypeInterceptor code (i.e. you change the reference of the parameter passed-in). Well, if I translate correctly, this lifecycle interceptor should be registered on the component-owning class (the one that holds the type reference), right ?

IMH, the checking of reference for component is not a good idea: a component has no identity, it's a value object. If each attribute of two components has same value, then the two components are equals.

I agree with you. But as far as I can remember, I had some problems with Hibernate and Jspresso dirty state detection (but I may be wrong, so let's have a look at it again).

Equality and hashCode can be implemented based on component properties equality (hashCode). Everything is actually accessible from the proxy implementation class, so no technical problem on this side.

Do you know that you can even do it yourself, i.e. change the default implementation used by Jspresso for implementing the components J2SE proxy without modifying the Jspresso code itself ? It may be a good scenario to try it out :

1. Subclass BasicComponentInvocationHandler and ControllerAwareComponentInvocationHandler. Those are the 2 default implementation classes used by Jspresso for components.
2. Override computeEquals and computeHashCode to implement equality/hashCode based on the component property map. you can use the straightGetProperties() method of the IComponet interface to do so.
3. Subclass BasicProxyComponentFactory and ControllerAwareProxyComponentFactory and override the createComponentInvocationHandler method to return instances of your subclasses (see 1.) instead of the default ones.
4. in config.xml, which is the last Spring context file loaded, you can override the standard bean definitions for basicComponentFactory and sessionAwareComponentFactory. Just clone the standard definition from commons.xml and substitute your factory subclasses (see 3.) to the default ones.

Now, each and every component created in your Jspresso app should use your implementation. Same is also available for entities.

Meanwhile, I'm taking a look to the default behaviour.

Best,

Vincent

Pierre,

I've implemented the default behaviour as you suggested. The dirty checking problem was linked to something else, so everything runs fine.

I've published a new SNAPSHOT including the fix as well as the computeHashCode API change to align it with computeEquals.

Tell me if it fits.

Best,

Vincent

Pierre,

it doesn't manage a component attribute with a type using special case values when the component is created or loaded from the persistence layer

Today, lifecycle interceptors are only triggered for entities. Following your idea, it would make sense that inlined components also get their lifecycle interceptors triggered, right ? So for instance, when an entity is updated to the persistence store, its interceptors get triggered and the interceptors of its inlined components also ? It definitely makes sense.

Would you open a feature request ?

Oups, it's already implemented. So what you say is that onCreate and onLoad don't get triggered for inline components (following their owning entity lifecycle) ?

and a modified valueConnector gets a value for the UI from the special case value of the model, e.g. SomeComponent.VOID => null

If I understand right, and if I take back your example of null <-> SomeComponent.VOID, you want :

• UI components to use null for the value binding
• component getter to return SomeComponent.VOID (never null)
• component setter to accept both null and SomeComponent.VOID
• component internal state to use SomeComponent.VOID exclusively (never null), so that the hashCode/equals based on property values works.
  
• persistence store to use null exclusively

This seems to me really complicated, but maybe I'm missing the use case behind, and the advantage of such a construct.

BTW, why wouldn't you just declare a (writable but stateless) computed property that takes care of this maping ? e.g. all the internal framework mecanisms (binding, persistence, ...) still use the original property (with null value) and you code your business rules against the computed property (that deals with SomeComponent.VOID and takes care of the mapping between the constants and the actual original values) ? IMHO, it would bring all the benefits you need, i.e. the mapping is written once and kept in one place, is only used for accessors on the component and you don't have to play with Jspresso binding implementation.

Would it be possible to do the job with some kind of getter in IPropertyProcessor

The actual implementation doesn't use plain getters for Hibernate to retrieve the state of the entity/component to persist. So it wouldn't be useful. More importantly, I don't feel like opening the door to linking some triggered behaviour to reading a property.

HTH,

Vincent

Pierre,

Just for the sake of accuracy :

a LifeCycleInterceptor can be used to add some custom actions between the model and the persistence layer

Right (even if onCreate is not directly linked to the persistence layer, i.e. in-memory instanciation).

and a PropertyProcessor can be used to do it between the model and the UI, but only in the direction UI->model

Not only between UI -> model (even if this is the most common case). Property processors will be triggred every time a modifier on the property is called (so even during a business rule, that is UI-less).

keep us informed about your tries.

Best,

Vincet