Would making events truly extensible mean not providing any built-in
types at all? Do the advantages of extensibility outweigh the
advantages of having some events built-in?
An issue with the "built-in" types is that they're not fully built-in.
The types are enumerated in the DTD, but the detailed settings for each
type are in limbo. These settings are hard-coded in the GUI but are
*not* hard-coded attributes in the domain DTD. The settings are
properties, and properties are typically used for third-party settings
of which the App Server has no knowledge.
If extensibility is the way to go, we should deprecate the existing
properties and provide mbeans that do the same thing. If built-in types
are the way to go, we should make the type settings attributes, not
properties.
My $0.02.
June
Bill Shannon wrote On 04/20/07 02:19 PM,:
> Senthil Chidambaram wrote:
>
>> Bill Shannon wrote:
>>
>>> Senthil Chidambaram wrote:
>>>
>>>> The six supported event types by GF can be extended. This is what
>>>> the document says, and that's how GUI is implemented. Sankara has
>>>> to confirm this.
>>>
>>>
>>>
>>> If the DTD only allows the six types, how can I add a new type?
>>
>>
>> You can't add a new type in the current screen flow. GUI is
>> implemented for the six supported types.
>
>
> First you say I can add a new type and then you say I can't.
> No wonder I'm confused!!! :-)
>
> Did you implement the GUI assuming there would never be any other
> event types?
>
> Or do you plan to completely redo the GUI in the future to support an
> open ended set of event types?
>
> Was it faster or easier to implement a GUI for six built-in types than
> to implement a GUI for an extensible set of types?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>