Re: Adding setComment on SFieldMeta

>> 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");

Hmm, I think you just made a good argument for not using the Enum!

Maybe an Enum.toString().  Maybe the Map should be <String, Object>?  Or maybe a Property List?

I suppose that different aps could use different enums, but the potential for confusion is high.

>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 ?

I think use the userProperties if you prefer, although there is a bit of a clash with the use of fields elsewhere.  But as you say, things like defaults can be dealt with in UI layer.

I think having different enums plus strings as keys is very odd and potentially very nasty.  Use "$PROMPT" or "SORM:PROMPT" if you are concerned about namespaces.    

I think that I would like userProperties key changed to String now that you bring it up.

By all means introduce an enum of Common properties.  It will help if different aps use Simpleorm.   But mark it as just a list of strings.

Having getters and setters for userProperties is a bit odd.  If they are standard, why not make them simple fields?  But could be handy.  Maybe get(enum) and set(enum)?

(It could later go the other way -- expose simpleOrm fields through the property interface as special cases.  Not actually stored as properties, just overload get() to look up the field value.)

isDescriptive() is definitely something that should be treated like PROMPT.  The idea was that for simple list and crud forms you could default the List fields directly.  One could then build a generic app that worked directly off the meta data.

It would be good to make a list of common properties.  Display size could be one.  URL for help?  Don't go crazy, just the ones you might actually use.  Maybe there will be too many for simple fields.

We do need to get JavaDB or possibly Daffodil up and running.  I prefer the latter, but the former has become standardized.

Anthony


>Franck
>
>


Spreadsheet Detective,
Southern Cross Software Queensland Pty Limited
54 Gerler Street
Bardon, Queensland 4065, Australia.

Email: [email protected]
www.SpreadsheetDetective.com
Ph: +61 427 830248 (Australian Eastern Standard Time)

"If the model seems correct only because the numbers look right, 
then why build the model in the first place?"


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

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/