Intro, ConstrainedProperty

[eokyere]

Geert and All,

My name is Emmanuel Okyere, I do a fair bit of java development on a
daily basis, and I've been evaluating RIFE over the last few days; I
am very excited by what I see in the codebase itself, as well as the
equally excellent examples the framework has been put to, shown on the
RIFE website; It is also refreshing to see a project this new put out
so much documetation. Thanks a lot guys.

I noticed code like:

         new CmfProperty(ID).identifier(true).editable(false)

in  the simple blog example, which corresponds to:

        public T identifier(boolean identifier) {
                setIdentifier(identifier);

                return (T) this;
        }

        public void setIdentifier(boolean identifier) {
                mConstraints.put(IDENTIFIER, identifier);
        }

In the ConstrainedProperty class.

Is there a reason the setXXX methods return voids? Since 'constraints'
should be explicitly spelt out, I hardly expect anyone to type code
like:

foo.indentifer(false)

I think we can maintain the flexibility of the code while still
maintaining the use of the non-sexXXX methods as CmfProperty
'annotations', by introducing sensible defaults.

For instance, I have done changes to what I have here to look like:

        public T identifier() {
                return setIdentifier(true).notEditable();
        }

        public T setIdentifier(boolean identifier) {
                mConstraints.put(IDENTIFIER, identifier);
                return (T) this;
        }

        public T notEditable() {
                reuturn setEditable(false);
        }

        public T setEditable(boolean editable) {
                mConstraints.put(EDITABLE, editable);
                return (T) this;
        }

which allows me to write either

         new CmfProperty(ID).setIdentifier(true).setEditable(false);
// the old way
or
         new CmfProperty(ID).identifier() // as an 'annotation'


Comments?

Thanks,
Emmanuel

[Geert Bevin]

On 28-okt-05, at 00:22, Emmanuel Okyere wrote:

> Geert and All,
>
> My name is Emmanuel Okyere, I do a fair bit of java development on a
> daily basis, and I've been evaluating RIFE over the last few days; I
> am very excited by what I see in the codebase itself, as well as the
> equally excellent examples the framework has been put to, shown on the
> RIFE website; It is also refreshing to see a project this new put out
> so much documetation. Thanks a lot guys.

Thanks for the nice compliments :-)

> I noticed code like:
>
>          new CmfProperty(ID).identifier(true).editable(false)
>
> in  the simple blog example, which corresponds to:
>
>     public T identifier(boolean identifier) {
>         setIdentifier(identifier);
>
>         return (T) this;
>     }
>
>     public void setIdentifier(boolean identifier) {
>         mConstraints.put(IDENTIFIER, identifier);
>     }
>
> In the ConstrainedProperty class.
>
> Is there a reason the setXXX methods return voids?

There are several reasons for this, one is that a setXXX method that  
does not return void isn't seen as a setter in the JavaBean spec and  
introspection classes. Second, some people hate the chained method  
calls and prefer writing the setXXX operations as they do traditionally.

> Since 'constraints'
> should be explicitly spelt out, I hardly expect anyone to type code
> like:
>
> foo.indentifer(false)

Not in the initial declaration, but you have to understand that  
constraints are done on an instance basis, not on a class basis. This  
means that at any moment you can change the constraints of one  
particular instance to handle exceptional situations even when  
automated logic applies. Using this with RIFE's callbacks makes this  
particularly useful.
Another reason is that people can extend classes that already  
declared constraints and still want to override some of them.

> I think we can maintain the flexibility of the code while still
> maintaining the use of the non-sexXXX methods as CmfProperty
> 'annotations', by introducing sensible defaults.
>
> For instance, I have done changes to what I have here to look like:
>
>     public T identifier() {
>         return setIdentifier(true).notEditable();
>     }
>
>     public T setIdentifier(boolean identifier) {
>         mConstraints.put(IDENTIFIER, identifier);
>         return (T) this;
>     }
>
>     public T notEditable() {
>         reuturn setEditable(false);
>     }
>
>     public T setEditable(boolean editable) {
>         mConstraints.put(EDITABLE, editable);
>         return (T) this;
>     }

This might be sensible for you, and I agree that for most people this  
will be the case, but in this particular case I know of people using  
sparse tables that have identifiers that are not generated by the  
database. They might want them to be editable, so this default  
doesn't make sense for them.
Also, one of the approaches in RIFE is to be consistent and simple  
without too much automated or magic behavior. In this case for  
instance, people might find it confusing in the long run since  
modifying constraints are not clearly defined operations anymore.  
Without reading the RIFE source or the javadocs, they are never sure  
that the constraint operations they perform are exactly what happens.

