You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by James Strachan <ja...@yahoo.co.uk> on 2002/01/02 18:29:47 UTC
[DynaBean] a couple of other existing projects...
Here's a couple of other projects I've stumbled on which might help design
discussions on DynaBeans. They tackle similar things; if nothing else it
might be useful to describe what DynaBeans isn't as both of these projects
have different aims.
I stumbled across the niggle project recently (thanks to Geir's JavaWorld
article). If you look in the Javadoc here
http://www.niggle.org/api/index.html
at the Record interface in org.oreodata here
http://www.niggle.org/api/org/oreodata/package-summary.html
it looks very similar to the current DynaBean proposal though it adds
support for primary keys and immutable records. It also has a
RecordDescriptor, which is like the DynaClass.
It also has is a FieldDescriptor which allows specialised Fields to be
implemented and which encapsulates the knowledge of how to convert to and
from strings and JDBC types, how to normalize values and perform validation
etc.
e.g. here's some default implementations of DateField, TimeZoneField,
EmailField etc.
http://www.niggle.org/api/org/oreodata/metadata/package-summary.html
This 'Record has Fields' kind of model is similar to the Barracuda model,
which uses the class 'Form' rather than Record.
http://barracuda.enhydra.org/cvs_source/Barracuda/docs/forms/forms_brief.gif
http://barracuda.enhydra.org/cvs_source/Barracuda/docs/forms/high_level_over
view.html
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [DynaBean] a couple of other existing projects...
Posted by Paulo Gaspar <pa...@krankikom.de>.
Answer inline:
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Thursday, January 03, 2002 2:49 PM
>
> James Strachan wrote:
> > For things like type converters that turn Strings to and from other data
> > types such as Number and Date, I was thinking these converters should be
> > moved to a Controller as they can be environment or framework dependent.
> > e.g. validation might result in a localized message being produced to be
> > displayed in a UI. Or arbitrary formatting rules could be
> applied to display
> > property values.
> >
> > So I was musing about the idea of having a BeanController facade to a
> > DynaBean (or regular JavaBean) that used Strings and was responsible for
> > doing the type conversions and validation messages, having Locale,
> > ResourceBundles and whatnot, seemed better than forcing a DynaClass to
> > understand these i18n issues.
>
> David Winterfeldt's validator (already accepted as a Commons product)
> uses an XML configuration file to store these kind of properties for a
> field.
>
> http://home.earthlink.net/~dwinterfeldt/
Interesting stuff!
=:o)
> This can then be used in collaboration with a controller to perform a
> primia facia validation, and generate localized messages and what not.
>
> This would be the sort of thing that could also be stored with a column
> helper inside the DynaBean. The controller could then run down the
> objects stored in the DynaBean and trigger the validations/conversions,
> rerouting control if one or more fail.
>
> Of course, the DynaBean would not need to be aware of any of this, it is
> just encapsulating the column helpers. The controller could be calling
> the triggers on DynaBean members (which it would know are all column
> helper objects).
>
> I'm thinking we could merge what David's validator does with a column
> helper that also supported a data-entry buffer, and define everything
> about a column in one place. You know, like Access or FileMakerPro ;-)
What I am trying to find out is an as-light-as-possible implementation of
a DynaBean that allows to do all this stuff.
Since this is stuff that depends on a context (what is the Locale of the
user, i18n, current form, etc.) it should be in an external Controller as
James suggested or in the DynaBean as I like (for simple enough stuff).
The DynaClass is one for the whole app. Any properties and rules you set
there are application wide. If you set a DynaClass for a "form bean"
DynaBean, it will probably only be useful for that form - and this could
be very appropriate anyway.
If you have column helpers per DynaClass (as I have for some wrappers)
they are application wide too.
OTOH, If you have column helpers per DynaBean, the DynaBean might become
an heavy object - at least an additional object per property per bean.
Lets evolve a bit the per-property-converter of my previous post and call
it an input filter:
public interface InputFilter
{
Object filter(int propIndex, Class destType, Object newValue);
}
If you have an (optionally doing nothing) InputFilter per DynaBean with
its filter method called to process each value being assigned to a
property you can do a lot with it in terms of per field type conversion
and validation (or you can do nothing).
You can implement an InputFilter to apply generic type conversion rule,
per-property type conversion rules, same thing for validation.
And you can swap InputFilter at each stage of a processing pipeline
depending on the needs of that stage.
You can make it very light:
public class NoOpInputFilter implements InputFilter
{
public final Object filter(int propIndex, Class destType, Object
newValue)
{ return newValue;
}
}
Or you can make it as complex as you describe.
For global bean validation you can implement an extended interface:
public interface PostValidatingInputFilter extends InputFilter
{
void validate(DynaBean updatedBean);
}
Then helper methods or controllers can do things like:
public class DataPumpHelper
{
//...
public static void copyByName(Map source, DynaBean dest)
{
final String[] propNames = dest.propNames();
for(int i = 0; i < propNames.length; ++i)
{ String pName = propNames[i];
if (source.containsKey(pName))
{
dest.set(pName, source.get(pName));
}
else
{
dest.set(pName, null);
}
}
InputFilter inpFilter = dest.inputFilter();
if (inpFilter instanceof PostValidatingInputFilter)
{
((PostValidatingInputFilter)inpFilter).validate();
}
}
//...
}
Of course that both the InputFilter.filter() and the
PostValidatingInputFilter.validate() methods should throw exceptions when
something is wrong/invalid. I am just not very sure if they should be
RuntimeException's but that is what I am doing for data conversion.
The above DataPumpHelper.copyByName() could collect those exceptions to
provide complete information on all that goes wrong.
> The nice part about doing this with a DynaBean, is that we get what
> appears to be a standard JavaBean, but is actually being assembled from
> component objects.
YEEEEEeeeeeeeeeessssssssss!!!!
=:o)
> Again, this would not be in the DynaBean package per se, but another
> package using the DynaBean as a proof of concept.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Building Java web applications with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
Keep the ideas flowing and ave fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [DynaBean] a couple of other existing projects...
Posted by Ted Husted <hu...@apache.org>.
James Strachan wrote:
> For things like type converters that turn Strings to and from other data
> types such as Number and Date, I was thinking these converters should be
> moved to a Controller as they can be environment or framework dependent.
> e.g. validation might result in a localized message being produced to be
> displayed in a UI. Or arbitrary formatting rules could be applied to display
> property values.
>
> So I was musing about the idea of having a BeanController facade to a
> DynaBean (or regular JavaBean) that used Strings and was responsible for
> doing the type conversions and validation messages, having Locale,
> ResourceBundles and whatnot, seemed better than forcing a DynaClass to
> understand these i18n issues.
David Winterfeldt's validator (already accepted as a Commons product)
uses an XML configuration file to store these kind of properties for a
field.
http://home.earthlink.net/~dwinterfeldt/
This can then be used in collaboration with a controller to perform a
primia facia validation, and generate localized messages and what not.
This would be the sort of thing that could also be stored with a column
helper inside the DynaBean. The controller could then run down the
objects stored in the DynaBean and trigger the validations/conversions,
rerouting control if one or more fail.
Of course, the DynaBean would not need to be aware of any of this, it is
just encapsulating the column helpers. The controller could be calling
the triggers on DynaBean members (which it would know are all column
helper objects).
I'm thinking we could merge what David's validator does with a column
helper that also supported a data-entry buffer, and define everything
about a column in one place. You know, like Access or FileMakerPro ;-)
The nice part about doing this with a DynaBean, is that we get what
appears to be a standard JavaBean, but is actually being assembled from
component objects.
Again, this would not be in the DynaBean package per se, but another
package using the DynaBean as a proof of concept.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [DynaBean] a couple of other existing projects...
Posted by Paulo Gaspar <pa...@krankikom.de>.
Here we go again,
=:o)
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Thursday, January 03, 2002 7:20 PM
> To: Jakarta Commons Developers List
> Subject: Re: [DynaBean] a couple of other existing projects...
>
>
> Paulo Gaspar wrote:
>
> ...
>
> The objects in this package may also have their own converters, but that
> would not affect the design of the base DynaBeans.
Cool! This way my little obsession is not being attacked yet.
=;o)
> Paulo Gaspar wrote:
> > For many things I never go trough the String step. Some things I do when
> > converting:
> > - I always convert any Number descendent to another Number type using
> > the methods in the Number interface (yes, I validate overflows);
> > - I convert JDBC date/time types into java.util.Date... and I already
> > miss converting also to other types;
> > - I do not duplicate immutable objects if the source column type is the
> > same as the destination type.
> >
> > I will try to post my Converter here in a couple of days. It is really
> > simple.
>
> Where the getXxxBuffer comes into play is with data validation and
> CORRECTION. The idea is that you need to buffer whatever they input, so
> you can return it to them for correction (without relying on the browser
> back button).
Aaaaaaaaahhhhhhh!!!!!
Understood!
But you can use something like a simple Map as a buffer and a "normal"
(whatever that means) DynaBean for the rest. The buffer does not need type
information and other DynaBean stuff, it just needs to be a map of names
to values.
(This means I still did not "get it" all.)
> The getXxxString accessor may be just a standard converter for the type,
> or may return a formatted version. For example a telphone number may be
> stored as all digits in the database, but punctuated on the page. So if
> I want the raw version, I can ask for getXxx when I want the formatted
> version, I ask for getXxxString. In some case, they may both return
> Strings, but one might be formatted.
What is the "Xxx" here?
(The property name is an argument on DynaBean accessors, so I am excluding
that one.)
> James Strachan wrote:
> > Agreed. Maybe a DynaClass could be constructed from a list/array of
> > DynaProperty objects, then we could have a library of derived
> DynaProperty
> > classes for standard properties, default values, range contraints etc.
> >
> > e.g.
> >
> > String[] sexes = [ "m", "f" ];
> > DynaProperty[] properties = {
> > new StringProperty( "name" ),
> > new PercentProperty( "score" ),
> > new DateProperty( "birthday" ),
> > new ChoiceProperty( "sex", sexes )
> > new DynaProperty( "foo", Foo.class )
> > };
> > DynaClass personClass = new DynaClass( "Person", properties );
> > DynaBean person = personClass.newInstance();
>
> That's the general idea, though these do not have to be Dyna anythings.
> I'm thinking of a conventional base object to represent a column, with
> subclasses to represent the different types. The object would have
> properties representing the column name, label, type, range, validation,
> converter, state, and so forth.
>
> In a real application, we are already creating all this someplace, it's
> just getting spread around.
>
> This package does not even need to be DynaBean-aware, and I'm sure
> people have done similar things in the past. But, if we insert something
> like this into the DynaBean at initialization, they get exposed as
> ordinary JavaBean properties, rather than as some custom class.
I am inclined to use DynaBeans a lot for this kind of thing although with
a more Access-like meatadata/functionality (now I understand what you
meant).
I am starting with something like that. It is my 2nd attempt on the web
and my n-th overall. It did not help that I was trying too many new things
in the previous attempt.
(In many respects the Web is too different from (lets say) a 2 tier
Windows application... although probably similar to a 3+ tier one. I am
very interested on this stuff.)
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Building Java web applications with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
Have fun,
Paulo Gaspar
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [DynaBean] a couple of other existing projects...
Posted by Ted Husted <hu...@apache.org>.
Paulo Gaspar wrote:
> All this blah blah means that I think your ideas are very nice and valid
> but they do not invalidate or are opposed by my Converter-per-DynaBean
> obsession.
> =;o)
Agreed.
Nothing I'm talking about affects the DynaBean implementation. I'm
thinking of a package that would put the DynaBean to good use.
The objects in this package may also have their own converters, but that
would not affect the design of the base DynaBeans.
Paulo Gaspar wrote:
> For many things I never go trough the String step. Some things I do when
> converting:
> - I always convert any Number descendent to another Number type using
> the methods in the Number interface (yes, I validate overflows);
> - I convert JDBC date/time types into java.util.Date... and I already
> miss converting also to other types;
> - I do not duplicate immutable objects if the source column type is the
> same as the destination type.
>
> I will try to post my Converter here in a couple of days. It is really
> simple.
Where the getXxxBuffer comes into play is with data validation and
CORRECTION. The idea is that you need to buffer whatever they input, so
you can return it to them for correction (without relying on the browser
back button).
The getXxxString accessor may be just a standard converter for the type,
or may return a formatted version. For example a telphone number may be
stored as all digits in the database, but punctuated on the page. So if
I want the raw version, I can ask for getXxx when I want the formatted
version, I ask for getXxxString. In some case, they may both return
Strings, but one might be formatted.
James Strachan wrote:
> Agreed. Maybe a DynaClass could be constructed from a list/array of
> DynaProperty objects, then we could have a library of derived DynaProperty
> classes for standard properties, default values, range contraints etc.
>
> e.g.
>
> String[] sexes = [ "m", "f" ];
> DynaProperty[] properties = {
> new StringProperty( "name" ),
> new PercentProperty( "score" ),
> new DateProperty( "birthday" ),
> new ChoiceProperty( "sex", sexes )
> new DynaProperty( "foo", Foo.class )
> };
> DynaClass personClass = new DynaClass( "Person", properties );
> DynaBean person = personClass.newInstance();
That's the general idea, though these do not have to be Dyna anythings.
I'm thinking of a conventional base object to represent a column, with
subclasses to represent the different types. The object would have
properties representing the column name, label, type, range, validation,
converter, state, and so forth.
In a real application, we are already creating all this someplace, it's
just getting spread around.
This package does not even need to be DynaBean-aware, and I'm sure
people have done similar things in the past. But, if we insert something
like this into the DynaBean at initialization, they get exposed as
ordinary JavaBean properties, rather than as some custom class.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [DynaBean] a couple of other existing projects...
Posted by Paulo Gaspar <pa...@krankikom.de>.
Answer inline:
> -----Original Message-----
> From: James Strachan [mailto:james_strachan@yahoo.co.uk]
> Sent: Thursday, January 03, 2002 2:27 PM
>
> From: "Paulo Gaspar" <pa...@krankikom.de>
> >
> > ...
> >
> > I am just defending that even in such specific case it is not a
> > very good idea to extend the DynaBean.
>
> Agreed. Things like number or date range constraints or String
> patterns and
> other such validations sound like ideal metatdata to add to
> DynaClass. i.e.
> i18n and user context independent constraints. So maybe a DynaClass has a
> number of DynaProperties that can be extended to have validation
> rules etc.
>
> For things like type converters that turn Strings to and from other data
> types such as Number and Date, I was thinking these converters should be
> moved to a Controller as they can be environment or framework dependent.
> e.g. validation might result in a localized message being produced to be
> displayed in a UI. Or arbitrary formatting rules could be applied
> to display
> property values.
>
> So I was musing about the idea of having a BeanController facade to a
> DynaBean (or regular JavaBean) that used Strings and was responsible for
> doing the type conversions and validation messages, having Locale,
> ResourceBundles and whatnot, seemed better than forcing a DynaClass to
> understand these i18n issues.
>
> Another way around this could be to pass in some Context object
> which has-a
> Locale, Timezone, maybe a ResourceBundle and the DynaBean and having
> getString() / setString() methods that take a Context. Though this seems a
> bit clumsy, seperating this stuff out seems cleaner.
You can do a LOT with a simple Converter that is field aware. Thins means
that instead of the interface:
public interface Converter
{
Object convert(Class toType, Object newVal);
}
we could have
public interface DynaBeanConverter
{
Object convertProperty(Class toType, String propName, Object newVal);
}
Or we can have a mega controller that changes the DynaBean Converter when
needed (if the column to be set follows "exceptional" rules) or that just
uses an "external" Converter. That would probably have some method like:
public class BigAndMeanBeanController
{
public void copyData(Map source, DynaBean dest)
{
// any weird stuff here
}
}
In this case you do might not miss the DynaBean having a converter
(although it might still help implementing it) but it also does not get
on your way.
The reason I keep insisting on a Converter attached to the basic DynaBean
implementation is that it eases a lot many simpler use cases:
- Most of the times you use a DynaBean you will have to perform data
conversion in a way that a Converter implementation can help a lot;
- The few times you do not need conversion, you can skip it (I use a
NoOpConverter to avoid "if (null == m_converter)" everywhere);
- For more complex uses like you propose, the Converter-per-DynaBean can
still help on its implementation and at least does not get on the way.
All this blah blah means that I think your ideas are very nice and valid
but they do not invalidate or are opposed by my Converter-per-DynaBean
obsession.
=;o)
> > > Since converters would have all kinds of optional contexts associated
> with
> > > them like Locale, Timezone and other stuff like maybe the user id or
> > > HttpSession, keeping such a controller seperate to the DynaClass, like
> the
> > > BeanController idea I suggested, would seem cleaner.
> > >
> > > e.g. a single 'customer' DynaBean instance could have a
> single DynaClass
> > > instance (which could be shared by other customer DynaBeans) but could
> be
> > > viewed using various different locales & timezones & users.
> So having a
> > > seperate 'controller' object for each context would seem to
> make sense,
> > > which just has-a reference to the DynaBean.
> >
> > Sure.
> >
> > But I still defended the option we previously discussed of having a
> > converter
> > attached to the DynaBean object (not the DynaClass) since it
> can make most
> > of
> > its uses simpler (e.g.: set the bean with a converter for the
> right Locale
> > and
> > just assign values to its fields).
>
> I think a simple facade might be cleaner, that takes care of the i18n and
> type conversion issues. i.e. a seperation of concerns. The
> DynaClass/DynaBean takes care of the typesafe properties and validation
> rules, the BeanController (or BeanConverter) takes care of the type
> conversion & i18n & validation messages issues. Though maybe adding an
> optional Formatter to the DynaProperty/DynaClass might help keep the
> metadata together, then just have a single helper class
> BeanController/Converter/View to do the i18 specific stuff.
>
> Still thinking aloud though.
Me too (thinking aloud).
I only defend the Converter-per-DynaBean (here I go again) at the
"standard" DynaBean implementation level because it would help on a very
common use pattern (wanting to get data from somewhere into the bean
following some simple type conversion rules).
The DynaClass extended metadata looks great for the case where you want
to define something like a form bean. Maybe implementing a DynaClass
descendant is a simple and convenient way to store such extended metadata
information. Maybe there are other ways.
I am still thinking how I am going to do this one too.
My experience with the Converter-per-DynaBean is some and very positive
but I still did nothing like you are talking about - although it is now
in my horizon.
> > > > Craig, I and others discussed several ideas that have a lot
> to do with
> > > > this stuff during the last couple of weeks.
> > >
> > > Just out of interest was this on a struts list or just privately?
> >
> > Just here in the commons-dev list. I do not use Struts.
>
> Ah in that case I read them; it was those ideas I was responding to. I was
> just checking there wasn't another discussion thread going on some place
> else.
>
> James
I will try to keep it here as much as I can.
=:o)
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [DynaBean] a couple of other existing projects...
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Paulo Gaspar" <pa...@krankikom.de>
> > > The DynaClass (metadata) part should be the only one having to be
> > > extended to avoid a complex DynaBean class structure. Then you can
have
> > > helper classes that use the extended metadata information to the tasks
> > > you talk about (formatting, validation, etc.).
> > >
> > > Trying to include these and other concerns in some DynaBean
> > descendent(s)
> > > will produce a monster hard to manage class(es). Separating
> > such concerns
> > > in separated helper classes with the help of extended metadata will
have
> > > the advantages of:
> > > - Simpler code;
> > > - Easier learning of its use (the user does not have to learn
> > what he is
> > > not using).
> >
> > I agree DynaBean isn't the right place for this, but I don't
> > think DynaClass
> > is either - I think a seperate 'controller' is better. Think MVC and
that
> > the DynaBean/Class as the 'model' and a controller mediates between a
view
> > (HTTP request/form or Swing controls).
>
> I was talking about extending DynaClass for extended metadata information.
>
> Sometimes you have a bean you use in a very restricted scope - like a data
> entry form - and it might be much simpler to define all its metadata in a
> single place, including things like validation and conversion rules.
>
> For such use it makes sense to have a specialized DynaClass and some
> helpers,
> but I am NOT defending this should be included in the "standard"
DynaClass.
>
> I am just defending that even in such specific case it is not a very good
> idea to extend the DynaBean.
Agreed. Things like number or date range constraints or String patterns and
other such validations sound like ideal metatdata to add to DynaClass. i.e.
i18n and user context independent constraints. So maybe a DynaClass has a
number of DynaProperties that can be extended to have validation rules etc.
For things like type converters that turn Strings to and from other data
types such as Number and Date, I was thinking these converters should be
moved to a Controller as they can be environment or framework dependent.
e.g. validation might result in a localized message being produced to be
displayed in a UI. Or arbitrary formatting rules could be applied to display
property values.
So I was musing about the idea of having a BeanController facade to a
DynaBean (or regular JavaBean) that used Strings and was responsible for
doing the type conversions and validation messages, having Locale,
ResourceBundles and whatnot, seemed better than forcing a DynaClass to
understand these i18n issues.
Another way around this could be to pass in some Context object which has-a
Locale, Timezone, maybe a ResourceBundle and the DynaBean and having
getString() / setString() methods that take a Context. Though this seems a
bit clumsy, seperating this stuff out seems cleaner.
> > Since converters would have all kinds of optional contexts associated
with
> > them like Locale, Timezone and other stuff like maybe the user id or
> > HttpSession, keeping such a controller seperate to the DynaClass, like
the
> > BeanController idea I suggested, would seem cleaner.
> >
> > e.g. a single 'customer' DynaBean instance could have a single DynaClass
> > instance (which could be shared by other customer DynaBeans) but could
be
> > viewed using various different locales & timezones & users. So having a
> > seperate 'controller' object for each context would seem to make sense,
> > which just has-a reference to the DynaBean.
>
> Sure.
>
> But I still defended the option we previously discussed of having a
> converter
> attached to the DynaBean object (not the DynaClass) since it can make most
> of
> its uses simpler (e.g.: set the bean with a converter for the right Locale
> and
> just assign values to its fields).
I think a simple facade might be cleaner, that takes care of the i18n and
type conversion issues. i.e. a seperation of concerns. The
DynaClass/DynaBean takes care of the typesafe properties and validation
rules, the BeanController (or BeanConverter) takes care of the type
conversion & i18n & validation messages issues. Though maybe adding an
optional Formatter to the DynaProperty/DynaClass might help keep the
metadata together, then just have a single helper class
BeanController/Converter/View to do the i18 specific stuff.
Still thinking aloud though.
> > > Craig, I and others discussed several ideas that have a lot to do with
> > > this stuff during the last couple of weeks.
> >
> > Just out of interest was this on a struts list or just privately?
>
> Just here in the commons-dev list. I do not use Struts.
Ah in that case I read them; it was those ideas I was responding to. I was
just checking there wasn't another discussion thread going on some place
else.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [DynaBean] a couple of other existing projects...
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Ted Husted" <hu...@apache.org>
> Paulo Gaspar wrote:
> > For such use it makes sense to have a specialized DynaClass and some
> > helpers,
>
> Agreed. I'm just thinking that the first thing I will do with a DynaBean
> is define a number of standard field or column helpers, that would
> correlate to the columns or fields in a database.
>
> Since this will be a common idea, we might want to consider a companion
> package to the DynaBean that defined these helpers. This could save us,
> and dozens of others, from each implementing our own, all with the same
> goals.
Agreed. Maybe a DynaClass could be constructed from a list/array of
DynaProperty objects, then we could have a library of derived DynaProperty
classes for standard properties, default values, range contraints etc.
e.g.
String[] sexes = [ "m", "f" ];
DynaProperty[] properties = {
new StringProperty( "name" ),
new PercentProperty( "score" ),
new DateProperty( "birthday" ),
new ChoiceProperty( "sex", sexes )
new DynaProperty( "foo", Foo.class )
};
DynaClass personClass = new DynaClass( "Person", properties );
DynaBean person = personClass.newInstance();
> There are are finite number of column types supported by the JDBC, so
> I'm thinking there could be a toolkit for generating these and rolling
> them into a DynaBean.
>
> Since any value can be represented as a String, such a helper might
> include a String buffer along with its native object, and could be very
> useful in ferrying input from the Web tier (which is String based) to
> the Business tier (which often needs native values). So each column
> helper would have a getXXX form and a getXXXString form. There may also
> be a setXXXBuffer form to enter data for later validation, and then a
> trigger for the valiation/conversion routine.
I'm thinking we should maybe have a seperate converters to/from JDBC,
to/from XML (e.g. XML Schema Data Types) and to/from Strings (web tier or
Swing controls).
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [DynaBean] a couple of other existing projects...
Posted by Paulo Gaspar <pa...@krankikom.de>.
Answer inline:
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Thursday, January 03, 2002 2:21 PM
>
>
> Paulo Gaspar wrote:
> > For such use it makes sense to have a specialized DynaClass and some
> > helpers,
>
> Agreed. I'm just thinking that the first thing I will do with a DynaBean
> is define a number of standard field or column helpers, that would
> correlate to the columns or fields in a database.
In my implementation (the IRecord thing I talk about all the time) I am
wrapping ResultSets with a very simple DynaBean which DynaClass is built
from a ResultSetMetaData. This object just works as a buffer zone that
ensures reading columns in the right order (which is necessary with some
JDBC implementations) while doing some data conversion (lets say I am
converting CLOBs to strings while also reading nested ResultSets into
memory).
Then I read the above wrapped data into my "standard" DynaBean using a
Converter.
> Since this will be a common idea, we might want to consider a companion
> package to the DynaBean that defined these helpers. This could save us,
> and dozens of others, from each implementing our own, all with the same
> goals.
>
> There are are finite number of column types supported by the JDBC, so
> I'm thinking there could be a toolkit for generating these and rolling
> them into a DynaBean.
Actually, I only give a special treatment to long types (BLOB, CLOB and
so on) and nested ResultSets. All the rest I just read with getObject().
At the moment the buffering DynaBean ResultSet wrapper just says that all
columns are Objects although it uses special readers for the mentioned
special cases.
If I want to put data from a ResultSet in a Velocity template in a quick
and dirty way I just:
- Create a DynaClass with the same number of properties and the same
names as the ResultSet wrapper, all these fields having Object as
their type;
- Read the ResultSet into a List by repeating this steps:
- Moving the ResultSet to the next row;
- Using the above DynaClass to create a new "standard" DynaBean;
- Read the data from the ResultSet wrapper into this bean;
- Put the bean in the list.
- And I put the above list in the template context.
(Actually, this is the version I use to cache data. There is another
version where I put an Iterator that makes something similar without the
list, which is great for huge XML exports.)
If I want to do something fancy, I have a separate and more detailed
DynaClass definition that follows my business logic needs and not so
much the exact database types. Then, to read the data I just follow a
method similar to the above quick and dirty case but using this
DynaClass and setting the destination DynaBean to use an appropriate
converter to turn the JDBC column objects into the appropriate types.
> Since any value can be represented as a String, such a helper might
> include a String buffer along with its native object, and could be very
> useful in ferrying input from the Web tier (which is String based) to
> the Business tier (which often needs native values). So each column
> helper would have a getXXX form and a getXXXString form. There may also
> be a setXXXBuffer form to enter data for later validation, and then a
> trigger for the valiation/conversion routine.
For many things I never go trough the String step. Some things I do when
converting:
- I always convert any Number descendent to another Number type using
the methods in the Number interface (yes, I validate overflows);
- I convert JDBC date/time types into java.util.Date... and I already
miss converting also to other types;
- I do not duplicate immutable objects if the source column type is the
same as the destination type.
I will try to post my Converter here in a couple of days. It is really
simple.
> Elsewhere in this thread, I believe it's been suggested that an
> application might actually end up with two DynaBean definations, one
> String, one native. This often happens in Struts applications today. I'm
> just thinking that the leverage a DynaBean give us, makes a standard
> column helper package is an attractive idea.
You can also have helper methods to convert a Map of Strings into a
DynaBean using a given Converter. Just to illustrate and without using the
correct method names that were proposed by Craig, such method would be
something like:
public class DataPumpHelper
{
//...
public static void copyByName(Map source, DynaBean dest)
{
final String[] propNames = dest.propNames();
for(int i = 0; i < propNames.length; ++i)
{ String pName = propNames[i];
if (source.containsKey(pName))
{
dest.set(pName, source.get(pName));
}
else
{
dest.set(pName, null);
}
}
}
//...
}
> In practice, there would probably be domain-level validators/converters
> in the column helpers, and a model-level validator/convereter in the
> DynaBean itself. The idea being, for example, that first I make sure the
> datum could be a username or password (not too short, et cetera), and
> then I check to see if it actually registered as such.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Building Java web applications with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [DynaBean] a couple of other existing projects...
Posted by Ted Husted <hu...@apache.org>.
Paulo Gaspar wrote:
> For such use it makes sense to have a specialized DynaClass and some
> helpers,
Agreed. I'm just thinking that the first thing I will do with a DynaBean
is define a number of standard field or column helpers, that would
correlate to the columns or fields in a database.
Since this will be a common idea, we might want to consider a companion
package to the DynaBean that defined these helpers. This could save us,
and dozens of others, from each implementing our own, all with the same
goals.
There are are finite number of column types supported by the JDBC, so
I'm thinking there could be a toolkit for generating these and rolling
them into a DynaBean.
Since any value can be represented as a String, such a helper might
include a String buffer along with its native object, and could be very
useful in ferrying input from the Web tier (which is String based) to
the Business tier (which often needs native values). So each column
helper would have a getXXX form and a getXXXString form. There may also
be a setXXXBuffer form to enter data for later validation, and then a
trigger for the valiation/conversion routine.
Elsewhere in this thread, I believe it's been suggested that an
application might actually end up with two DynaBean definations, one
String, one native. This often happens in Struts applications today. I'm
just thinking that the leverage a DynaBean give us, makes a standard
column helper package is an attractive idea.
In practice, there would probably be domain-level validators/converters
in the column helpers, and a model-level validator/convereter in the
DynaBean itself. The idea being, for example, that first I make sure the
datum could be a username or password (not too short, et cetera), and
then I check to see if it actually registered as such.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [DynaBean] a couple of other existing projects...
Posted by Paulo Gaspar <pa...@krankikom.de>.
Answer inline:
> ----- Original Message -----
> From: "Paulo Gaspar" <pa...@krankikom.de>
> > Extending the DynaClass and using Converters would do most of what you
> > describe here.
>
> I'm arguing for not putting converters/validators in a DynaClass or a
> descendant but in a seperate 'controller'.
I agree with you.
> > The DynaClass (metadata) part should be the only one having to be
> > extended to avoid a complex DynaBean class structure. Then you can have
> > helper classes that use the extended metadata information to the tasks
> > you talk about (formatting, validation, etc.).
> >
> > Trying to include these and other concerns in some DynaBean
> descendent(s)
> > will produce a monster hard to manage class(es). Separating
> such concerns
> > in separated helper classes with the help of extended metadata will have
> > the advantages of:
> > - Simpler code;
> > - Easier learning of its use (the user does not have to learn
> what he is
> > not using).
>
> I agree DynaBean isn't the right place for this, but I don't
> think DynaClass
> is either - I think a seperate 'controller' is better. Think MVC and that
> the DynaBean/Class as the 'model' and a controller mediates between a view
> (HTTP request/form or Swing controls).
I was talking about extending DynaClass for extended metadata information.
Sometimes you have a bean you use in a very restricted scope - like a data
entry form - and it might be much simpler to define all its metadata in a
single place, including things like validation and conversion rules.
For such use it makes sense to have a specialized DynaClass and some
helpers,
but I am NOT defending this should be included in the "standard" DynaClass.
I am just defending that even in such specific case it is not a very good
idea to extend the DynaBean.
> Since converters would have all kinds of optional contexts associated with
> them like Locale, Timezone and other stuff like maybe the user id or
> HttpSession, keeping such a controller seperate to the DynaClass, like the
> BeanController idea I suggested, would seem cleaner.
>
> e.g. a single 'customer' DynaBean instance could have a single DynaClass
> instance (which could be shared by other customer DynaBeans) but could be
> viewed using various different locales & timezones & users. So having a
> seperate 'controller' object for each context would seem to make sense,
> which just has-a reference to the DynaBean.
Sure.
But I still defended the option we previously discussed of having a
converter
attached to the DynaBean object (not the DynaClass) since it can make most
of
its uses simpler (e.g.: set the bean with a converter for the right Locale
and
just assign values to its fields).
> > Craig, I and others discussed several ideas that have a lot to do with
> > this stuff during the last couple of weeks.
>
> Just out of interest was this on a struts list or just privately?
Just here in the commons-dev list. I do not use Struts.
> James
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [DynaBean] a couple of other existing projects...
Posted by James Strachan <ja...@yahoo.co.uk>.
----- Original Message -----
From: "Paulo Gaspar" <pa...@krankikom.de>
> Extending the DynaClass and using Converters would do most of what you
> describe here.
I'm arguing for not putting converters/validators in a DynaClass or a
descendant but in a seperate 'controller'.
> The DynaClass (metadata) part should be the only one having to be
> extended to avoid a complex DynaBean class structure. Then you can have
> helper classes that use the extended metadata information to the tasks
> you talk about (formatting, validation, etc.).
>
> Trying to include these and other concerns in some DynaBean descendent(s)
> will produce a monster hard to manage class(es). Separating such concerns
> in separated helper classes with the help of extended metadata will have
> the advantages of:
> - Simpler code;
> - Easier learning of its use (the user does not have to learn what he is
> not using).
I agree DynaBean isn't the right place for this, but I don't think DynaClass
is either - I think a seperate 'controller' is better. Think MVC and that
the DynaBean/Class as the 'model' and a controller mediates between a view
(HTTP request/form or Swing controls).
Since converters would have all kinds of optional contexts associated with
them like Locale, Timezone and other stuff like maybe the user id or
HttpSession, keeping such a controller seperate to the DynaClass, like the
BeanController idea I suggested, would seem cleaner.
e.g. a single 'customer' DynaBean instance could have a single DynaClass
instance (which could be shared by other customer DynaBeans) but could be
viewed using various different locales & timezones & users. So having a
seperate 'controller' object for each context would seem to make sense,
which just has-a reference to the DynaBean.
> Craig, I and others discussed several ideas that have a lot to do with
> this stuff during the last couple of weeks.
Just out of interest was this on a struts list or just privately?
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [DynaBean] a couple of other existing projects...
Posted by Paulo Gaspar <pa...@krankikom.de>.
Extending the DynaClass and using Converters would do most of what you
describe here.
The DynaClass (metadata) part should be the only one having to be
extended to avoid a complex DynaBean class structure. Then you can have
helper classes that use the extended metadata information to the tasks
you talk about (formatting, validation, etc.).
Trying to include these and other concerns in some DynaBean descendent(s)
will produce a monster hard to manage class(es). Separating such concerns
in separated helper classes with the help of extended metadata will have
the advantages of:
- Simpler code;
- Easier learning of its use (the user does not have to learn what he is
not using).
Craig, I and others discussed several ideas that have a lot to do with
this stuff during the last couple of weeks.
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Wednesday, January 02, 2002 7:20 PM
> To: Jakarta Commons Developers List
> Subject: Re: [DynaBean] a couple of other existing projects...
>
>
> In the course of the discussions, the idea of a "record" object has come
> up quite often, especially in relating the DynaBean to other object
> developers are already using.
>
> Perhaps we should think about a subclass of DynaBean, or another package
> based on it, that directly supported the idea of "field objects", and
> then made the fields appear like standard properties.
>
> So, you might create your own "RecordBean" class, and then in the
> constructor add several "FieldBeans", to represent the records. So there
> might be prewritten "DateFieldBeans" and "CurrencyFieldBeans", that
> would just add in the constructor (giving them labels and validators
> along the way).
>
> These could then be exposed using both a native type and a String
> variation, so
>
> getDateString
>
> and
>
> getDate
>
> might both refer to the same "DateFieldBean".
>
> Using Struts as an example again, the ActionForms are being used like
> get*String properties for all the fields in a HTML form, and then there
> is a typed companion bean someplace that has the native version. Along
> the way someplace, we validate the get*String properties, and then move
> them over to a native bean.
>
> So along the lines of what Jim mentioned, maybe we could use the
> DynaBean to build another bean that could be used to accept String
> input, optionally validate it, and then expose it as a native type if
> validation passes. The DynaBean would encapsulate the field objects, so
> the fields could be used as JavaBean properties whereever JavaBeans are
> used now.
>
> I'm not proposing we extend the DynaBean this way, but maybe to use it
> as base class for something that let us build more Swing-like controls
> that have a built-in String buffer along with a typed property. If you
> are building something from scratch, then this might be all you need. If
> not, then it would be a great vehicle for validating data before passing
> it along to a legacy object.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Building Java web applications with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [DynaBean] a couple of other existing projects...
Posted by Ted Husted <hu...@apache.org>.
In the course of the discussions, the idea of a "record" object has come
up quite often, especially in relating the DynaBean to other object
developers are already using.
Perhaps we should think about a subclass of DynaBean, or another package
based on it, that directly supported the idea of "field objects", and
then made the fields appear like standard properties.
So, you might create your own "RecordBean" class, and then in the
constructor add several "FieldBeans", to represent the records. So there
might be prewritten "DateFieldBeans" and "CurrencyFieldBeans", that
would just add in the constructor (giving them labels and validators
along the way).
These could then be exposed using both a native type and a String
variation, so
getDateString
and
getDate
might both refer to the same "DateFieldBean".
Using Struts as an example again, the ActionForms are being used like
get*String properties for all the fields in a HTML form, and then there
is a typed companion bean someplace that has the native version. Along
the way someplace, we validate the get*String properties, and then move
them over to a native bean.
So along the lines of what Jim mentioned, maybe we could use the
DynaBean to build another bean that could be used to accept String
input, optionally validate it, and then expose it as a native type if
validation passes. The DynaBean would encapsulate the field objects, so
the fields could be used as JavaBean properties whereever JavaBeans are
used now.
I'm not proposing we extend the DynaBean this way, but maybe to use it
as base class for something that let us build more Swing-like controls
that have a built-in String buffer along with a typed property. If you
are building something from scratch, then this might be all you need. If
not, then it would be a great vehicle for validating data before passing
it along to a legacy object.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>