The Java RIA Framework

Hi Marc,

There is already such a concept in Jspresso but it's not yet documented. I would actually need 36 hours in day ...

Look at the org.jspresso.framework.view.descriptor.ICardViewDescriptor interface and its hierarchy (give the source code a look) :

• AbstractCardViewDescriptor is the base class for all card view descrriptors.
• EntityCardViewDescriptor is a concrete implementation that choses the view to display based on the entity class
• WorkspaceCardViewDescriptor is the view descriptor used in a Jspresso application to render the application main pane based on the selected workspace/module.

A card view is a stack of views (like the swing card layout) where only the selected card is made visible. The decision to display a card is made by the getCardNameForModel(Object) method. So basically, all you would have to do is create your own subclass and implement the getCardNameForModel(Object) method to implement your business rule and select the appropriate view key accordingly.

This could be made even simpler if we could inject the card determination strategy in Spring, i.e. have a contrete BasicCardViewDescriptor that can be injected with an instance of a class responsible for determining the view based on the model instance. This could be a feature request (would you create it ?).

Just a remark : Card views are best used as detail view in a master-detail, i.e. you would include it in a container where cascadingModel=true so that the model gets dynamically assigned depending on the selection made on the master view.

To be complete, regarding dynamic editability of a view or view part, there is another undocumented yet feature. It is the concept of accessibility gates. You can assign to a view (or a sub view) descriptor, a collection of writability (and readability) gates (see the org.jspresso.framework.util.gate.IGate class hierarchy). What it means is for the produced view to be editable (writable) all gates must be open. And Jspresso provides built-in gate types that open and close dynamically based on model boolean properties (org.jspresso.framework.binding.model.BooleanPropertyModelGate).

I hope this helps.

I'm sorry I can't elaborate more at this time since I'm about to leave for 3 weeks of vacations (at last...). Of course you can continue to post your ideas/questions/bugs to the forum (and I really appreciate that), but just be aware that I won't be able to answer (at least not deeply nor regularly) until I come back.

Best,

Vincent

Marc,

I've created and implemented the 2 feature requests of this thread (2850085 and 2850082). Regarding your objectives, I've also double checked the correct behaviour of IModelGates assigned to views. There was actually a bug that would have prevented your use-case to get correctly implemented. This is all fixed now.

Everything is included in the 3.0.1-SNAPSHOT that I'm uploading now.

Best,

Vincent

Hi Marc,

A few line of code should hopefully make things clearer. Try to move around the following Spring XML lines :

    <property name="writabilityGates">
      <bean class="org.jspresso.framework.binding.model.BooleanPropertyModelGate">
        <property name="accessorFactory" ref="accessorFactory"/>
        <property name="booleanPropertyName" value="persistent"/>
        <property name="openOnTrue" value="false"/>
        <property name="grantedRoles">
          <list>
            <value>administrator</value>
          </list>
        </property>
      </bean>
    </property>

They basically say :

Create a gate that is open when the model is not (openOnTrue=false) persistent (booleanPropertyName="persistent"). The gate can only be opened by a logged-in user that has the administrator (grantedRoles=["administrator"]) role. The framework will do the rest, i.e. apply the model, trigger the isPersistent() method, react on property change events (when the persistent property changes, i.e. when an entity is saved), check that the subject is granted the right to open the gate.

1/ include the previous snippet in model.xml in one of your entities. All the views backed by this entity will be impacted. When the view model is transient, the view will be editable and when the view model is persistent, the view will be read-only. I must admit that it's not a real-life use-case . Try to create an entity, edit some values, save and you should not be able to edit anything more...

2/ transfer the previous snippet on an entity property descriptor instead of the whole entity. Now only the fields (and table cells) backed by this property will have the behaviour described above.

3/ now transfer the snippet from the model.xml to the view.xml. Include it in a view. Only this view will be impacted.

4/ now transfer it on a "PropertyViewDescriptor" (those are used to refine table columns, using the columnViewDescriptors property and form fields using the propertyViewDescriptors property). Only the column (or the form field) of the enclosing view will be impacted.

The objective is that you never have to mess around with getting the model and so on.

Note 1 : I reworked slightly things in order to simplify using the subject roles in gates. So this code with the grantedRoles assigned to the gates will only work on tonight snapshot.

Note 2 : If you only want to display/hide fields, columns or complete views based on the logged-in user roles, you can use the grantedRoles property (but this one is in the manual) on model and/or view with the same kind of cascading mecanism as the one described above.

Note 3 : gates, as well as the simpler grantedRoles property can also be used on actions.

Hope this helps.

Best,

Vincent

Marc,

Vincent would surely complete/correct these answers. Here is what I think I understood:

- I see that JSpresso generates java classes for entities. Also hybernate mapping and the SQL table creation script are generated. Does JSpresso generate other classes?

Short: no.

Long:

The only template is HibernateXdocletEntity.ftl, used to generate the entity interfaces. It's a FreeMarker template which has nothing to do with hibernate but to insert the right hibernate tags. (It could be JPA in a future version...)

From these entity interfaces, Hibernate is able to generate all the files it needs.

From the configuration files (i.e. the Spring files), no other files are genereted by jspresso.

Note: may be I'm wrong about some specific files for UI like the qooxdoo one.

-I guess that all files whose name ends with "Descriptor" correspond exactly with the structures in the JSpresso/Spring/XML files that we author to model an application. Is this correct?

Yes

-About Spring Dependency Injection: I guess it is used essentially to create instances of "Descriptor"-classes that are part of the framework

Yes but not only, see below.

and have been coded manually.

Mmm, if you mean instances of "Descriptor"-classes as specified in a spring configuration file, then yes. But you never code manually (i.e. in java) such a class.

At least  until you want to enhance the capabilities provided by jspresso, e.g. to deal with joda date and time, or to define a specific authentication process (it reminds me that these two topics would be good wiki entries...)

If you mean classes coded manually by you, and injected in any hook provided by jspresso, you are still right. See:

- Service delegate classes

- Extension classes

- Interceptor classes

- Processor classes

- Action classes

- ...

Or does Spring Dependency Injection also create new classes by interleaving things?

Not sure I understand what you mean here (autowire? proxy?).

It's all for now...

Pierre

Vincent,

About Spring DI: Just consider it as a smart and compact way of creating and assembling POJOs to build your app. There is really nothing more. You could actually do it in plain java, but it would be much more painful.

In a previous thread you said you were thinking about replacing xml by some king of dsl for the Spring configuration files. But what about Spring Java Configuration Project?

Regards

Pierre

Marc,

I've just seen that you were writing a Wiki entry for gates ! I've just changed your user permissions so that you can use the advanced WYSIWYG editor for formatting.

Thanks for your contribution !

Vincent