Michiel Meeuwissen <[EMAIL PROTECTED]> wrote:
> I also added the 'EnumHandler' functionality, by which now you can add
> 'enum' types (dependant on the 'guitype' of an integer) to FieldInfo
> without recompiling and java-coding. This depends on a ResourceBundle
> of which the name is based on the guitype, which make it e.g. also
> internationalized. I make an example for the 'dirs' field of reldefs
> which now can appear as a dropdown box in the editors (even with
> internationalized content). Until now this simply was an input-box
> where you had to type '1' or '2'. After this hack you can choose
> between 'unidirectional' and 'bidirectional' (or
> 'unidirectioneel/bidirectioneel' etc,) and it will be possible to add
> these kind of things as many as you like (by use of property files)

In the 'media' project these kind of things are needed too (Think for
example of a dropdown of statuses of media source, a dropdown of
stream servers etc).

For the moment I tried to use the above-mentioned 'enumhandler'
functionality with resource-bundles to add the dropdown functionality
to jsp-editors. This works fine. I have not found a satisfactory
sollution to use the same lists in the editwizards too, but I do not
doubt that I would succeed in this.

Before going on though I would like to see some kind of discussion
about a 'vision' how these things will be solved in future mmbase
releases, because now we can find several different ways.

So, besides the ones I don't know about or I forgot, there are:

1 The 'ad-hoc' ones. For example the 'guitype' 'reldefs' will result
  in a dropdown box, and the content is determined by a query in IntegerHandler

2 The 'node' types. If the type is 'node' and the 'guitype' a
  nodetype, then the dropdown box will contain a list of all
  nodes. This does not work in e.g. the editwizards. I don't know if
  it works in scan.

  I thinks a few 'ad-hoc' ones can be replaced by this (and in CVS, are)

3 In the editwizards it is possible to define a 'optionlist'. It can
  be centralized with SYSTEM entities, but the content of those lists
  cannot be easily shared with the lists used in for example
  jsp editors. I think these options can also be defined by a query.

4 The above mentioned 'resources'. If the type is 'integer' then the
  gui type can be a 'resource' and in jsp-editors you get a drop-down
  box (in the right language)

5 In the 'MediaFragments' of the media project we see the use of a
  'lookup' table with key-value pairs. This is not used in
  jsp-editors, and I doubt if it can be now.

  The basic idea of storing the enums in the database (like also 2
  does) does not seem so bad though.

6 Pierre came up with guitype enum/identifier which then could be
  used in editwizards.

- more?

We are in a freeze so we cannot change everything now for a generic
solution, but I do think it is wise to think now about it, because it
is not too late to make a few small changes in code and documentation
of 1.6 about what is the 'preferred' way of doing this.

I would imagine that what actually needs to be done is the definition
of a template for this purpose. Such a template could be implemented
using an mmbase object model or resources or whatever seems
appropriate in for the case. The 'implementation' then somehow has to be
configured in guitype of the field. Perhaps something like this:

<guitype>integer</guitype>        <!-- default, not an enum -->

<guitype 
class="enum/org.mmbase.module.builders.ResourceEnum">org.mmbase.applications.media.resources.states</guitype>
 
 <!-- use resource -->

<guitype class="enum/org.mmbase.module.builders.LookupEnum">formats</guitype>      
<!-- use lookup table -->


Such an enum interface should be instanciated with a cloud (for
implementation based on an object model) and the value of guitype or
something like that (serving as a configuration).

Like said, I'd prefer not to implement all this in 1.6 yet, but if it
would be possible to make the 'configuration' and 'extenstion' on the
current 1.6 implementations (like the media project) forward
compatible with a generic solution of e.g. 1.7 then that would be
desirable I think.

 greetings, 

 Michiel

-- 
mihxil'  Michiel Meeuwissen 
Mediapark C101 Hilversum  
+31 (0)35 6772979
[]() 

Reply via email to