> which allows me to write either
>
>          new CmfProperty(ID).setIdentifier(true).setEditable(false);
> // the old way
> or
>          new CmfProperty(ID).identifier() // as an 'annotation'
>
>
> Comments?

Thanks for your ideas, I'm always interested in comments and thoughts  
that might improve our framework.

Best regards,

Geert

--
Geert Bevin                       Uwyn bvba
"Use what you need"               Avenue de Scailmont 34
http://www.uwyn.com               7170 Manage, Belgium
gbevin[remove] at uwyn dot com    Tel [phone]

PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net

[eokyere]

Geert,

Thanks for the reply;

On 10/28/05, Geert Bevin <gbevin@...> wrote:

>
> On 28-okt-05, at 00:22, Emmanuel Okyere wrote:
>
> > Geert and All,
> >
> > My name is Emmanuel Okyere, I do a fair bit of java development on a
> > daily basis, and I've been evaluating RIFE over the last few days; I
> > am very excited by what I see in the codebase itself, as well as the
> > equally excellent examples the framework has been put to, shown on the
> > RIFE website; It is also refreshing to see a project this new put out
> > so much documetation. Thanks a lot guys.
>
> Thanks for the nice compliments :-)
>
> > I noticed code like:
> >
> >          new CmfProperty(ID).identifier(true).editable(false)
> >
> > in  the simple blog example, which corresponds to:
> >
> >     public T identifier(boolean identifier) {
> >         setIdentifier(identifier);
> >
> >         return (T) this;
> >     }
> >
> >     public void setIdentifier(boolean identifier) {
> >         mConstraints.put(IDENTIFIER, identifier);
> >     }
> >
> > In the ConstrainedProperty class.
> >
> > Is there a reason the setXXX methods return voids?
>
> There are several reasons for this, one is that a setXXX method that
> does not return void isn't seen as a setter in the JavaBean spec and
> introspection classes. Second, some people hate the chained method
> calls and prefer writing the setXXX operations as they do traditionally.

Ah, to conform to the JB spec... makes sense

> > Since 'constraints'
> > should be explicitly spelt out, I hardly expect anyone to type code
> > like:
> >
> > foo.indentifer(false)
>
> Not in the initial declaration, but you have to understand that
> constraints are done on an instance basis, not on a class basis. This
> means that at any moment you can change the constraints of one
> particular instance to handle exceptional situations even when
> automated logic applies. Using this with RIFE's callbacks makes this
> particularly useful.
> Another reason is that people can extend classes that already
> declared constraints and still want to override some of them.

The change wouldn't have precluded them from using the setXXX methods
to make special changes, as was already being done; but this goes back
to the JB spec point, which seems to be the overiding matter here :)

> > I think we can maintain the flexibility of the code while still
> > maintaining the use of the non-sexXXX methods as CmfProperty
> > 'annotations', by introducing sensible defaults.
> >
> > For instance, I have done changes to what I have here to look like:
> >
> >     public T identifier() {
> >         return setIdentifier(true).notEditable();
> >     }
> >
> >     public T setIdentifier(boolean identifier) {
> >         mConstraints.put(IDENTIFIER, identifier);
> >         return (T) this;
> >     }
> >
> >     public T notEditable() {
> >         reuturn setEditable(false);
> >     }
> >
> >     public T setEditable(boolean editable) {
> >         mConstraints.put(EDITABLE, editable);
> >         return (T) this;
> >     }
>
> This might be sensible for you, and I agree that for most people this
> will be the case, but in this particular case I know of people using
> sparse tables that have identifiers that are not generated by the
> database. They might want them to be editable, so this default
> doesn't make sense for them.
> Also, one of the approaches in RIFE is to be consistent and simple
> without too much automated or magic behavior. In this case for
> instance, people might find it confusing in the long run since
> modifying constraints are not clearly defined operations anymore.
> Without reading the RIFE source or the javadocs, they are never sure
> that the constraint operations they perform are exactly what happens.

same as above

> > which allows me to write either
> >
> >          new CmfProperty(ID).setIdentifier(true).setEditable(false);
> > // the old way
> > or
> >          new CmfProperty(ID).identifier() // as an 'annotation'
> >
> >
> > Comments?
>
> Thanks for your ideas, I'm always interested in comments and thoughts
> that might improve our framework.
>

Many thanks,
Emmanuel