Hello,
I'm a newcomer who try to run the examples (atm I'm stuck with chapter
8; may be my next email ;-) ), but may I suggest :
- to keep an option with Rife as it is,
- to add an option "Rife with AOP", and use for example Spring
capabilities or even AspectJ
Regards
Pierre
Geert Bevin a écrit :
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
_______________________________________________
Rife-users mailing list
Rife-users@uwyn.com
http://www.uwyn.com/mailman/listinfo/rife-users
