I think this is fine. While I don't know if I would ever use it (I suspect I would) I think it fills a void.

I think the implementation that Geert suggested is perfect (except that his POJO extends something, but I'm sure that is a typo).

On 10/30/05, Geert Bevin <[EMAIL PROTECTED]> wrote:
As I said to Keith, this would be an additional way of specifying the
constraints.

The main reasons are:
* allow for migration of existing POJOs models towards RIFE (Spring,
Hibernate, ...)
* create POJOs in a RIFE application that are framework-independent
and can be used together with other solutions

I you look how this would be practically, it doesn't change much imho.

Let's compare:

Traditional method
==================

public class Blog extends CmfValidation
{
     private int     mId = -1;
     private Date    mMoment = Calendar.getInstance().getTime();
     private byte[]  mImage = null;
     private String  mTitle = null;
     private String  mBody = null;
     private boolean mDraft = false;

     protected void activateValidation()
     {
         addConstraint(new ConstrainedBean()
             .defaultOrder("moment", ConstrainedBean.DESC)
             .defaultOrder("title"));

         addConstraint(new CmfProperty("id")
             .editable(false)
             .identifier(true));
         addConstraint(new CmfProperty("moment")
             .listed(true)
             .notNull(true));
         addConstraint(new CmfProperty("image")
             .listed(true)
             .mimeType(MimeType.IMAGE_PNG)
             .contentAttribute("width", 150)
             .notNull(true)
             .file(true));
         addConstraint(new CmfProperty("title")
             .listed(true)
             .notNull(true)
             .notEmpty(true)
             .maxLength(100));
         addConstraint(new CmfProperty("body")
             .mimeType(MimeType.APPLICATION_XHTML)
             .autoRetrieved(true)
             .fragment(true)
             .notNull(true)
             .notEmpty(true));
         addConstraint(new CmfProperty("draft")
             .notNull(true)
             .defaultValue(false));
     }

     // accessors omitted
}

True POJO method
================

public class Blog extends CmfValidation
{
     private int     mId = -1;
     private Date    mMoment = Calendar.getInstance().getTime();
     private byte[]  mImage = null;
     private String  mTitle = null;
     private String  mBody = null;
     private boolean mDraft = false;

     // accessors omitted
}

public class BlogMetaData extends CmfValidation
{
     protected void activateValidation()
     {
         addConstraint(new ConstrainedBean()
             .defaultOrder("moment", ConstrainedBean.DESC)
             .defaultOrder("title"));

         addConstraint(new CmfProperty("id")
             .editable(false)
             .identifier(true));
         addConstraint(new CmfProperty("moment")
             .listed(true)
             .notNull(true));
         addConstraint(new CmfProperty("image")
             .listed(true)
             .mimeType(MimeType.IMAGE_PNG)
             .contentAttribute("width", 150)
             .notNull(true)
             .file(true));
         addConstraint(new CmfProperty("title")
             .listed(true)
             .notNull(true)
             .notEmpty(true)
             .maxLength(100));
         addConstraint(new CmfProperty("body")
             .mimeType(MimeType.APPLICATION_XHTML )
             .autoRetrieved(true)
             .fragment(true)
             .notNull(true)
             .notEmpty(true));
         addConstraint(new CmfProperty("draft")
             .notNull(true)
             .defaultValue(false));
     }
}

On 30-okt-05, at 17:50, Stefan wrote:

> Indeed, splitting this information into too many classes may result
> in confusion instead of ease of use. Why not do something like
> WindowListener and WindowAdapter in java? So having a default class
> if interface implementation is not simple enough? Or maybe a
> Wrapper/Delegator could be added.
>
> Also, seeing the current way annotations are used in java (EJB 3.0
> for example)  currently anyone tries not to spread too much
> information in different files.
>
> Keith Lea schrieb:
>
>
>> I think requiring 2 classes for each bean sucks. I know it won't
>> be  required, but I think even allowing you to do it this way is
>> encouraging complicated, verbose, hard to maintain code.
>>
>> On Oct 30, 2005, at 3:47 AM, Geert Bevin wrote:
>>
>>
>>> Hi everyone,
>>>
>>> currently, the persistence engine requires your POJOs to
>>> implement  the Constrained and Validated interface, which can be
>>> quite a  burden if you don't extend the CmfValidation or
>>> Validation base  classes. I was thus thinking of adding support
>>> for declaring all  the meta-data in an external parallel class.
>>>
>>> So if your POJO is named like this:
>>> com.mypakkage.ThisPojo
>>>
>>> RIFE would look for:
>>> com.mypakkage.ThisPojoMetaData
>>>
>>> If this class exists and implements the required interface, it
>>> will  be instantiated for each instance of ThisPojo that is
>>> inspected for  meta-data.
>>>
>>> Sadly this is not as simple as it sounds, since RIFE's
>>> validation  is state-full. It has been designed to stick around
>>> as a collector  for all validation errors that can appear in any
>>> possible layer,  until the errors are explicitly cleared. To make
>>> this possible, I  should add a registry (WeakHashMap) that keeps
>>> track of each  ThisPojo instance and the associated
>>> ThisPojoMetaData instance.
>>>
>>> The most logical location to add this would be an additional
>>> Participant. However, since this is such a fundamental core
>>> feature, it seems awkward to require everybody to add this
>>> participant explicitly. It would this always be added by default
>>> to  the standard Repository implementation (maybe even to the
>>> custom  ones). Another option would be to just have a static map
>>> in  ConstrainedUtils, but that feels very dirty.
>>>
>>> What do you think of all this? Do you think it is worth the
>>> effort?  Any better ideas to preserve the instance and meta-data
>>> mapping?
>>>
>>> Thanks for you input,
>>>
>>> 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 +32 64 84 80 03
>>>
>>> PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
>>> Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net
>>>
>>>
>>> _______________________________________________
>>> Rife-users mailing list
>>> Rife-users@uwyn.com
>>> http://www.uwyn.com/mailman/listinfo/rife-users
>>>
>>>
>>
>> _______________________________________________
>> Rife-users mailing list
>> Rife-users@uwyn.com
>> http://www.uwyn.com/mailman/listinfo/rife-users
>>
>>
> _______________________________________________
> Rife-users mailing list
> Rife-users@uwyn.com
> http://www.uwyn.com/mailman/listinfo/rife-users
>
>

--
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 +32 64 84 80 03

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


_______________________________________________
Rife-users mailing list
Rife-users@uwyn.com
http://www.uwyn.com/mailman/listinfo/rife-users



--
JR Boyens
[EMAIL PROTECTED]
_______________________________________________
Rife-users mailing list
Rife-users@uwyn.com
http://www.uwyn.com/mailman/listinfo/rife-users

Reply via email to