Re: Adding setComment on SFieldMeta

Le jeudi 01 octobre 2009 à 20:32 +1000, [email protected]
a écrit :
>   
> Glad to see the meta data being used. That was an original point of
> SimpleORM. 
> 
> There are actually several "Comments".
> 
> 1. PROMPT, SHORT_PROMPT: Default field name in UI, possibly long and
> short.
> 
> 2. DESCRIPTION, or TOOL_TIP: Tool tip like comment, a line or so.
> 
> 3. COMMENT?: Technical comment.
> 
> Probably the first two are the mains ones. They get concatenated to
> produce the commend DLL as 
> PROMPT:- DESCRIPION
> (say). Include a delimiter such as :- so that they could be reverse
> engineered later.
> 
> An enum sort of defeats the purpose of user extensibility. (Enums
> cannot be extended in Java, which greatly limits their usefulnes.) If
> they are well known, then maybe they should just be properties of the
> object, with get/set methods?

In fact userProperties is a Map<Object, Object>, so the key can really
be anything we want.
I was suggesting using an enum instead of strings for "standard"
properties to avoid conflicting with user keys,
eg. putUserProperty(SFieldProperty.PROMPT, "my prompt") won't conflict
with putUserProperty("PROMPT", "user did put a prompt here");

Of course, the does not mean that we would enforce using an enum as a
key, key would remain Object, and users can still use Strings, or their
own enums if they want, or anything fits their needs.

> 
> SHORT_PROMPT should default to PROMPT, so there is some logic. But how
> does one default DisplayLength from max length? And know whether you
> have a default value or a set value?
> 
I think we should keep it simple, ie known properties with shortcut
getters/setters.
Logic should belong to the UI layer (think also about I18N, maybe
getting translations or per-user customizations from a database, etc.)

> Long ago I had a complex properties system that Franck (fortunately)
> deleted. 
> 
> I'm inclined to leave UserProperty for miscellaneous, and methods for
> known properties.

If we are sure that keys won't enter in conflict (we are), I think using
userProperties even for known "standard" properties is cleaner.

> Certainly use String as parameter to UserProperty.

As I explained, I would stick with Object as a key.

> 
> To unify them, could have UserProperty $PROMPT (say) just call
> getPrompt(). Could include max size, default display length etc. Not
> sure if that is useful. Do you ever really want to enumerate all the
> properties? 
> 
Only predefined ones.


So, what I propose is :

1) keep keys in userProperties as Object
2) use a dedicated enum to give the keys of known standard properties,
and avoid any collision with custom user properties.
3) create shortcut method that put/get from the userPropertie map
4) begin with two standard properties : PROMPT and TOOLTIP and
setPrompt, setTooltip methods.

Does this sound ok ?

Franck






------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/SimpleORM/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/SimpleORM/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/