Entity fields customizing

[Dmitry]

I have several questions about entity presentation customization:

1. How to define field caption? By default it is constructed from field
name, I want to provide my own caption.
2. How to define the size (length) of the field control on the form?
3. How to define field size? Or, more generally, is it possible to
define field restrictions?

According to your answers on my previous post, such customization
should be concentrated in the entity class but I didn't found the way
to achieve this.

Thank you
//Dmitry

[Eitan Suez]

On 7/14/06, Dmitry <dmitry.o...@gmail.com> wrote:

1. How to define field caption? By default it is constructed from field
name, I want to provide my own caption.

At present, field captions are derived directly from the field's
getter method.  The algorithm translates camel casing to
introduce spaces between words.  example:
  getSomeProperty
would produce the caption "Some Property"
  getMyHBM_Account()
would produce the caption "My HBM Account" (the underscore
  is used as a delimiter for separating the last capital letter in an
  acronym from the next word.

currently there is no other way to do this.  i've never really had
the need for it.. however, it should be easy to add.  have a look
at the annotation "FieldAt" which allows you to specify a mnemonic
for a field.  for an example of how it's used, look at the class
'com.u2d.type.composite.Name ' where the first name is marked
with the mnemonic 'f'.  it's pretty easy to define another
property on the annotation named 'caption' and to use the
specified value in the application.

i will add that to the bug list.
 

2. How to define the size (length) of the field control on the form?

currently there is no support for this.  for large blocks of text,
use a TextEO, which implies a different type for persistence
and a textarea for the ui.  and StringEO for varchar's, which
as you know, default to 255 for persistence, and

3. How to define field size? Or, more generally, is it possible to
define field restrictions?

when i started with jmatter, i used to hand-code hibernate mapping
files.  that was in the old days, before the fancy ejb3 jpa annotations.
that got old, so i built an HBMMaker that generated the files for me.
that made things _much_ easier.  i can now deal with fairly complex
objects and interrelationships and have hbmmaker produce xml
files that i never look at anymore (heaven).  every now and then,
i'd come across a modeling situation that hbmmaker did not handle
and so i'd add support for it.  so the jmatter hbmmaker basically
provides access to a subset of the flexibility provided by hibernate. 
i think there's value there.  technically, if i were to provide all the
flexibility that hibernate mapping files provide, then there'd be no
point for hbmmaker.

the truth is that now with annotations and jpa, using hibernate in the
raw is getting easier and easier and the point for an hbmmaker might
go away.  hibernate's wiki posts a number of alternative usertypes
to support java 5 enumerations.  with annotations, enum support
is now built-in.  for a long time jmatter remained
java 1.4 compatible on purpose.  i crossed that line however
recently and started by using annotations to mark commands.
so i'm in the process of transitioning many of the other metadata
specifications as annotations.  enum support will likely come along
as part of that process.

but to answer your question, i suppose there are a number of
options:
  [a] add support for column length to hbmmaker
  [b] use hbmmaker to generate an initial hbm.xml file and then
    turn it off in the build file, and hand-edit the hbm.xml file.
 

give me examples of field restrictions.  there is support for marking
a property unique, read-only, for specifiying whether a field is required,
for validating a field, and for specifying a default value for a field.

thanks, eitan

[vput...@gmail.com]

Hi Eitan,
Is there a Java 1.4 verison of JMatter that I can have access to ?
If so will most if not all of the demo work on it?
Thanks,
Vamsi

[Eitan Suez]

hi vamsi,

  see my reply to this very question in the other thread
  you just posted to.  the answer is, yes:  before starting
  to use annotations, i used method naming conventions
  to mark commands.

  for example:
  public void commandSayHello(CommandInfo cmdInfo) {}

  would replace the newer:
  @CommandAt
  public void SayHello(CommandInfo cmdInfo) {}

  so if you write your apps according to the older
  convention, you could get jmatter to work with
  jdk1.4.  the main thing you need to do is revise
  a couple of lines in ComplexType:  which reflector()
  you want to use.  with a little refactoring, this could
  be pulled out of ComplexType and into, say,
  app-config.xml

  if you do this, i'll gladly integrate your patch.

thanks, eitan