API overview

It would be nice to have an API overview available, but ... sorry, not yet.

Global Search

Idea: I would like to search a subset of all the beans in my application (which could be the set of all beans) through a generic search form; the search form maybe can use the FormDescriptors in order to introspect the beans.

Challenge: How to enable that not always all beans is looked at when searching?

sweet-titles

Use something like sweet titles?

Example using databinder

Idea: Have an attribute on an article which uses jtextile to display it's rendered text.

How to use blobs with hibernate?

Make a more complex example, with e.g. inheritance in the model?

doesNotFit. Somehow something does not fit:

1. The form descriptors describe some viewing information per class. Well, not necessarily, look into createEditBeanPage of the BeanPageFactory instantiated inside Webby4DBConfigurator.
2. There is no way to have state in the view. Example where this would be nice: There is a bean with a description (e.g. written using textile) which should (normally) be displayed only. But sometimes I'd like to change it, which means switching to some kind of edit mode (which is a stateful action in the view, isn't it?), doing the changes, and then switching back.

   <default>: View
   type: Company
   singleton: select from ...
   Company.description.type=JTextile(mode=view)
   Company.id.isVisible=false
   
   Browse articles: View

About state: Such stats should be owned by the user:

user --> state

State can define attribute values of the view. Examples:

• isVisible=false for an element in the view, e.g. a column in a table or the list of the articles relation.
• length=25 for the length of the edit field in the edit form.
• instance=org.somepackage.SpecialEditField for the instance that shall be created for the attribute in the edit form.

What about just defining an object model (that can be persisted) which defines the structure needed? Classes then would probably be:

Entity (1:1 to FormDescriptor) --* Attribute
                               --* Relation
... pretty similar to the classes there are already in webby?

BeanPageFactory

BeanPageFactory
  Page createEditBeanPage(IModel model);

Should have a default implementation which instantiates SimpleBeanPage instances.

SimpleFormDescriptorFactory

This factory can be used to create simple ("default") descriptors which use introspection to analyze the classes given as a set of viewable classes to the factory.

BeanAction

The idea of a BeanAction is that independant of how a possible action on a "business bean" is presented, an action can be described, so that Webby can present the action to the user. Finally, the user should be able to execute the action, of course...

There should be a List (NOT a Set) of BeanActionDescriptors available for every FormDescriptor. Maybe later also for RelationDescriptors there could be a list of those actions that are intended to be available for each item in a list of related beans/objects.

BeanActionDescriptor
  isActionVisible(IModel model)
  isActionEnabled(IModel model)
  void execute(IModel model)
  String getDisplayName(IModel model)

Inside and outside of Webby: Enable easier integration

If you want to use Webby just to show/navigate beans using the forms and lists which are part of Webby itself, it is easy. If however you want to mix the UI stuff and application flow provided by Webby with other UI support, this can't be done so easily: You could implement your own BeanPageFactory, but this would only allow you to go to your own page whenever the user follows a to-n relation.

In order to make this better, let's look at the following which seems to be true:

1. Webby should control the application flow partly, but not completely. This is true because not controlling the flow means too much work for implementing the UI if you want to use Webby. (And it's one of the goals of Webby to rather describe what to show than how to show it.) On the other hand, controlling the flow completely ...
2. Having the navigation from a bean to a related bean (either via a to-1 or a to-n relation) controll by Webby seems logical.
3. A good moment to be able to switch from Webby control to other control is when an action is executed.

This leads to the following design change: Instead of

void execute(IModel model)

it will become

Page execute(IModel model, Page currentPage)

whereas the currentPage is the current page for which the action is executed from (what a surprise ;-) and the return value is either the same as the currentPage parameter or null in order to indicate that the page shall not change, or it is any other page which will be set as the new page using Component.setResponsePage.

...

Inheritance? What's this??

Most probably using inheritance in the model results in ugly (or hardly usable) results: Most probably I would not see attributes of sub classes in the lists, maybe I would not even see those attributes on the edit page!

This is something to be worked on, I'd say.

Allow actions to be taken from the beans?

Idea: Allow actions to be taken from the beans instead of explicitly code them in the configurator?

Possible solution: Actions could be coded in the bean directly as methods and marked via annotations:

Use annotations to mark those methods of a bean that shall be visible as an action in the UI. How it is made visible is not to be decided by the bean but by webby. There is however some limited control about "what comes next" in the application flow by what is returned:

• If the method returns nothing, the page stays the same.
• If the method returns an entity object, a page with the entity object is displayed.
• If the method returns a Collection of entity objects, a list with the entity objects is returned.

By the way, it should still be possible to add actions via the descriptors!

Advantages of this solution:

• Behavior is coded in the beans themselves, not in the UI framework.

Disadvantages of this solution:

• If the coded action wants to make use of anything from webby, then a build time dependency is created to webby which might be unwanted. (?)

@interface Action {
  String displayName();
}

Possible enhancement: Annotate a resource id instead of a display name. This way internationalization of the display names might be possible.

Together with webby4db it is an issue when to commit the transaction: Committing the transaction inside the annotated bean method does not allow the creation of a bean model (HibernateObjectModel) any more afterwards, because the transaction is closed. Thus we need a specialisation of SimpleBeanAction in webby4db: This can be enabled by a BeanActionDescriptorFactory provided via WebbyConfigurator getBeanActionDescriptorFactory?

To-1-Relation: Enable changing them, if descriptor allows it

Idea: Allow the user to set a to-1 relation, provided that the property descriptor gives a list of choices.

The list of choices should be given indirectly however: the propertydescriptor should return a factory which takes as argument a bean object and returns a List of choices (of beans that could be assigned to the to-1 property via set<PropertyName>. During runtime (i.e. when the page is rendered) this List can be loaded via a LoadableDetachableModel ... well, the LoadableDetachableModel should invoke the factory method. (See also OrderbookConfigurator in webby-orderbook, revision 1.3.4.3.) Thus in short:

interface ChoicesFactory { // new interface
  List getChoices(Object bean);
}

// add following to To1RelationPropertyDescriptor:
  ChoicesFactory getChoicesFactory()

// extend To1RelationBeanFormPanel to make use of this information
...

// extend SimpleFormDescriptorFactory to add useful <<<ChoicesFactory>>>'s to the simple
// form descriptors

Exception handling? Error handling?

Currently, there is no exception handling implemented: Whenever an exception must be caught, it is typically wrapped in a RuntimeException. No exceptional situation is handled seriously. (This is of course due to the early stage this piece of software is in...)

This seems particularly bad when calling actions which are coded in the model: An exception could represent an exceptional situation in the business logic. Then there should definitely not be a runtime exception thrown, but rather an error handling should be in place which allows smart reactions on the exceptional situation.

Use a date attribute?

Is possible, see the example Webby Projects. However it is not very comfortable: You have to know the date format to be used. Improvements could be

• display the format to be used
• use a date picker component to make it easier.

  How exactly could this be done? Maybe a good support could be via annotated components to be used for properties, see next section.

Cleanup log messages

Not done yet.

Business IDs?

PersistentObject.businessId

BusinessIdGenerator
  long lastId
  long getNewId(Session)
  static getInstance

Enabling business ids in the way they might be a good idea for hibernate is not in scope of what should be done with webby: Webby is independent of the persistence layer.

There is another project webby4db which might be interested in supporting business ids as sketched here.