The Java RIA Framework

Hi DiegA !

sadly there are many times in the real world when you have to deal with physical constraints...is it always possible for Jspresso to address this kind of concerns from the logical approach?

I completely agree with your point here and of course, there are a lot of room for physical optimizations (one of them is DB indices, for instance) that Jspresso doesn't handle from scratch (is it even possible ?). I've also been part of large ERP-like projects and I think know what you mean .

I would just try to keep things cleanly separated whenever it's possible. For instance, we could have another kind of physical "descriptors" that would only be used at compile/generation time, living in another Spring context file that is only registered when the generator runs in the maven build. This special generation context would hold everything that doesn't need to be kept at runtime (e.g. the Hibernate inheritance mapping strategy).

we had recently dropped a very nice framework for similar reasons (JMatter, I don't know if you are familiar with it)

I've heard/read about JMatter but never practiced. Jspresso still has a small community and in a way, that's an opportunity for fast improvements when needed. So don't hesitate. Even if we have to make a living outside of Jspresso, we try hard to be as responsive as possible.

I think that it would be great if Jspresso had this concerns in mind, since you are already using Spring, you could make the framework even more pluggable than it already is.

Well, a Jspresso application is "just" an assembly of Spring beans. And Spring brings the magic of being able to override bean definitions whenever you need it. For instance, you can override standard Jspresso beans (keeping the same id , of course) in the your application spring config files and adapt each and every default behaviour. This can lead to feature enhancements for the price of a few lines of code (e.g. introduce KPIs, change part of the UI generation, ...), or even clean patching of features you would like to fix/improve (until Jspresso offers a solution ).

This is mainly due to the fact that your application spring config files are registered after the Jspresso framework ones and thus take precedence.

...Like for example the EntityGenerator and the GenerateSQLName class...

Well, I'm not on the same road here. For this precise example, I would rather make a Maven plugin out of the entity generator; and the naming strategy would be one of the configuration options among others. But time is running out and the antrun plugin was (sadly) the quick way to go to get everything integrated in a single maven command build.

it would be great if instead of it, the view.xml would be automatically generated

I like the idea of generating "ready to use" view parts that you could assemble. But today the view.xml is produced by the Maven archetype to bootstrap the application development. Afterwards, e.g. when you have begun to describe your model, it will never be touched again by the build process. In this area, I really think that the future of Jspresso lies in an Eclipse plugin that would help the developer in designing (assembling) the application by "hiding" the application Spring config files.

But having said that, It would be possible to include, during the Maven generation process, the creation of an XML file that would serve as a depot for generated views that you could cut and paste in your actual view.xml.

maybe you have a more extensive documentation

All I have written is available. There is no hidden stuff that I would keep for super-privileged customers (until now, at least ). I know that there are a lot of areas that are not covered enough (actions is one of them), but ultimately, there is the source-code... and the forum. I will be glad to answer your questions in detail (it will be then a good source for improving the reference manual). Moreover, I've received a very clever suggestion of building a showcase application that would demonstrate interactively each and every Jspresso features (from the model to the views, passing by the actions, the workspaces and modules, printing, external components integration, wizards, ...), along with their individual sourcecode. This is high priority on the @TODO and I think it will really help. But I definitely want to finish the Qooxdoo integration before so that we can have an AJAX fron-end that is even better than the Flex one. I'm 80% done on it.

...if you dont have any problems with us collaborating on everything that we can.

Of course, you're warmly welcome!

..."dont forget about us" we meant just an acknowledgement somewhere in tiny fonts.

What about a section on the site that would list suggestions / ideas / pieces of code that have been suggested/contributed ? Would it fit ?

Best regards,

Vincent

DiegA,

Nothing is dumb outhere . And your questions are just valuable feedback and help improving Jspresso.

1) How can I display a my view directly without the initial filter screen?

Well, in that case, you have to declare a org.jspresso.framework.application.model.BeanModule explicitely in the modules list of your workspace. Configure it with a projectedViewDescriptor that references your view and a componentDescriptor that references the root model it works on. Of course, you should configure other properties like name, description, ... Then, you have to tell Jspresso how to populate the model when the module shows. This is done by registering a startupAction on the module itself that will do the job of retrieving the model from somewhere (or maybe create it in memory). Here is a skeleton of such a module startup action :

public class MyStartupAction extends AbstractBackendAction {
  @Override
  public boolean execute(IActionHandler actionHandler, Map<String, Object> context) {
    BeanModule myModule = (BeanModule) getModuleConnector(context).getConnectorValue();
    Object myBean = [retrieve or create your model]
    myModule.setModuleObject(myBean);
    return super.execute(actionHandler, context);
  }
}

2) Is there an easy way to make the icons bigger?

