Hi Geert,
yes, that seems clear by your example. Nevertheless I am currently
thinking about pros and cons of a repository. Though this has not been
used in your examples I could think of the need for different
validations for one single pojo.
Your default way would either be the current way it is implemented in
rife or
an optional (and direct) relationship between
com.mypackage.ThisPojo and
com.mypackage.ThisPojoMetaData
But think of different users with different rights. One who could enter
a new data object and one who may modify everything (e.g. admin). Though
this could be achieved by if statements it would be an option if
validation A would allow to enter anything but the mId in your example
and validation B would allow to alter that mID also.
Please note that this is just an idea. Maybe that will not be required
by any real world applications but is an option that would let me prefer
a repository to alter the default settings. So if such an entry does
exist that one will be taken otherwise the default behaviour will be used.
Geert Bevin schrieb:
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
{
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
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
_______________________________________________
Rife-users mailing list
[email protected]
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
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
