Hi Neal,
I found a problem with your customFormatter extension.
Following situation:
You have a text inputfield wich you send through your formatterInterface to
change it to xx-xx-xx.
If you get back the response the string will be stored as xx-xx-xx into the
database.
Now you send it again through the formatter interface and the formating will
happen again.
So i think we need something to format and deformat the value again.
OK, let's see what we have for formatting values:
1. You can define a pattern which will be used to format numeric or date
values.
2. You can define a special formatter class which will be used to format
numeric or date values
Only the pattern generated by this class is send to the page and used
for parsing the value back.
We should deprecate this and remove it in version 2.6
3. We have your new customFormatter defined as a session bean to
unidirectional format values.
You also use - according to my suggestion - the formatter interface
and passes the fieldValue,
the field and tag into the object array used by the Formatter.
Why do you need the the field and the tag inside the formatting? Is it
really neccesary?
4. At least each value is escaped/unescaped by an special escaper. This
works for escaper defined in
the config file in the moment.
To use them for tag too we must transport the escaper classname
through an request/response cycle
To format comboboxes some other rules are working:
1. Transforming of the value list to the output text is done by a special
class which works
like the good old c function sprintf(formatString, value1, value2,
...)
The format is defined by the attribute format
2. To customize this behaviour you can define your own formatter class
which must implement the formatter
interface which is only an abstraction of the PrintfFormat class.
Conclusion:
The customFormatter interface do not fit the needs of the customFormatter
- Sorry.
The formatter class of the BaseHandler is'nt need any longer - let's
deprecate it.
The escaping/unescaping should only work on field/table/default base -
not on tag base. Because escaping for tags is
only rudimentaer i will remove it.
We should define a customFormatter interface like this:
interface
string format(Field f, string s);
string parse (Field f, string s);
The classname of the customFormatter should be an attribute of the field
so that we can transport it over the request/response
cycle and can call the parse function during parsing
If your really need the tag and the field during format we need some
setters too.
Pay attention: On the response we do not have the tag - so we can not use
it. So i would suggest not to use it.
Every information you is in the field - not in the tag.
OK, lets discuss this stuff!
What do you think?
Cheers,
Henner
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
DbForms Mailing List
http://www.wap-force.net/dbforms