Not in the 3.0.0 version. Icon dimensions are hardcoded in final static constants and yep, this is bad. But I've just improved it in the new 3.0.1-SNAPSHOT so that the icon factory can now be configured with the dimensions to use for the icons. If you want to change them, you can do it by overriding the abstractIconFactory bean definition in your application Spring config files (this is the parent of all icon factories), e.g. :

  <bean
    abstract="true"
    id="abstractIconFactory"
    class="org.jspresso.framework.view.AbstractIconFactory">
    <property
      name="okYesIconImageURL"
      value="classpath:org/jspresso/framework/application/images/ok-48x48.png" />
    <property
      name="noIconImageURL"
      value="classpath:org/jspresso/framework/application/images/no-48x48.png" />
    <property
      name="cancelIconImageURL"
      value="classpath:org/jspresso/framework/application/images/cancel-48x48.png" />
    <property
      name="infoIconImageURL"
      value="classpath:org/jspresso/framework/application/images/info-48x48.png" />
    <property
      name="warningIconImageURL"
      value="classpath:org/jspresso/framework/application/images/warning-48x48.png" />
    <property
      name="errorIconImageURL"
      value="classpath:org/jspresso/framework/application/images/error-48x48.png" />
    <property
      name="forbiddenIconImageURL"
      value="classpath:org/jspresso/framework/application/images/forbidden-48x48.png" />
    <property
      name="backwardIconImageURL"
      value="classpath:org/jspresso/framework/application/images/backward-48x48.png" />
    <property
      name="forwardIconImageURL"
      value="classpath:org/jspresso/framework/application/images/forward-48x48.png" />
    <property
      name="upIconImageURL"
      value="classpath:org/jspresso/framework/application/images/1uparrow-48x48.png" />
    <property
      name="downIconImageURL"
      value="classpath:org/jspresso/framework/application/images/1downarrow-48x48.png" />
    <property name="tinyIconSize">
      <bean class="org.jspresso.framework.util.gui.Dimension">
        <property name="width" value="32"/>
        <property name="height" value="32"/>
      </bean>
    </property>
  </bean>

There are 4 icon dimensions that are used in Jspresso depending on the context (button, message dialog, ...), and thus 4 dimensions that can now be configured : tiny, small, medium and large icon sizes.

3) Why do the child-windows dont have the X button for closing them? How could I add that button?

Well, not easily workable by overriding. Depending on the UI channel used, the different UI controllers may use a MDI UI with internal frames (Swing, ULC and Qooxdoo) or a simple stacked view (WingS and Flex). This desicion is made in the UI controller (DefaultXXXController) but is not easily changeable as of 3.0.0. But I also improved it in the new snapshot so that MDI workspaces internal frames are now closeable.

4) About the grid in the filtered views. Is it possible to make them readonly?

As a general tip you can make any Jspresso view readonly by setting the readonly property to true in the view descriptor. If you want to change the default state of the filter view table, you just have to do the following (look for your module definition in frontend.xml that should extend abstractFilterableBeanCollectionModule) :

  ...
  <bean parent="abstractFilterableBeanCollectionModule">
    ...
    <property name="projectedViewDescriptor">
      <bean parent="filterableBeanCollectionModuleView">
        <property name="readOnly" value="true"/>
      </bean>
    </property>
  </bean>

and to edit the rows by double-clicking them?

Well again, I had to slightly improve the framework to achieve this. In the new 3.0.1 snaphot, collection property views (list and table) now have a rowAction property that will react on a user double-click. Note that this property will be ignored on the WingS frontend since WingS does not allow to distinguish a double from a simple click. So, to do what you want, you just have to reference the standard addAsChildModuleFrontAction to the filterableBeanCollectionModuleView we've updated above, i.e. :

  ...
  <bean parent="abstractFilterableBeanCollectionModule">
    ...
    <property name="projectedViewDescriptor">
      <bean parent="filterableBeanCollectionModuleView">
        <property name="readOnly" value="true"/>
        <property name="rowAction" ref="addAsChildModuleFrontAction"/>
      </bean>
    </property>
  </bean>

The Qooxdoo integration sounds really cool (I really dont know much about it, is it so different than Wings, why both?)

There are several advantages over WingS. Qooxdoo relies on HTML divs rather than tables to layout components. This leads to much more flexible layout and richer components (table columns can be moved, split panes, ...), and greater performance (FF has a big performance hole on deeply nested HTML tables) . And I love the look and the design; you should have a look to the Qooxdoo demos to make your mind. But Qooxdoo is a client UI technology and we had to leverage the generic communication layer we have developed for the Flex integration (100% reused ).

BTW, do you have a Roadmap somewhere?

Not written. But there are plenty of exciting things that are waiting for us.

BTW-1, it would be nice if we could try to keep 1 forum thread == 1 subject. This one "Newbie in Jspresso" is quite not a newbie thing anymore . This will help for refering back to single-subject threads when needed.

BTW-2, linking to Jspresso 3.0.1-SNAPSHOT should be just a matter of changing the root pom of your application and replace 3.0.0 by 3.0.1-SNAPSHOT. Or generate a new one by pointing to the jspresso snapshot repos :

mvn archetype:generate -DarchetypeCatalog=http://repository.jspresso.org/maven2-snapshots/

Hope this helps,

Have a good time with Jspresso.

Best

Vincent